OPENCORES.ORG

From: markus at reaaliaika.net<markus@r...>
Date: Tue Aug 17 12:16:41 CEST 2004
Subject: [oc] Parallel Array Processor Project

[P-code generator] > > >You mean you have a pcode generator? ;-) > > > > Well, I didn't quite follow this... Most parsers/compilers [...] > > convert the mixed prefix/infix notation (function calls, infix > > operators) to a postfix, stack-based code. > > Which is called p-code after the UCSD p-code machine. I readed the description, and in broader sense, yes, maybe, I have a some kind of P-code generator - or Forth-code generator. Hmmh, I have hard times to trying to classify the current compiler backend. The front-end is definitely a stack-based, recursive system. It's derived from compiler for conventional processors, but because the array has no stacks or procedure calls, the resulting code is not stack- based. But because of the inheritance, it's easily modified to do so. > Normally though you use the p-code to build trace trees and then > optimize on them [...] for the non-stack-processor. Yes (altought I normally use the term "evaluation trees"). [Striping a Forth processor] > Remember to strip you compiler if you kick out subroutines. > They really don't cost that much in stack machines. What would the cell call for? I can't see at the moment much use of subroutines, because the stack engine is only used to implement cell instructions (which would otherwise require HW). The array itself doesn't have subroutines. For example, one cell could add the values from north and south cells. The code for the cell would be: push north push south add out ..where: "out" <=> "result = pop()" > > What increases the complexity, is the neighborhood > > synchronization - it could be HW or SW based [...] > > Did you see my comments on the PORT semantics for stack machines? Yes, I saw and I'm familiar with the concept (Forth uses somewhat similar thing for memory addressing). I have a something like that in my simple single-bus cell processor design: http://reaaliaika.net/showarea.php/procmem/schw_connection Some more words about the sync'ing with software based solutions: http://reaaliaika.net/showarea.php/procmem/schw_sync [DSP programming] > [1] And if you look at TI 6000, AD TigerSHARC etc, most programmers > have a hard time beating the performance reached by the > compilers by hand writing asssembler. Yes, and speak about the difficultiness of writing the compiler. For that DSP56303, I realized, that I have to have a quite complete processor model inside an assembler compiler to produce good, pipeline stall-less code.