Modern processors are extraordinarily capable, but much of their silicon is devoted to organizing work rather than performing it. They rename registers, reorder instructions, predict branches, track dependencies, and clean up whenever speculation goes sideways. It is impressive engineering, although it can resemble hiring an entire airport staff to deliver one sandwich.
The Mill CPU architecture proposes a different arrangement. Instead of asking complicated hardware to discover parallel work while a program runs, Mill relies heavily on the compiler and a component called the specializer. It replaces general-purpose registers with a “belt,” issues many operations together, and introduces unusual approaches to memory, function calls, prediction, and security.
This human-friendly interview is a synthesized explanation of ideas presented in public Mill interviews, technical talks, documentation, patents, compiler material, and broader research on VLIW and out-of-order processors. The answers are paraphrased for clarity rather than presented as direct quotations.
Inside the New Mill CPU Architecture
Question: What is the Mill CPU in plain English?
Answer: Mill is a clean-sheet architecture for general-purpose processors. Its designers want it to run ordinary compiled languages while approaching the power efficiency associated with digital signal processors, or DSPs.
A conventional high-performance CPU receives a stream of instructions and dynamically searches for operations that can run in parallel. The Mill uses a very wide, statically scheduled model. Its software tools decide in advance which operations should start together and where their inputs will come from.
Think of a conventional out-of-order processor as a restaurant where the kitchen reorganizes every ticket after it arrives. Mill asks the compiler to prepare a detailed cooking schedule before the order reaches the kitchen. This can simplify the kitchen, although it makes the planning software much more important.
Question: Why redesign the CPU instead of improving x86 or Arm?
Answer: Incremental improvements must preserve decades of compatibility. Modern x86 processors, for example, can translate complex instructions into internal micro-operations and then use register renaming, scheduling queues, reorder buffers, and speculative execution to keep their functional units busy.
Those techniques work remarkably well. They also consume transistor area and energy. The Mill project starts from the argument that only part of a processor’s power budget is spent on arithmetic. A considerable portion is spent fetching, decoding, moving, scheduling, and remembering operations.
Mill attempts to remove some of that administrative machinery. It does not claim that arithmetic suddenly becomes magical. Two plus two remains stubbornly committed to being four. The proposed advantage comes from making the logistics around that addition less expensive.
Question: What is the famous Mill “belt”?
Answer: The belt is the Mill architecture’s primary mechanism for passing temporary results between operations. It replaces the programmer-visible general-purpose registers found in conventional register machines.
When an operation produces a result, that value appears at the front of the logical belt. New results push older values farther back. Instructions refer to values by their relative position, and sufficiently old values eventually fall off the end. Long-lived data can be moved to a byte-addressable scratchpad.
Suppose a program performs these operations:
- Add 4 and 5, producing 9.
- Multiply 3 and 7, producing 21.
- Add the two recent results, producing 30.
On a register machine, the compiler might place 9 in one named register and 21 in another. On Mill, the operations naturally deposit both values on the belt. The third operation refers to them by recency. Destination naming is implicit because every new result goes to the front.
The belt resembles a stack in diagrams, but it is not a traditional stack machine. Multiple operations can produce multiple results in one cycle, values can be consumed without being removed, and the physical implementation does not need to shift a giant row of bits every time a result arrives. The conveyor belt is a programming model, not tiny luggage equipment hidden inside the chip.
Question: Why is single assignment important?
Answer: A belt value never changes after it is produced. This single-assignment rule removes write-after-read and write-after-write hazards from the programmer-visible operand model.
Conventional processors use register renaming partly because several instructions may appear to update the same architectural register. The hardware maps those apparent updates to different physical locations, tracks dependencies, and eventually commits the correct state. Since Mill results are created once rather than repeatedly overwriting named registers, much of that renaming problem disappears.
This does not mean Mill has no internal storage or operand-routing hardware. It means the architecture does not expose a conventional mutable register file and therefore can organize that storage differently.
Question: Is Mill simply another VLIW processor?
Answer: Mill belongs to the broad very-long-instruction-word tradition because one instruction can contain numerous independent operations selected by the compiler. However, its belt, instruction encoding, phasing, memory behavior, and binary specialization distinguish it from classic VLIW designs.
Different operations are assigned to execution slots associated with functional pipelines. A larger Mill family member may have more slots and issue more operations per cycle than a smaller one. Published architectural material describes high-end configurations capable of issuing more than 30 operations in a cycle, but that number represents available widthnot a promise that every program will continuously find 30 useful things to do.
The design also uses split-stream encoding. Conceptually, operations are encoded from opposite ends of an instruction bundle, allowing very wide instructions to remain variable in size without requiring a painfully sequential decoding process.
Question: Where does the compiler fit into all this?
Answer: The compiler is essential because Mill hardware does not perform conventional dynamic instruction scheduling. Software must understand operation latencies, available functional units, belt positions, and dependencies.
The proposed toolchain separates generic compilation from machine-specific scheduling. A compiler produces a dataflow-oriented intermediate representation known as genAsm. The specializer later turns that representation into conAsm and executable code for a particular Mill family member.
This arrangement addresses an old VLIW portability problem. A binary scheduled for one machine width may perform poorly or fail to fit another configuration. Mill’s intermediate representation can be distributed in a more general form, then specialized when the target processor is known.
The tradeoff is obvious: simpler scheduling hardware requires sophisticated software. If the specializer makes weak decisions, the processor cannot summon a reorder buffer from behind the curtains to rescue the schedule.
Question: How does Mill handle slow memory?
Answer: Memory latency is one of the hardest problems for a statically scheduled processor. An arithmetic operation may have a predictable latency, but a load can hit a nearby cache or wander all the way to main memory like a tourist refusing to ask for directions.
Mill addresses this with deferred loads. The compiler can initiate a load before its result is needed and specify when that result should retire onto the belt. If the data arrives early, a retire station holds it. If it arrives late, execution may wait when the scheduled retirement point is reached.
This separates requesting data from consuming it and allows useful work to be placed between those events. The architecture also proposes byte-granular cache-validity mechanisms and techniques intended to reduce unnecessary initialization, write traffic, and false sharing.
These are architectural solutions to real bottlenecks, but their practical effectiveness depends on workloads, cache organization, compiler decisions, clock targets, and physical implementation.
Question: What happens when the CPU guesses the wrong branch?
Answer: Mill organizes control flow around extended basic blocks, which have one entry and potentially several exits. Rather than looking only at each individual conditional branch, its prediction system attempts to predict which exit will be taken and can run ahead to fetch future instruction blocks.
A short pipeline is intended to make recovery less expensive. Mill material commonly describes a four-cycle misprediction penalty for representative configurations. That is a design figure, not a universal law: the exact cost depends on the family member and implementation.
Operand metadata also supports speculation. A “Not a Result” state can travel with a value, allowing speculative operations to proceed without immediately raising an exception. A fault matters when the result reaches an operation that must commit a visible effect. In simplified terms, the architecture can carry a sealed envelope labeled “possible trouble” until somebody actually needs to open it.
Question: How are function calls and security different?
Answer: Function calls are integrated with the belt. A called function receives explicitly passed arguments, while the caller’s temporary state can be preserved by hardware-supported mechanisms and restored on return. This reduces caller-save and callee-save traffic and can prevent unintended temporary values from leaking across call boundaries.
Mill also describes protection domains called turfs and controlled entry points called portals. These mechanisms are intended to support fine-grained isolation and less expensive communication across protection boundaries. Additional design features include separate control-flow state, hardware-managed stack structures, and memory that appears zeroed before initialization.
Such features can reduce familiar attack surfaces, including some forms of buffer-overflow exploitation and return-oriented programming. They do not make software invulnerable. Security ultimately depends on the complete implementation, operating system, compiler, firmware, verification process, and response to side-channel research.
Mill Versus a Conventional Out-of-Order CPU
| Design Area | Conventional High-Performance CPU | Mill Approach |
|---|---|---|
| Temporary operands | Architectural registers mapped to physical registers | Single-assignment belt plus scratchpad |
| Scheduling | Hardware discovers ready operations dynamically | Compiler and specializer schedule operations statically |
| Parallel issue | Superscalar issue from a dynamic window | Very wide instruction containing scheduled operations |
| Loads | Load queues and out-of-order machinery hide latency | Deferred issue and scheduled retirement |
| Binary portability | Stable ISA binary interpreted by different microarchitectures | Generic representation specialized for a family member |
| Primary goal | High performance with broad compatibility | High instruction-level parallelism with lower hardware overhead |
Can the Mill Architecture Deliver Its Claimed Advantages?
The ideas are technically interesting because they attack connected problems rather than replacing one instruction format and declaring victory. The belt affects operand naming, calls, spilling, scheduling, and encoding. Deferred loads complement static scheduling. The specializer connects a configurable processor family to software portability.
However, an elegant architecture is only the opening chapter. A commercially successful CPU also requires verified silicon, manufacturing partners, development boards, operating systems, debuggers, optimized libraries, applications, long-term support, and competitive benchmark results. Established architectures benefit from ecosystems built over decades.
Mill’s published performance and efficiency figures should therefore be treated as design goals or project claims unless supported by independently tested implementations. Patents, simulators, talks, and generated hardware descriptions demonstrate substantial engineering work, but they are not substitutes for measurements from broadly available production processors.
Experience Notes: Learning to Think Like a Mill Processor
The most useful experience when studying the Mill architecture is to stop thinking about permanent boxes labeled R1, R2, and R3. Imagine writing a short expression on a whiteboard. Each result receives no enduring name; you simply refer to the newest result, the next-newest result, and so forth. At first this feels like someone removed the drawer labels from your workshop. After a few examples, the dataflow becomes surprisingly visible.
Consider calculating the distance traveled by multiplying speed by time and then adding an initial position. On a register machine, an assembly sequence explicitly selects destination registers. With the belt model, the multiplication result appears automatically, followed by the addition result. The compiler’s job becomes keeping each producer near its consumer so useful values do not age off the belt. When a value must survive a longer stretch of code, the scratchpad becomes its parking garage.
A second revealing exercise is scheduling operations on paper. Start a three-cycle multiplication, then place independent additions in the following cycles. The multiplication pipeline can accept new work before the first product finishes. This makes “wide issue” easier to understand: Mill is not necessarily completing every operation instantly; it is launching many operations through multiple pipelines according to a predetermined timetable.
The exercise also exposes the design’s pressure points. Add an unpredictable memory access, and the neat schedule suddenly develops a hole. Deferred loads offer an answer by launching the request early and assigning a future retirement point. Yet the compiler must estimate enough distance to cover normal latency without delaying the result unnecessarily. Real programs contain aliases, indirect calls, cache conflicts, and data-dependent loops, so scheduling is less like arranging dominoes and more like arranging caffeinated cats.
Another practical lesson comes from comparing Mill with contemporary processors. It is tempting to ask which architecture is “better,” but that question lacks a workload, power budget, manufacturing process, compiler maturity level, and cost target. A wide statically scheduled core might excel where the compiler exposes predictable parallelism. Dynamic hardware may respond better when runtime behavior is difficult to anticipate. Good engineering lives in those qualifications.
Finally, the Mill story demonstrates that CPU innovation is an ecosystem challenge. Designing the belt is difficult, but so are building a compiler, specializing portable code, verifying generated logic, porting an operating system, and persuading developers to care. Studying the architecture leaves a valuable impression: the instruction set is only one layer of a processor’s personality. Tooling, memory behavior, security, physical design, and software compatibility determine whether a clever idea becomes a useful machine.
Conclusion: A CPU That Moves Complexity to a New Address
The new Mill CPU architecture is best understood as a redistribution of complexity. It removes conventional registers from the programming model, reduces dependence on dynamic scheduling hardware, and gives the compiler far more responsibility. The belt names values by production order, very wide instructions expose parallel work, deferred loads manage uncertain memory latency, and the specializer adapts generic code to individual processor configurations.
Whether Mill can outperform mature alternatives in shipping systems requires independently testable implementations and a complete software ecosystem. Even without that verdict, it remains a fascinating architectural case study. It asks a question worth asking whenever an industry has optimized the same basic pattern for decades: what if the expensive machinery is solving a problem created by the model itself?
