IMHO the world has missed the real thing Chuck Moore invented, that being an alternative CPU architecture. The use of two stacks, one for data and one for sub-routine linkage had not been seen to my knowledge, before Moore.
Forth is not a language. It's an extensible instruction set. You like RISC.
Are 31 instructions "RISCy" enough? :-)
I have wondered what Chuck's CPU designs could have become if they had been given more financial and intellectual support at the level that we see for the dominant machines in the world.
Chuck's first CPU NOVIX 2000, performed multiple instructions per clock without pipelining, Interrupt handling in 2 clocks, sub-routine calls in 1 clock and return was 0 clocks on many instructions. That was done with a ridiculously small number of gates.
In later years Chuck realized that a dogmatic use of only the data stack was not ideal and he added an a address register and a loop counter register to make the machines faster.
It would be cool to see someone carry these concepts forward to see what's possible.
Ya that chip is really weird. Each core is so minimal that people struggle to understand how to use the chip. I think something less "fanatic minimalism" would be better but hey that's just me.
It's not really "fanatic". The minimalism has a purpose: less transistors so less power, smaller size and cheaper. The previous designs from Moore focused on speed at the time when MIPS was what people were looking for (e.g. the F21 [1])
I can see this chip being used instead of "system on chip" (SoC) designs. Namely GA144 + a general purpose processor (if the "business logic" of the application is too large/complicated for a GA144).
When you look at typical ARM-based SoCs, a lot of the integrated controllers are just bit-banging stuff from and to peripherals. But this is all carved in silicon, and to maximize flexibility you have a lot of additional complexity (both for the chip and the programmer) for configuration. Plus, because those chips are often used in mobile computing, you have a lot of complexity to power up and down unused parts.
It seems to me that a GA144 or two, you have more flexibility (because it's all software) and low-power usage (due to its design). What this chip probably needs is libraries to talk to common peripherals (I2C, SPI, SSC, SD card controlers, LCD controlers, flash controllers...).
Kind of a sad story but it does highlight some of the issues of something like Forth, where if you're not careful, you'll create a very powerful but also kind of difficult for anyone else to understand system.
Interestingly, there's an appearance by 'Mentifex' in the very next email.
The strength of Forth is pretty well highlighted in this post: you are free to create your own thing, quickly. But it makes it entirely personal, non-standard and alien.
Yet its simplicity definitely makes it also learnable for people who understand low-level hardware, which becomes less and less common.
It is strange for the time of the story, OP's teammates didn't pick up his system and made theirs (as a team). But yeah. When a guy comes in and is allowed to do things differently and succeed when you didn't because you had to follow arbitrary rules, you have to make a conscious effort not to take a passive-aggressive stance against them and under-estimate what they are using and doing. I know that feeling.
These days certainly aversion to risk makes it extremely difficult to go that route (although Forth, Inc. mentioned in TFA is still alive). The unavoidable complexity of today's software is not really a major problem that the author points out near the end, as you can fight with the same tools as everyone else in Forth, e.g. dealing with a stupidly complex thing like XML by just using one of the zillions of C XML library from Forth.
One thing to mention is that Forth was around the JPL probably because Chuck Moore began his career and created Forth in the astronomy field [1].
He should look into C, not C++. With Duff's device[1] trick, it becomes surprisingly lisp- and forth-y. It can be used to implement coroutines in 100% portable C[2]. And I'm pretty sure you can use the same trick to implement infinite recursion (stack on heap) and maybe even backtracking a la prolog.
> It was even worse than that. It turned out that someone in a different Litton division was using Forth for production test station control for the same reason, its efficiency and power. This person was upset that I had brought in a new dialect. He had his box of tools and would not look at mine, and we could not share code.
It's not really lisp curse (I'd argue the whole "Lisp Curse" article is incorrect, even), but as mentioned by other responders in the mailing list thread, it's organizational dysfunction if anything.
I have seen it in various forms with all kinds of problems, including being hated for the audacity of not bearing the pain of previous distro upgrade and wanting to take away some seniors ability to mess with production servers.
> Both posts makes me appreciate the joy of working on my own stuff for fun.
There was once a programmer who worked upon microprocessors. “Look at how well off I am here,” he said to a mainframe programmer who came to visit, “I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self‐consistent and easy‐to‐use. Why do you not quit your present job and join me here?”
The mainframe programmer then began to describe his system to his friend, saying: “The mainframe sits like an ancient sage meditating in the midst of the data center. Its disk drives lie end‐to‐end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle.
The programs, each unique, move through the system like a swift‐flowing river. That is why I am happy where I am.”
The microprocessor programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.
I wonder how the rest of his career went. I hope he joined some dot com and made a killing.
sigh the bit about everybody else thinking you are cheating because you actually know the best way to do it part really brings back bad memories......
I tried to introduce embedded lua at one company....another guy had just spent 2 years, though, developing his own language, which, of course, was buggy, incomplete, and ran just about 100 times slower than lua....
That bit about wondering WTF to do after being laid off AGAIN also hits pretty close to home. You spend your whole life refining your craft, and one fine day, the market decides that its value is exactly $0.00
> The primary increase in speed versus a simple, straightforward loop, comes from loop unwinding that reduces the number of performed branches, which are computationally expensive due to the need to flush — and hence stall — the instruction pipeline.
Is this generally true, or only in the case of a branch mispredict?
The early 90s defence industry recession was rough for southern California. When I moved to the bay area in 2000 (during the dot-com boom), I met folks who were still recovering from the loss of their jobs and the simultaneous real-estate value crash, and had moved to silicon valley in search of new opportunities.
Holy cow. I also worked at MDH Industries, for a few years starting in 1981 or so. That was also the first and only time I ever programming in Forth, doing embedded code for a new radiation calibration machine they were coming out with. Howard Marshall was the most brilliant analog circuit designer I have ever met; it was only decades later that I realized his connection with J. Howard Marshall the oil tycoon, Anna Nichole Smith, and all that.
Forth is not a language. It's an extensible instruction set. You like RISC. Are 31 instructions "RISCy" enough? :-)
I have wondered what Chuck's CPU designs could have become if they had been given more financial and intellectual support at the level that we see for the dominant machines in the world.
Chuck's first CPU NOVIX 2000, performed multiple instructions per clock without pipelining, Interrupt handling in 2 clocks, sub-routine calls in 1 clock and return was 0 clocks on many instructions. That was done with a ridiculously small number of gates.
In later years Chuck realized that a dogmatic use of only the data stack was not ideal and he added an a address register and a loop counter register to make the machines faster.
It would be cool to see someone carry these concepts forward to see what's possible.