Much as I love Forth and stack-based architectures, I have to admit that they are a very niche technology. To understand why they never really took off you have

Much as I love Forth and stack-based architectures, I have to admit that they are a very niche technology. To understand why they never really took off you have to put a pile of computers beside a pile of cars. The internal combustion engine is terrible. Noisy, inefficient, difficult to make, and somehow everything else we've tried is worse. More-or-less every car you've ever driven has been powered by a four-stroke four-cylinder engine. It might have had overhead valves or an overhead cam, it might have had a carburettor or electronic fuel injection, but it's still the same basic technology going back over 100 years. Why? Because it sucks, but everything else sucks worse. Two-strokes are simple but fiddly to get running over a wide range of power settings, Wankels are light and simple and don't vibrate but are incredibly fiddly to make. Likewise in computing, it turns out that you can do all sorts of clever tricks like hardware support for object-orientated memory like the Linn Rekursiv (the last known example of which is on the bottom of the Forth and Clyde Canal, in the north of Glasgow, which ought to tell you how successful a concept it was), or hardware stack-based processors like the RTX2010 and its predecessors or the HP3000 minicomputer, or CISC processors that took the first C to strange new places like the DEC VAX architecture that was planned to have single machine code instructions for solving polynomials and multiplying matrices. However, you almost never use these, and - if you actually look at what the compiler emits - you find you spend all your time shuffling values between registers and firing them into the ALU. And that's where RISC comes in. You need to move things from memory to registers (masses of registers) and back, or fire it into the ALU and get a result back quickly. Combine all these with conditionals based on the value of the status register, and you've got a very powerful machine instruction set that lends itself well to general-purpose computing. Sure, you need to write quite a lot of code to do your matrix multiply now, but that's okay because it's written in lots of small efficient steps, running on a small efficient hardware platform. So why would you implement a stack machine these days, and how? Well, the obvious use for something like Forth is in bringing up a machine from bare metal, where with a couple of kB of assembly code (just enough to set up the hardware you want to use, and implement a couple of dozen instructions) and a couple of kB of Forth code (Forth is mostly written in Forth) you can have a working environment that you can actually write code in and control your new computer. Some CPUs are particularly well-suited to this, having enough memory index registers (or like the 6809 and friends, two stack pointers) to implement the parameter and return stack, and if you've got registers left over you can do things like top-of-stack-in-register saving a memory access or two. The trick with "Forth written in Forth" is that once you've got the inner interpreter running all you need to do to write words in Forth from your assembler is define each word's header and then a list of addresses of the words you want to call. If you wanted to implement a stack machine in hardware, like if you were heavily into homebrew computing or paleocomputing, you could probably do it in a few dozen common discrete logic chips, a couple of 74LS181 ALUs (you can still buy these!) and a couple of EPROMs for the microcode.