All I know of Chuck's current projects comes from his blog and the fireside chats he gives at the Silicon Valley Forth Interest Group's annual "Forth Day". They can be found here, along with many other fun presentations: http://www.forth.org/svfig/videos/index.html
It seems he's written some temperature-monitoring and signal processing code, a number of routines for generating VGA video signals and he has begun work on building a ColorForth compiler that can run on the GA144.
Do they provide a foundation for building application-oriented languages in the classic Forth style?
Based on my observations and my own experience tinkering with a softsim for a single F18, the resource constraints of the processing elements make it very difficult to write genuinely reusable code, beyond discovering idiomatic opcode combinations and design approaches. The only way to make your code fit is to code like Chuck- simplify brutally. It would be interesting to see how well an optimizing compiler could take more relaxed, modular Forth (or another language) and squeeze it onto an F18.
What I really want to know is whether this architecture would be suitable for dataflow, i.e. whether you could build a spreadsheet on top of it. It seems not unlike the systolic array architectures that were a hot research topic 25 years ago, and those were thought to be suitable for dataflow.
I concur with your comparison to systolic arrays- the GA144 is more flexible than most of those old designs, but has a very similar character. I think calculating something like a spreadsheet on a grid of F18s could work well, but would need a much larger array of processing elements to be effective. Interconnect is also an issue. The parallelism that can be extracted by dataflow architectures is often a product of the rate at which calculations can fan out, and a grid-based architecture enforces a strict cap. As I'm sure you are well aware, spreadsheet formulae frequently gather input from a large number of other cells and are in turn used in many places, often with only a tenuous relationship to the orthogonal neighbors of a cell.
Your discussion of re-entrancy in spreadsheets raises some interesting ideas. F18 cores in a GA144 are designed to very easily push code to their neighbors to execute- it's the basis of deploying code through the grid. The same capabilities mean that you can write code that dynamically reprograms various parts of the array at runtime. Extensive use of self-modifying code is widely regarded as deep magic nowadays, but I've often imagined programming for a huge FPGA where an OS can assemble new purpose-designed cores on the fly instead of spinning up new processes- these chips could be used in a similar way. Like I said, there's a great deal of new CS theory lurking in this design space.
My pleasure. :)
Do we know any programs that have been written for them? What does Chuck write?
The largest available program listing for the GA144 that I'm aware of is an MD5 hasher: http://www.greenarraychips.com/home/documents/pub/AP001-MD5....
All I know of Chuck's current projects comes from his blog and the fireside chats he gives at the Silicon Valley Forth Interest Group's annual "Forth Day". They can be found here, along with many other fun presentations: http://www.forth.org/svfig/videos/index.html
It seems he's written some temperature-monitoring and signal processing code, a number of routines for generating VGA video signals and he has begun work on building a ColorForth compiler that can run on the GA144.
Do they provide a foundation for building application-oriented languages in the classic Forth style?
Based on my observations and my own experience tinkering with a softsim for a single F18, the resource constraints of the processing elements make it very difficult to write genuinely reusable code, beyond discovering idiomatic opcode combinations and design approaches. The only way to make your code fit is to code like Chuck- simplify brutally. It would be interesting to see how well an optimizing compiler could take more relaxed, modular Forth (or another language) and squeeze it onto an F18.
What I really want to know is whether this architecture would be suitable for dataflow, i.e. whether you could build a spreadsheet on top of it. It seems not unlike the systolic array architectures that were a hot research topic 25 years ago, and those were thought to be suitable for dataflow.
I concur with your comparison to systolic arrays- the GA144 is more flexible than most of those old designs, but has a very similar character. I think calculating something like a spreadsheet on a grid of F18s could work well, but would need a much larger array of processing elements to be effective. Interconnect is also an issue. The parallelism that can be extracted by dataflow architectures is often a product of the rate at which calculations can fan out, and a grid-based architecture enforces a strict cap. As I'm sure you are well aware, spreadsheet formulae frequently gather input from a large number of other cells and are in turn used in many places, often with only a tenuous relationship to the orthogonal neighbors of a cell.
Your discussion of re-entrancy in spreadsheets raises some interesting ideas. F18 cores in a GA144 are designed to very easily push code to their neighbors to execute- it's the basis of deploying code through the grid. The same capabilities mean that you can write code that dynamically reprograms various parts of the array at runtime. Extensive use of self-modifying code is widely regarded as deep magic nowadays, but I've often imagined programming for a huge FPGA where an OS can assemble new purpose-designed cores on the fly instead of spinning up new processes- these chips could be used in a similar way. Like I said, there's a great deal of new CS theory lurking in this design space.