Quite a story, and it seems it does not have a happy ending, but for all the wrong reasons.
About 2/3rds in (past the 'read more') the Novix rates a mention. I think that that is possibly the most underrated CPU design that ever saw the light of day, at the time it was so out of the ordinary that only very few people knew what to do with it.
A high level language (forth is by most definitions a high level language) directly executed by the CPU.
At the time I worked for a company called dadadata in the Netherlands, they were in the process of developing a bunch of real time software to process video images for classification and recognition (1988 or thereabouts). The Novix chip arrived and would have definitely blown the socks of anything that I could have done with a regular PC at the time, if not for one small problem: someone dropped a dime into the power supply and the whole development kit was toast. A couple of all nighters later we had a working reproduction of the code in 'C' and that was used for the customer demonstrations. Still, the power of that little chip is something I'll never forget and it is a pity that the Novix and its successor which iirc was called shboom never made real headway. The forth code for the novix was probably only about 10% or so in size of the equivalent C code. The head forth honcho there called C sneeringly a 'great' language.
There is still hope, even today that one day that power will finally be available in some package that sees wide distribution, the heritage of Novix lives on in the greenarrays line (which is now shipping dev boards and chips).
I took a close look at Green Array recently and found a few blogs from engineerings who were beginning to play with them. At first they seemed too good to be true, but it appears that the architecture is only a good match for tasks that can easily be parallelized by hand. Computer vision would be one of those tasks, but then is rewriting CV code from scratch on a new architecture something you can viably do anymore?
Anyway, I hope these find a niche so that this kind of architecture might one day make a comeback. The advantages are staggering.
It forces you to structure your application as tiny communicating processes which you route by hand. You're actually coding quite close to the hardware. When you want a process to communicate with another – correct me if I'm wrong somebody – you can only communicate processes that are physically adjacent on the chip and you actually write something like "the one to the left/right". Each process is very small and one of the blogs I looked at was very much about optimizing code-size to fit in such a small place. This results in a situation where if your problem does not easily map to this kind of architecture, then you have no other option.
But the same thing can be said of programming at a low level with a Von Neumann architecture. Such architectures are an exceptionally bad match for what the Green Array (dataflow) architecture is good for, namely highly concurrent applications involving processing flows of data such as sensor networks, computer vision, and all manner of routers.
The way that Von Neumann systems handle this problem is by having high-level programming languages (like C), which gives you some level of abstraction from the hardware so that you can model your program however you like and force it to map to the architecture, even if the problem intrinsically doesn't map well. This is why parallel programming is a hard problem. It's not actually a hard problem (well, it could be intrinsically harder), it's just a hard problem for architectures that are not designed for it. On a Green Arrays chip, parallelism is the most natural thing in the world.
Currently Green Arrays has no equivalent of C, and as I understand, this is unlikely to change as the philosophy of Forth is to stay close to the metal and make that an enjoyable experience. That's probably a good thing actually. it's more efficient to design problems to fit the hardware than to use one architecture for absolutely everything as we've been doing for the past 40 years or whatever (with notable exceptions like the Transputer, the Connection Machine, Xmos XCore chips and FPGA's to a certain extent).
Your description of inter-core communication in the GA144 is on the money. In addition to the challenge of mapping your problem to the grid, you have the interesting problem of initializing all those cores with their programs, since it's only possible to do serial communication with a few cores on the edges of the chip. In one of his recent "fireside chats", Chuck discussed how he first fills the chip with a zigzag pattern of of programs that act as a pipeline and then pumps the desired binary along, replacing the scaffolding backwards toward the serial port he's using. It reminds me a bit of the design of biological systems- not only do you have to write a program, you have to make it self-assemble.
If anybody's interested in the GA144, GreenArrays recently put up a series of free self-paced courses about the architecture: http://school.arrayforth.com/
That sounds awesome – reminds me of cellular automata – but also, um, I just can't see Joe Engineer figuring that out. My first thought when I started researching Green Arrays was that this was an amazing idea that I would love to see take off, but their UX and marketing will really get in the way. Not like that have much competition though – the entire microcontroller world is hopelessly obscure with the exception of Arduino and all of the projects that it inspired.
Fortunately Chuck's already done the nasty parts and you can (presumably) leverage his upload code if you use GreenArrays' tools, but there's always the possibility that your code will require some very specific sequence of node initialization and you'll have to wade in and do it manually. I agree that this tech will probably never be mainstream. If I had an unlimited supply of free time I would be very tempted to develop some third-party devtools for GA chips- I enjoy programming in Forth and I could get used to the F18 instruction set, but using a custom keyboard layout and ditching my text editors and source control systems in favor of a block editor is pretty hard to swallow.
the entire microcontroller world is hopelessly obscure with the exception of Arduino and all of the projects that it inspired
I dunno, it doesn't seem that bad to me. Cortex-M microcontrollers use the ARM instruction set and seem to be gaining ground. I've personally used PIC24 (the 16bit PIC microcontrollers from Microchip) and various 8bit Atmel ones without using Arduino. The 8bit PIC16 still seems reasonably popular too.
Certainly none are as popular or accessible to beginners than Arduino, but is it really hopelessly obscure? Hell, if I can get started with PIC24, then surely anyone can! (Though I do admit I've started doing prototyping on Arduino lately because the wealth of sample code saves tons of time and headaches, while before the PIC24 was my go-to microcontroller. I have used the AT90USB162 and some Atmega micros for some work too and will probably use them much more in the future).
How do the boards compose? Is communication between the edge cores of two internal boards of a grid different from communication between two cores on the same board?
I don't know as much about that, but based on the whitepapers[1] the GA144s aren't designed to tile. They have a whole bunch of different kinds of peripherals attached to different nodes like analog I/O, busses for RAM controllers and so on. The GA144 is just a network of tesselated F18 cores, though, so if there was some kind of application available that could use a larger grid of them it might be possible to work with GreenArrays to develop the silicon- they wouldn't have to start over from scratch.
Wow that sounds amazing. Thanks for that. I can think of how such an architecture would be useful to many types of Machine Learning algorithms. Especially agent and deep learner type networks, also meta-heuristic approaches. AI is a lot about architecture and I would not be surprised if a breakthrough was built on a machine like this.
So that's the thing for me: I know there's this huge payoff if I can successfully use the GA144, but I also know that it's going to be a GIANT pain in the ass.
I got one of the first Apple II computers (serial number 71) and after I wrote the silly little Chess program that Apple provided on a demo cassette tape, I was considering getting FIG Forth running on the Apple II.
One Saturday morning I was in the local Computer Land store in San Diego and was talking about my just beginning side project of porting Forth. One of the new sales guys got really pissed off and started ranting about why would I waste my time on that, lots of people were doing it, etc. The owners of the store Dan and Dave were friends and they glared at their sales guy, and the conversation turned to more pleasant topics.
I decided that afternoon that the obnoxious guy was perhaps right and started instead spending time with Bill Budge's cool 3D library for the Apple II.
A few months later someone came out with an inexpensive product that was Forth ported to the Apple II and I always wondered if the sales guy who got so mad that Saturday had any involvement with that product.
Unlikely. Porting Forth is not a few months long project ;-) Most of Forth is usually written in Forth anyway - all you have to do is to port some primitives and you're set.
In any case, I did a lot of interesting stuff with Paul Lutus' GraFORTH and TransFORTH. Much more mileage than I ever got out of Aztec C.
BTW, I probably shouldn't say that, but that chess program was most likely the one that came on the boot disk of my first Apple II clone (I live in Brazil and it was impossible - as in "a fellony" - to get a computer from abroad). Thanks for the many hours of challenging chess. I never had the patience to play against humans, however. Meat is too slow. ;-)
One of the problems with our field is the fixations that programmers, and organizations, develop with particular solutions. They form a really bad alliance with language/platform specialization that leads to a reinforcing spiral which shuts experienced, adaptable programmers out of the market. If Asia were not available to pick up the slack, the problem might be more noticeable.
In some alternate universe, the Forth/Forth++ programmers are sneering at the silly die-hard C programmers. :-)
Back in the time that most of the story takes place, there was not the glut of well-developed, thoroughly documented, cross-platorm tools with helpful user communities that we have today. Every machine had its own set of 2 or 3 first-class development development packages (i.e., pascal, cobol, basic, fortran: choose any two).
So when a small, elegant cross-platform development solution like Forth or C comes along, folks would get really excited about it. If you found something you could be productive with, and could take it from job to job, it was hard not to. It just didn't make sense to use the best tool for that particular machine when you knew there was a high probability that you might never use that vendor's hardware for any other project.
Honestly, maintaining the stack in your head is a skill that can be learned with practice. In my own experience, it was very hard at the beginning but over the course of a few weeks it became second nature. You get used to idiomatic ways of doing things- arranging expressions so that they don't become deep, factoring words apart as a means of reducing the number of elements you care about in a given context, when to use a variable or two to untangle a complex expression.
From the debugging side, well-factored code consists primarily of short pure functions with a very small number of code paths. This couldn't be a more perfect scenario for TDD. In my own projects I use an extremely simple unit testing system called the Test Anything Protocol (TAP). Here's an example of a fixture:
Forth is the as simple as beautiful as Lisp and Smalltalk are. It's, in fact, vastly used... in the form of PostScript, which based on Forth. Back in the Apple ][ days, Forth became popular as GraFORTH. As a langue, today it has its limitations, but it's not impossible that Forth will have the Clojure that Lisp got and start its second life.
26 comments
[ 3.6 ms ] story [ 1849 ms ] threadAbout 2/3rds in (past the 'read more') the Novix rates a mention. I think that that is possibly the most underrated CPU design that ever saw the light of day, at the time it was so out of the ordinary that only very few people knew what to do with it.
A high level language (forth is by most definitions a high level language) directly executed by the CPU.
At the time I worked for a company called dadadata in the Netherlands, they were in the process of developing a bunch of real time software to process video images for classification and recognition (1988 or thereabouts). The Novix chip arrived and would have definitely blown the socks of anything that I could have done with a regular PC at the time, if not for one small problem: someone dropped a dime into the power supply and the whole development kit was toast. A couple of all nighters later we had a working reproduction of the code in 'C' and that was used for the customer demonstrations. Still, the power of that little chip is something I'll never forget and it is a pity that the Novix and its successor which iirc was called shboom never made real headway. The forth code for the novix was probably only about 10% or so in size of the equivalent C code. The head forth honcho there called C sneeringly a 'great' language.
There is still hope, even today that one day that power will finally be available in some package that sees wide distribution, the heritage of Novix lives on in the greenarrays line (which is now shipping dev boards and chips).
http://www.greenarraychips.com/
To kill forth and the concepts behind it permanently will take a lot of garlic and stakes, I think it will always have its champions.
Anyway, I hope these find a niche so that this kind of architecture might one day make a comeback. The advantages are staggering.
Could you expand on that?
But the same thing can be said of programming at a low level with a Von Neumann architecture. Such architectures are an exceptionally bad match for what the Green Array (dataflow) architecture is good for, namely highly concurrent applications involving processing flows of data such as sensor networks, computer vision, and all manner of routers.
The way that Von Neumann systems handle this problem is by having high-level programming languages (like C), which gives you some level of abstraction from the hardware so that you can model your program however you like and force it to map to the architecture, even if the problem intrinsically doesn't map well. This is why parallel programming is a hard problem. It's not actually a hard problem (well, it could be intrinsically harder), it's just a hard problem for architectures that are not designed for it. On a Green Arrays chip, parallelism is the most natural thing in the world.
Currently Green Arrays has no equivalent of C, and as I understand, this is unlikely to change as the philosophy of Forth is to stay close to the metal and make that an enjoyable experience. That's probably a good thing actually. it's more efficient to design problems to fit the hardware than to use one architecture for absolutely everything as we've been doing for the past 40 years or whatever (with notable exceptions like the Transputer, the Connection Machine, Xmos XCore chips and FPGA's to a certain extent).
If anybody's interested in the GA144, GreenArrays recently put up a series of free self-paced courses about the architecture: http://school.arrayforth.com/
I dunno, it doesn't seem that bad to me. Cortex-M microcontrollers use the ARM instruction set and seem to be gaining ground. I've personally used PIC24 (the 16bit PIC microcontrollers from Microchip) and various 8bit Atmel ones without using Arduino. The 8bit PIC16 still seems reasonably popular too.
Certainly none are as popular or accessible to beginners than Arduino, but is it really hopelessly obscure? Hell, if I can get started with PIC24, then surely anyone can! (Though I do admit I've started doing prototyping on Arduino lately because the wealth of sample code saves tons of time and headaches, while before the PIC24 was my go-to microcontroller. I have used the AT90USB162 and some Atmega micros for some work too and will probably use them much more in the future).
[1]http://www.greenarraychips.com/home/documents/greg/PB001-100...
Oh well. Where there's muck, there's brass.
Why do you put C in quotes here?
One Saturday morning I was in the local Computer Land store in San Diego and was talking about my just beginning side project of porting Forth. One of the new sales guys got really pissed off and started ranting about why would I waste my time on that, lots of people were doing it, etc. The owners of the store Dan and Dave were friends and they glared at their sales guy, and the conversation turned to more pleasant topics.
I decided that afternoon that the obnoxious guy was perhaps right and started instead spending time with Bill Budge's cool 3D library for the Apple II.
A few months later someone came out with an inexpensive product that was Forth ported to the Apple II and I always wondered if the sales guy who got so mad that Saturday had any involvement with that product.
Unlikely. Porting Forth is not a few months long project ;-) Most of Forth is usually written in Forth anyway - all you have to do is to port some primitives and you're set.
In any case, I did a lot of interesting stuff with Paul Lutus' GraFORTH and TransFORTH. Much more mileage than I ever got out of Aztec C.
BTW, I probably shouldn't say that, but that chess program was most likely the one that came on the boot disk of my first Apple II clone (I live in Brazil and it was impossible - as in "a fellony" - to get a computer from abroad). Thanks for the many hours of challenging chess. I never had the patience to play against humans, however. Meat is too slow. ;-)
Indeed; an 'intermediate' Forth programmer is defined as someone who has written their own Forth implementation but nothing else in the language.
Back in the time that most of the story takes place, there was not the glut of well-developed, thoroughly documented, cross-platorm tools with helpful user communities that we have today. Every machine had its own set of 2 or 3 first-class development development packages (i.e., pascal, cobol, basic, fortran: choose any two).
So when a small, elegant cross-platform development solution like Forth or C comes along, folks would get really excited about it. If you found something you could be productive with, and could take it from job to job, it was hard not to. It just didn't make sense to use the best tool for that particular machine when you knew there was a high probability that you might never use that vendor's hardware for any other project.
From the debugging side, well-factored code consists primarily of short pure functions with a very small number of code paths. This couldn't be a more perfect scenario for TDD. In my own projects I use an extremely simple unit testing system called the Test Anything Protocol (TAP). Here's an example of a fixture:
https://github.com/JohnEarnest/Mako/blob/master/lib/Test/tes...