This presentation introduces the Mill CPU, a novel processor architecture designed to bridge the significant performance-per-watt-per-dollar gap between general-purpose CPUs and specialized DSPs. The core challenge addressed is how to efficiently decode a very high number of variable-length instructions per cycle (up to 33) without the traditional bottlenecks of instruction cache bandwidth and parsing complexity. The solution is a "split-stream, double-ended decoding" technique where a single logical instruction stream is divided into two physical streams. These streams are laid out "head-to-head" in memory, each with its own L1 cache and program counter, allowing them to be fetched and decoded in parallel from a single branch target. This doubles the effective L1 cache capacity and bandwidth without increasing critical path latency. The presentation also briefly introduces the Mill's "belt machine" execution model, which replaces general-purpose registers with a temporal "conveyor belt" for passing operands, radically simplifying data flow and function calls.
Decoding the Mill CPU: A New Architecture for High-Performance Computing
0:00:58 - The CPU Performance Gap: The talk begins by comparing a high-end Intel Xeon CPU with a Texas Instruments DSP, using "performance per watt per dollar" as the key metric. The DSP outperforms the general-purpose Xeon by a factor of 400, a gap the Mill architecture aims to close.
0:06:23 - The Mill Architecture's Goal: The Mill is a new CPU architecture designed from scratch to deliver the high efficiency of a DSP on general-purpose computing tasks. A key feature is its ability to issue a very high number of operations per cycle (e.g., 33 for the "Gold" model) by effectively pipelining almost all loops.
0:10:21 - The Decoding Bottleneck: The central challenge of issuing so many operations is decoding them. Fixed-length instructions are too large, creating massive instruction cache pressure, while variable-length instructions (like x86) are too complex to parse at high speed.
0:16:39 - Solution Part 1: Split-Stream Decoding: The Mill architecture splits a single logical instruction stream into two physical streams. Each stream is handled by its own decoder, which drastically reduces the complexity of parsing the instructions for a given cycle.
0:20:13 - Solving the Branch Problem: To allow a single branch instruction to work on two streams, the streams are laid out "head-to-head" in memory. They start at the same address but execute in opposite directions (one with increasing addresses, one with decreasing addresses). This allows a single function pointer or branch target to control both program counters.
0:25:24 - Doubling L1 Cache Capacity: This split-stream design allows for two independent L1 instruction caches, one for each decoder. This doubles the total cache capacity and fetch bandwidth without increasing the critical wire distance between the cache and the decoder, a key physical limitation in CPU design.
0:26:52 - How Bundles are Decoded: Instructions are grouped into "bundles." Each bundle starts with a header that specifies the layout and count of operations within it. This allows the hardware to decode the bundle in a pipelined fashion from both ends simultaneously, quickly parsing all operations.
0:55:53 - The "Belt Machine" Model: The Mill is not a register or stack machine; it is a "belt machine." There are no general-purpose registers. Instead, operations drop their results onto the front of a conceptual "conveyor belt." Other operations then access their inputs temporally (e.g., "take the 3rd most recent value from the belt"), which is highly efficient for the common case of tightly-coupled data dependencies.
1:04:05 - Efficient Function Calls and Returns: The belt model makes function calls extremely cheap. A call instruction can gather many arguments from scattered positions on the caller's belt and present them as a new, clean belt to the called function in a single cycle. The hardware handles the saving and restoring of state.
1:00:46 - Load-Time Binary Compatibility: The Mill family of processors is not bit-for-bit binary compatible. Instead, it uses a system similar to the IBM System/38, where code is distributed in a higher-level format and the final machine code is generated at program install or load time, ensuring compatibility across different Mill implementations.