ASA-EMulatR Reference Guide > Introduction > Appendix > Appendix H

This appendix documents the EMulatR Alpha pipeline — a 6-stage, single-issue, in-order pipeline implemented as a ring buffer of PipelineSlot objects managed by a rotating head pointer. The pipeline is the central execution engine of AlphaCPU: every instruction flows through 6 stages (IF → DE → IS → EX → MEM → WB), one stage per cycle, with retirement occurring strictly in program order at the WB stage.

The pipeline design makes two deliberate simplifications relative to the real Alpha EV6 hardware: it is single-issue (one instruction per cycle, peak IPC = 1.0) and it uses reverse-order stage execution (WB first, IF last) to eliminate the need for forwarding logic, hazard detection, and speculative register state. These simplifications preserve architectural correctness — instruction ordering, precise exceptions, and the Alpha memory model — while reducing implementation complexity to a level tractable for a software emulator.

H.0 Pipeline Overview

The pipeline can be understood as two complementary domains: how instructions flow through the machine on a cycle-by-cycle basis, and how speculative results are committed to architectural state. These domains are tightly coupled — the cycle mechanics determine when an instruction reaches the retirement point, and the retirement mechanics determine whether that instruction’s results become architecturally visible or are discarded.

The following table summarizes the 6 pipeline stages and their responsibilities:

Stage	Index	Name	Responsibility
IF	0	Instruction Fetch	Consumes FetchResult from IBox; populates PipelineSlot with decoded instruction and grain pointer
DE	1	Decode	Pass-through (decode completed by IBox during fetch)
IS	2	Issue	Pass-through (single-issue eliminates scheduling complexity)
EX	3	Execute	Grain execution — all real instruction work occurs here; multi-cycle operations stall at this stage
MEM	4	Memory	Register writeback via commitPending; barrier stalls held here
WB	5	Writeback / Retire	Retirement point — instruction commits or faults; architectural PC advances; flushes originate here

H.0.1 Ring Buffer Architecture

The pipeline is physically implemented as a fixed-size array of STAGE_COUNT (6) PipelineSlot objects indexed by a rotating head pointer (m_head). The head pointer always identifies the oldest instruction (the WB stage). Logical-to-physical mapping is computed as: m_slots[(m_head - logicalIndex + STAGE_COUNT) % STAGE_COUNT]. Each cycle, advanceRing() increments m_head by one — the physical slot that was WB wraps around and becomes the new IF slot, and every other slot shifts one logical position toward retirement. No instruction data is copied; only the interpretation changes.

This design gives the pipeline O(1) advancement, zero-copy slot recycling, and stable physical pointers throughout an instruction’s lifetime. The ring buffer is the mechanical foundation on which both the cycle mechanics and retirement mechanics are built.

H.0.2 Key Design Principles

Reverse-order execution. Stages execute in the order WB → MEM → EX → IS → DE → IF within each tick() call. This is not a performance optimization — it is the correctness mechanism. By processing the oldest instruction first, the pipeline achieves implicit one-cycle register forwarding (commitPending() runs before stage_EX() reads registers), older-before-younger retirement guarantees (the foundation of precise exceptions), and commit-before-execute safety (deferred results from validated instructions are committed before the current cycle’s WB instruction can fault).

One-in-one-out invariant. At steady state, exactly one instruction enters at IF and exactly one instruction exits at WB per cycle. The ring buffer enforces this mechanically — it has exactly 6 slots, and advanceRing() recycles one slot per cycle. The invariant breaks only during warmup (bubbles draining), stalls (ring frozen), and flushes (slots cleared).

Precise exceptions without speculation hardware. Because the pipeline is in-order and single-issue, and because retirement occurs only at the WB stage after all younger stages have been processed, the architectural state visible to software is always consistent. A faulting instruction at WB triggers a flush that discards all younger in-flight instructions — their results were never committed because commitPending() only runs for instructions that have already passed through WB on a prior cycle. No speculative register file, no reorder buffer, no checkpoint/restore mechanism is needed.

H.0.3 Appendix Organization

This appendix is divided into two sub-appendices that together provide the complete pipeline reference:

H.1 - Pipeline Cycle Mechanics documents what happens during a single tick() call: the steady-state snapshot of 6 instructions at 6 stages, the four phases of tick() execution, the rationale for reverse-order stage processing, pipeline warmup and drain behavior, the advanceRing() rotation mechanism, multi-cycle stall impact, and the cycle-level invariants that the pipeline maintains unconditionally.

H.2 - Pipeline Retirement Mechanics documents how speculative results become architectural state: the retirement contract at the WB stage, the commitPending() deferred-write protocol, fault detection and delivery, flush semantics (full and partial), CALL_PAL and HW_REI pipeline interactions, the architectural PC advancement rules, and the conditions under which in-flight instructions are discarded or preserved.

Together, these sub-appendices bridge the gap between the per-stage documentation in Chapter 13.6 and the complete picture of a functioning pipeline — from the moment IBox supplies a fetch result to the moment an instruction’s effects become visible to the Alpha architecture.

Appendix H – Alpha Pipeline

Appendix H – Alpha Pipeline

H.0 Pipeline Overview

H.0.1 Ring Buffer Architecture

H.0.2 Key Design Principles

H.0.3 Appendix Organization