Aloha! markus at reaaliaika.net wrote:

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. DSP codes are much more regular with the
bulk of the execution located in specific kernels. The kernels however might
be written in optimized assembler for the specific architecture.

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.

TI, AMD, AD etc spends lots of money developing good compilers for their
architectures.



Stack based cores for embedded multiprocessor applications are a very fine
idea. There have been some work done on this, but I have few references for
you. 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.



You mean you have a pcode generator? ;-)

Yep! -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

If you look at stack based cpu. You could maybe look at forth chip. I have heard about "F40" or somethink linke that. It's a self timed assynchronous chip. It was running at a 2 ns cycle on a 0.5 µm technology (but need 4 cycles for an add). It count around ~1000 transistors designed by hand. It was made with a french public lab like Tima or INRIA but i don't remember precisly. Maybe that could be a nice starting point if you know how to programm such array :) I find this about FORTH cpu but is not the projet i had speak about : http://pet.dhs.org/~ecl/theproject/theproject.html and this one : http://www.jwdt.com/~paysan/b16.html

i found the forth chip :) http://www.ultratechnology.com/f21.html

Thanks! I already took a quick look. The F21 could be striped down
more, when using in the array. There's no need for subroutines, jumps
and conditionals are enough. Thus, there's no need for PC stack, either.
The data stack could be decreased, too.

What increases the complexity, is the neighborhood synchronization - it
could be HW or SW based, which ever seems to be better. I would
prefer software-based, because:

* You would implement only that synchronization mode, which you're
using in the cell (with HW implementation, you'd need to implement all
modes to all cells)

* It could give you possibility to use very complex synchronizations.

But I'll look it closer and make some scetchs.

[Forth Chip]


The speed of the single operations is not a problem. If my current
thoughts are right, the parallelism easily overcomes that in the average
cases.



Sounds faschinating!

[Stack-based cells]


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.



You mean you have a pcode generator? ;-)

Aloha! nico at seul.org wrote: There has been a previous thread about stack processors on OC. These links were mentioned in that thread: (Good list of basically all known chips and cores) http://www.ultratechnology.com/chips.htm JOP - The Java Optimized Processor; a stack architecture http://www.jopdesign.com/ And it's hard to talk about stack processors without mentioning Koopmans seminal book on the subject - "Stack Computers: the new wave": http://www.ece.cmu.edu/~koopman/stack_computers/index.html Finally Chuck Moore is the old man to know about when it comes to stack processors: http://www.colorforth.com/ -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

Aloha! markus at reaaliaika.net wrote:

Remember to strip you compiler if you kick out subroutines. They really don't
cost that much in stack machines.

Did you see my comments on the PORT semantics for stack machines? What you probably want are three primitives: (1) An IN port directive. Read from a shared memory via the port system. The address could be implicitlt taken as the value on TOP on the data stack. (2) An OUT port directive. Write to a shared memory via the port system. The address and value could be implicitly taken as TOP and TOP+1 on the data stack. (3) An atomic test and set ("TST" perhaps), a semaphore. Either a binary or multi value semaphore where the set value is TOP. The HW implementation for (1) and (2) would need to consider write scheduling and/or memory segmentation (dedicated write areas per PE), the latter would directly affect the programming model. (3) can be quite simply implemented by restricting the area where TST can be performed. I.e. they are located in a separate area from the shared memory. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

Aloha! markus at reaaliaika.net wrote:

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.

