A Forth Story (1995)(groups.google.com)
groups.google.com
A Forth Story (1995)
https://groups.google.com/g/comp.lang.forth/c/ThWiGXwKqv4
9 comments
Correction: The CPU was named NOVIX 4016.
The next iteration was the Harris RTX2000.
A quick history of this work is contained in this thesis by Charles Eric LaForest.
http://fpgacpu.ca/publications/Second-Generation_Stack_Compu...
A quick history of this work is contained in this thesis by Charles Eric LaForest.
http://fpgacpu.ca/publications/Second-Generation_Stack_Compu...
This company purports to sell a forth inspired 144 core chip I haven’t seen discussed much at all;
https://www.greenarraychips.com/
Apparently they had angel funding of some sort at some point.
https://www.greenarraychips.com/
Apparently they had angel funding of some sort at some point.
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...).
[1] https://www.ultratechnology.com/chips.htm
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...).
[1] https://www.ultratechnology.com/chips.htm
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.
That guy was famous: https://www.nothingisreal.com/mentifex_faq.html
Interestingly, there's an appearance by 'Mentifex' in the very next email.
That guy was famous: https://www.nothingisreal.com/mentifex_faq.html
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].
[1] https://colorforth.github.io/HOPL.html
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].
[1] https://colorforth.github.io/HOPL.html
He seems to have passed away this year.
https://obituaries.seattletimes.com/obituary/arthur-murray-1...
https://obituaries.seattletimes.com/obituary/arthur-murray-1...
Sad. He seemed like he had some real intelligence, but also a few wires crossed.
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.
[1] https://en.m.wikipedia.org/wiki/Duff%27s_device
[2] https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
[1] https://en.m.wikipedia.org/wiki/Duff%27s_device
[2] https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
> 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.
That sounds like the Lisp Curse¹.
1. <https://www.winestockwebdesign.com/Essays/Lisp_Curse.html#ma...>
That sounds like the Lisp Curse¹.
1. <https://www.winestockwebdesign.com/Essays/Lisp_Curse.html#ma...>
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.
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.
That reminded me of this HN post from yesterday[1]. It has quotes like
> Why is it that innovations require heroics to occur in our organization
[1] https://news.ycombinator.com/item?id=40749754
Both posts makes me appreciate the joy of working on my own stuff for fun.
> Why is it that innovations require heroics to occur in our organization
[1] https://news.ycombinator.com/item?id=40749754
Both posts makes me appreciate the joy of working on my own stuff for fun.
> 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.
— The Tao of Programming, Geoffrey James
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.
— The Tao of Programming, Geoffrey James
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
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?
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.