I return to this essay about once a year, when I hear the siren-song of minimalism and am tempted to implement a Forth CPU. It's situated exactly in the no-mans

I return to this essay about once a year, when I hear the siren-song of minimalism and am tempted to implement a Forth CPU. It's situated exactly in the no-mans'-land between FORTH and "C" camps and effortlessly slides between pragmatic and idealistic considerations. It emphasizes the distinction between the lure of toolbuilding (making a Forth, making a CPU) and actually solving the problems these tools are intended to solve. The comments on word sizes and problem-shifting are spot-on. It's an excellent essay, and I wish there were more like it. By day, I'm an FPGA coder. (The ASIC situation rhymes, more or less.) From the perspective of implementing small CPU architectures: register files are not the problem in the way you'd expect. A modern FPGA has primitives that implement 32- or 64-register files with remarkable efficiency, in 2-, 4-, or 8-port varieties. Midrange FPGAs are now fast enough that a lightly pipelined RISC CPU performs well enough; there's no need to aggressively pipeline a CPU for normal clock rates (100 to 250 MHz) any more, and little motivation for exotic architectures. The MicroBlaze (Xilinx) or NIOS-II (Altera) soft core CPUs are so boringly effective they've forced ARM to license their designs for FPGAs for free. For smaller state-machine-class problems, the PicoBlaze is an interesting, minimal RISC. For most of us, CPUs are solved problems and the frontier has shifted towards cache-coherency, networking and other more interesting arenas. I love the idea of stack machines in the right contexts (PostScript, FORTH, Java, you name it), but it's hard to disagree with the essay's conclusions.