[P-code 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.

Amongst a huge restructuration, there's now a small PDF file, which tries to collect the basic things of the project: http://reaaliaika.net/download/procmem.000.sxw.pdf

At 15:54 2004-08-22 +0200, markus at reaaliaika.net wrote:

Hi Markus,

I've followed this thread for a while. Your ideas sound interesting
I think, but note that I'm not any kind of expert on processor
architecture.

I am however a hardware developer, and as such, one thing strikes me
when I read about your ideas; Isn't it so that your architecture
actually IS the architecture of an FPGA? Or very much like it anyway,
might be that the FPGA architectures have even simpler processing cells
than the ones you have in mind? But they do have an instruction register
(the LUT programming), a result register (output flip-flops), and read
connections to their neighbours (the routing, even though this is more
complicated in the FPGA case).

You then have to excuse my ignorance because I have not had time to
in detail try to understand your ideas for programming this processor,
but from what I've read in this thread I got the impression that you're
thinking in the way of a programming language with lots of parallellism.
Sounds quite a lot like hardware design, on RTL or somewhat higher level,
to me... The RTL code can be seen as a "program" for an FPGA, the compiler
then being the synthesis and place-and-route tools.

Interesting also that you call it a "processing memory", this name also
fits quite good for an (SRAM-based) FPGA... Which is basically a memory
with some processing facilities added (the people developing the FPGAs
might not agree completely with this description... ;-)

Do you think that this interpretation of your ideas makes any sense?
Maybe the fact that the processing cells you're thinking of are much
more advanced than the current FPGA macrocells really adds a new
dimension with regards to how the processor is programmed and so on?

Anyway, if my comparison stands, you probably can take some inspiration
from hardware design and the associated tools. And maybe also the other
way around in the future...

(Take a look at e.g. "handel-C" from Celoxica, which is C with extensions
for parallellism. They have a compiler for it that takes it all the way
to hardware. They claim it is a very efficient way to design hardware. I
don't know about that though... :)

Good luck with your project, best regards
Gunnar Dahlgren
ASIC designer @ Axis Communications AB, Sweden

You're absolutely right here! Unconsciously I have thought that the PM
and FPGA have many things in common (for example, I have studied
using the VHDL as a programming language and I have borrowed many
ideas found from FPGAs to the possible physical implementations), but I
haven't thought this consciously.

Now I'm doing this first time, when writing this, so you probably
understand some "fuzziness" in the thougts... :-)



That's true. What are the differences of the FPGA cell and the PM cell?

In ground level, the program written for PM could be compiled to the
FPGA, as well as for conventional processor. That's nothing new, I think,
every program can be implemented either with hardware or with
software or with a some kind of combination of both.

---
I could quickly think these differences:

* The PM design should allow you to write programs for writing programs
(e.g. compilers, text editors and so on). I'm not sure, if you could write
a VHDL/FPGA compiler to FPGA?

BTW, one test for analyzing the completeness of the programming
languages is, that is it possible to write a program to output that
program with it? I don't know, if the VHDL passes that test?

* Furthermore, PM design should allow a program to "load" another
program inside the array. If I recall correctly, there has been some
attempts for creating "self-reconfigurable" FPGAs, too? But because of
the application area of the FPGA, I think that those oddities are not
very popular...?

* The PM chip should be able to execute larger programs that can fit
inside of the chip, by using a virtual memory. Normally, you don't have
this kind of possibilities in the FPGA, am I right?

I think that the ground reason for this is, that the PM cell is
synchronous. You can stop it for processing, read the state of it, store
it and later, restore the state from the memory and continue processing.

---

But PM and FPGA share many things, like inherent parallelism and cellular
structure. Some people could say, that PM is one implementation of so
called reconfigurable computing - I'd say, that it's just a massively
parallel processor.



I borrowed the idea of the "transmission gateway" (accessing distant
parts of the array) from the FPGA world :-)



Yes, you're right here. My approach comes from the programming world
and I have just basic knowledge (which is not too much) of the
hardware desing world.



Yes, and I think, that the hardware designers would easier understand
the programming paradigms of the PM than regular software designers.
And, I have borrowed the idea of "cell mapper" from the FPGA world -
that is, the PM needs a program for mapping the virtual assembler code
to physical cells just like VHDL does.



:-) But yes, PM and SRAM-based FPGAs are close to each other. And
yes, PIM (Processing In Memory) architectures are close to these, too.

The name comes to very obvious thing: I was designing a memory,
which processes the data by itself.



Perfectly!



Surely, the cells are more complex than the cells in the FPGA. About the
new dimension of processor programming, I'm not sure - my primary goal
is to get the PM to be programmable, without any extra pain (which it is
at the moment).



I'll do that.



I'll do that, altought at the moment I started the design of the HLL once
again from the grounds and decided to leave the world of the existing
languages behind... :-)

You're absolutely right here! Unconsciously I have thought that the PM
and FPGA have many things in common (for example, I have studied
using the VHDL as a programming language and I have borrowed many
ideas found from FPGAs to the possible physical implementations), but I
haven't thought this consciously.

Now I'm doing this first time, when writing this, so you probably
understand some "fuzziness" in the thougts... :-)



That's true. What are the differences of the FPGA cell and the PM cell?

In ground level, the program written for PM could be compiled to the
FPGA, as well as for conventional processor. That's nothing new, I think,
every program can be implemented either with hardware or with
software or with a some kind of combination of both.

---
I could quickly think these differences:

* The PM design should allow you to write programs for writing programs
(e.g. compilers, text editors and so on). I'm not sure, if you could write
a VHDL/FPGA compiler to FPGA?

Gunnar Dahlgren:

I added the comment with my reply to my web pages (feedback section), because it just brought a whole new world in to my mind... I also thought the issue a little further and made this addition: "What really is the difference between the PM and the FPGA? I must think more about this, because it could reveal some extraordinary possibilities for the PM. One thing is sure; the FPGA has been designed to process electronical signals. The PM has been designed to process abstract signals - data. PM is like a FPGA, not operating in the physical world, but in the abstract, virtual data world. Does it make any sense?" --- Altogether, there's new thoughts about the HLL and esp the "HLL Crisis": http://reaaliaika.net/showarea.php/procmem/hll_design/crisis