Stack Computers, Forth, RISC, CISC, etc.

I finished reading Stack Computers. This class of processors is a bit different from the mainstream today — neither is it like the classic RISC load/store architectures (MIPS, SPARC, PPC, etc…), nor is it like the surviving (x86) or dead (VAX) CISC architectures. In a way, it’s slightly reminiscent of the high-level language architectures of the 1970s which never even saw commercial application. They were processors designed intended to implement much of the semantics of a high-level language in hardware — quite the opposite of the RISC approach. (The difference being that RISC architectures provide a simple, orthogonal set of operations and a large register file to make it possible for modern compilers to compile high level languages with high performance results, while these high-level language architectures aimed to make the task of compilation for a particular language trivial.)

The analogy here is that most Stack Computer architectures (at the very least) have a close match to the execution model of the Forth languages, and often have opcodes which directly correspond to some common Forth primitives. However, I think the reason stack architectures are not entirely without commercial success is that most of those forth primitives are very low-level operations — it doesn’t require a lot of silicon to implement one of these stack CPUs, and it can be a very reasonable choice for an embedded system.

One downside of some of these stack CPUs is that while they all provide at least two hardware stacks (data stack and return stack), some of them do not provide a high-performance means of loading and storing from a base-pointer-plus-offset, making them poor targets for the C language since it generally accesses function arguments and local variables that way. (A few do extend the processor with enough operations to make them a decent target for C and similar languages.)

Besides reading that, I’ve been slowly trying to beat Forth into my head — the basics are incredibly simple, but doing serious projects in it requires a change of perspective. It seems that there are a number of techniques people have developed to provide abstraction and work with particular problems using domain-specific “little languages”, but it still seems like one unavoidable part of Forth is that it’s essentially untyped.

I’m still aiming to develop a small computer in an FPGA with Forth as the OS and programming language. Not for practical reasons, exactly, but as a way to learn two fairly big things at once.


  1. Posted July 3, 2008 at 9:25 am | Permalink

    Mike, I think I have a Forth computer, and by that I mean a computer on which Forth is the only language and (sort of) OS. It’s an NCR Tower circa 1984, probably a 10-20MHZ 68010 CPU with half a meg of ram and 20-40M of MFM disk, in a case a little larger than a window box fan.

    I used to manage several Tower computers running Unix, and got a reputation for being interested in collecting them when they were retired. Ran across this one at a surplus yard, and it when I booted it up it appeared to still be populated with a full set of data from the aircraft company it had belonged to, and it appeared to be running Forth.

    I’d be happy to let go of it and send it your way, along with an appropriate serial terminal, if you’d be interested in having it to complement your FPGA project. ;-)

  2. Michael Magin
    Posted July 3, 2008 at 9:32 am | Permalink

    Keith: Interesting, but due to space limitations, I’ve had to stop collecting old computers. :)

Post a Comment

Your email is never published nor shared. Required fields are marked *