http://www.greenarrays.com/home/documents/greg/PB001-100503-... [pdf]
About the mentioned F18A computer:
The F18A is a stable, mature design for a computer and its I/O whose robustness has been proven in many chip configurations. It has been proven in 180nm geometry, and a prototype in 130 nm has also performed well. The computer is small; eight fit in roughly a square millimeter. Depending on chip configurations, this yields between 100,000 and 200,000 computers per 8 inch wafer, contributing to the low cost of our chips.
http://greenarraychips.com/home/documents/greg/PB003-100822-... [pdf]
In the named pdf -files are also some information about possible applications. But it seems to be quite tough to get some outside information about it.
I think it has more than one MISC command in a word, I think count is about 3 (six-bit commands).
I cannot wrap my head around how to program that... not a beast, more like a field of tiny windmills. One of the designers of preceding chips once wrote about using it as a systolic engine, but the area of systolic algorithms is quite narrow, AFAIK.
I cannot find any C/Fortran compiler or compiler for any other high-level language.
My overall impression is that this looks like all bad ideas from Cell BE were ported to Forth language.
MISC: http://en.wikipedia.org/wiki/Minimal_instruction_set_compute... John Sokol on early GreenArray alike designs: http://hardware.slashdot.org/comments.pl?sid=274687&cid=...
Reading up on Charles Moore this may indeed be the intended case: http://www.pcai.com/web/ai_info/pcai_forth.html
> Charles Moore created Forth in the 1960s and 1970s to give computers real-time control over astronomical equipment. A number of Forth's features (such as its interactive style) make it a useful language for AI programming, and devoted adherents have developed Forth-based expert systems and neural networks.
Still, 100 billion neurons in brain / 144 cores * $20 per chip = ~$13 billion . Also I would guess most modern researchers in this area don't know Forth and are doing high-level programming and virtualizing neurons rather than taking a low-level hardware approach.
I have a book where authors developed Lisp on Forth and then proceed developing Prolog on newly created Lisp. Then they demonstrated how to use that Prolog in the development of rule-based expert system.
There was a saying that Forth amplify programmers' ability to develop programs and to make mistakes. If you a need an AI tool, but do not need your mistakes to be amplified, stay away from Forth. I think that apply to other areas of domain-specific development as well.
While I adore Forth, I cannot recommend it to anyone. Especially to simulate brain - what if you introduce an error, Forth amplifies it and we'll get a hidden psychopath? ;)
PAIP and a couple others have Lisp and Prolog, LOL has Lisp and Forth, HOPL 2 has all three (but separately), but it doesn't sound like any of those.
From http://www.faqs.org/faqs/computer-lang/forth-faq/part5/
Contains LISP and Prolog emulations in Forth,
including a unification algorithm. It also has some
minimum distance classifier code.
The application is fault diagnosis in locomotives.However, communicating in parallel between CPUs is very easy. I/O lines between CPUs have essentially a hardware semaphore that will cause reading CPUs to block until they get a write and writing CPUs to block until they get a corresponding read. By bit-indexing ports you also get pretty easy fanout.
The docs also mention that CPUs can directly "push" instructions to one another without needing a bootstrap on the receiving end, which allows CPUs to act as extended memory for one another, eases debugging and opens up tantalyzing possibilities for self-modifying code.
You aren't going to get very far trying to execute a conventional language on this architecture, but color me interested.
What's so bad about the cell? I know developers that express nothing short of love for the cell processor.
The tool support for Cell BE SPU was close to existent (no, I didn't mess words up). It was of such low quality so that you pretty had to use Emacs with assembler highlighting mode to to any serious work for SPU. The difference in speed between gcc and hand made assembler code circa 2007 was about 1.5-2 times.
Both PPU and SPU are in-order, so you have to avoid minefield of random memory accesses. You had to manually write allocators and such while holding up SPU constraints.
In-order architectures does not facilitate abstractions. You cannot simply recompile code from out-of-order x86 for in-order Cell BE and obtain reasonable performance (say, about 80% from maximum). You will have to optimize agressively.
You cannot load too much into 256Kbytes combined data and program memory of SPU. Divide those 256Kbytes by two, and you have about 128Kbytes of program memory (you should divide it again - one for working program and another for loaded program) and 128Kbytes, or 8Kquadwords (16 bytes per quad word) of data memory. Data memory you should divide again - one part of your data is constant, perhaps, or you work with one patr and another is being loaded. 4K quadwords. Two operations per cycle on quadwords, 2K cycles to process the whole data block. The latency of Cell memory subsystem is very high, so our 2Kcycles should be comparable to time needed to load that amount of data into SPU. So you have to be very, very careful to keep SPU loaded and working.
Many new chips suffer from lack of compiler support, especially in automatic parallelization. Cell BE surely did. So does GreenArray. Cell BE suffered from lack of memory on SPU, main parallel engine block. GreenArray does that as well. Cell BE used simple to implement but hard to program in-order architecture in all its' processing parts. GreenArray uses stack architecture which is extremely hard to program.
So, in my eyes, GreenArray is Cell BE ported to Forth. ;)
Nothing really interesting is.