© 2026 Reid D. McKenzie, all rights reserved.
Thanks to branch prediction, we now have nice, full pipelines. But while we can make pipelines deeper still as the Intel Pentium IV architecture is evidence building a 36 stage pipeline just hurts no matter how clever you think you are about predicting branches. So we need some new technique for doing yet more work every cycle.
Last time I signed off with a question: Given a fetch stage which runs many cycles ahead of the processor’s fully evaluated steady state, how can we ensure that the fetch stage is filling the pipeline with useful instructions and not just wasting time filling the processor with crap that will have to be thrown away?
The last processor which we invented was a register machine. Now, we are going to make another drastic revision to our processor in the name of speed, although this time we will succeed in retaining the same programming model, a feat which we did not accomplish when we discarded the stack machine.
Previously, we progressed from a single cycle stack machine to a register machine by attempting to escape the performance penalties brought upon us by attempting to access memory frequently. On this basis we reinvented the register machine as a mechanism which allows a programmer to escape the latency of accessing DRAM whenever possible by allowing for the manipulation of a small “working set” of data in “registers” without reading and writing to memory.
Stack machines are really nice and simple to describe and build. It’s also really easy to build a compiler for a stack machine because as shown above all a stack machine compiler has to do is rewrite the AST of the input program into data pushes and operation invocations.
A stack machine is arguably the simplest model for mechanical computation, and as such is still in wide use to this day under the hood of many programming languages, such as Java.
Because I am about to embark on a discussion of microchip design and examination, it is critical that we first agree on the fundamentals of microchip design and appreciate the consequent design constraints enforced upon hardware designers by manufacturing limitations and the laws of physics.
Previously I implemented a pipelined version of a simple processor for my batbridge assembly architecture. This time, I’m going to take that architecture a step further by using the Clojure.core.typed library by @ambrosebs to get some level of type safety in preparation for a binary assembler.
For those who lurk IRC channels, the initially obvious solution is to run IRSSI or your IRC connection of choice from within tmux or screen so that you can remain connected, identified and all that good stuff 24/7. Unfortunately, at least for my fellow emacs users, attaching to a screen or tmux session isn’t possible from within emacs and thus is sacralidge not acceptable in our workflow.
This time last year, I had the pleasure of taking a class in computer architecture with Ahmed Geith of IBM Research, ATX. Unlike my previous exposures to computer architecture, CS352H didn’t just present Intel x86 as the ideal architecture handed down from on high. Instead we approached computer architecture from first principles and build a modern processor from the ground up. In my hoby work developing the toothpick assembler, I use the BatBridge architecture which we invented for CS352H as my testbed because it has a simple MIPS like instruction set and I’m familiar with its binary layout. In this series of posts I’m going to walk through computer architecture and the BatBridge ISA which we developed in class, showing several Clojure simulator implementations which will grow from the single cycle design with which most programmers are familiar to the out of order and superscalar reality which many of us unknowingly use on a day-to-day basis.