A Forth Story (1995)

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.

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

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

> 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...>

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.