4 ms·

Thank you, I enjoyed reading that very much. Actually, I enjoy reading all your Forth comments very much, so please write lots more. A few points that struck me

by gruseom 15y ago

Thank you, I enjoyed reading that very much. Actually, I enjoy reading all your Forth comments very much, so please write lots more. A few points that struck me: getting rid of mode-switching words makes source code more compact That's a big deal, given that source code size is the best measure of complexity we have and the best predictor of errors we have. the GA144 uses essentially antique fab technology. With no changes to the design and the latest fabrication techniques you could (theoretically) get an order of magnitude more cores A smart approach. Prove the thing useful first, with the knowledge that there's another order of magnitude waiting to be had. programming them is very difficult and requires incredible attention to detail Do we know any programs that have been written for them? What does Chuck write? Do they provide a foundation for building application-oriented languages in the classic Forth style? I think that if any language other than Forth could be compiled for the machines it might be an array processing language like APL. 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 work on the problem of data parallelism in spreadsheets, and the thought of being able to apply hardware like this to it makes me salivate. Okay, not just salivate, drool. But we're probably years away from being able to figure out how to do that. Capturing even the low-hanging data parallelism in spreadsheets with any generality has proven surprisingly difficult, and I don't have a good gut feeling for whether the software techniques we've developed to do it would translate naturally to the GA chips. If they could, it would be a dream come true, because we could first prove the software on traditional hardware and then "go native" later. Obviously you couldn't just port already-written code to a platform that radically different. The question is whether the key concepts would survive or whether you'd have to rethink everything from scratch. The environment we're building is highly reactive. It doesn't just compile code and then run it; if the computations produce new formulae, those have to go back to the top level, get analyzed again, and then be computed in turn. That sort of re-entrancy turns out to be a big deal for spreadsheets, and most of the important constructs depend on it. I don't know if the GA chips would feel very good about that kind of dynamism; perhaps it would be more like "Damn, you just got all the code laid out and now you're shoving us all around again."

RodgerTheGreat 15y ago
I enjoy reading all your Forth comments very much, so please write lots more. 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.html 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 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.

by gruseom 15y ago

RodgerTheGreat 15y ago

I enjoy reading all your Forth comments very much, so please write lots more. 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.html 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 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.