|
<< Click to Display Table of Contents >> Navigation: ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 4 - Functional Execution Domains ("Boxes) > 4.2 Box-Based Execution Model |
In EMulatR, Boxes are not pipeline stages and not execution units in the scheduling sense. They are functional domains that group related architectural behavior. EMulatR adopts the Alpha AXP Box model not as a microarchitectural simulation, but as a clean architectural responsibility partitioning.
Key principle: Boxes are semantic domains, not pipeline stages. They encapsulate what kind of work is being performed — not when it is performed.
Boxes do not own time, do not schedule instructions, do not advance the pipeline, and do not store architectural state independently. Instead:
•Boxes are invoked by grains during the Execute (EX) stage
•Boxes operate synchronously within the caller's cycle
•Boxes act on state owned by AlphaCPU, the pipeline slot, or shared subsystems
•Boxes write results into the pipeline slot for writeback
Think of a Box as a capability boundary, not a control boundary.
A common misconception is to equate Boxes with pipeline stages. This is explicitly incorrect in EMulatR:
Pipeline Stages — control when an instruction advances (timing and ordering)
Execution Boxes — define what semantic work occurs (meaning and side effects)
90% of real work occurs in grain->execute() during the EX stage, but execution logic is delegated to the appropriate Box:
Pipeline EX Stage
|
+--> grain->execute(slot)
|
+--> EBox / FBox / MBox / CBox / PalBox
The pipeline controls ordering and serialization. Boxes control meaning and side effects.
Without Boxes, instruction execution would devolve into large monolithic execute functions, unmanageable cross-cutting logic, and tight coupling between unrelated subsystems. Boxes provide:
•Clear separation of concerns — each domain has one job
•Testable functional domains — Boxes can be verified independently
•Architectural fidelity to Alpha AXP documentation
•Predictable stall behavior and clear fault attribution
•A clean anchor for future optimizations (JIT, vectorization, async devices)
See Also: 4.3 Execution Flow: Grains, Pipeline, and Boxes; 4.10 Cross-Box Interaction Rules.