|
Message
From: markus at reaaliaika.net<markus@r...>
Date: Tue Aug 17 10:20:46 CEST 2004
Subject: [oc] Parallel Array Processor Project
[Stack-based cells]
> One thing to consider is how to implement/include the
> communication semantics. You could do this by adding a
> communication co-processor that extends the instruction
> set with port semantics. Doing this pushes/exposes the
> syncronization to the user and removes lots of burden for the HW
> implementation.
I have already been comparing HW-based and SW-based
synchronization models in my head. The SW-based is more fascinating
for me, because I'm much more a programmer than a HW designer and
because it's relatively easy to include that to the assembler/HLL
compiler.
> > The compiler could be easily modified to output reverse polish
> > program for the cell. In fact, it's easier to do this than make
> > the compiler to output programs for register-based PSMs.
>
> You mean you have a pcode generator? ;-)
Well, I didn't quite follow this... Most parsers/compilers (including most
of my compiler constructions and the current PM HLL compiler) convert
the mixed prefix/infix notation (function calls, infix operators) to a
postfix, stack-based code. Then, for conventional processors, a register
allocation is done and the compiled code is emitted.
Furthermore, most of the virtual machines (Java bytecode VM, Python
VM) are stack-based, because of the easiness of the implementation of
both VM and the compiler for it.
---
<offtopics>
[DSPs and C and uniform memory addresssing/accessing paradigm]
> > Have anyone programmed DSPs with C (or other higher level
> > language)?
[...]
> Yes I have. I would say that quite a lot (most?) DSP programming is
> done in C, albeit with more or less lots of pragmas and calls to
> (inlined) library functions sprinkled whithin the code.
I know - what a mess :-( But, the assembler programming is much
harder for larger applications than programming tweaked C code... :-/
> Programming DSPs can be quite a challenge, both due to
> non-orthogonal instruction sets and (for example TIs 6000
> series) VLIW and multiple core architectures.
You said it :-)
> TI, AMD, AD etc spends lots of money developing good compilers
> for their architectures.
Yes, and the results are quite good, altought the language itself does
everything to make it harder...
</offtopics>
|
 |
Browse
