|
<< Click to Display Table of Contents >> Navigation: ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 4 - Functional Execution Domains ("Boxes) > 4.11 Summary |
Functional Execution Domains ("Boxes") provide a clean, scalable execution architecture that mirrors Alpha AXP design intent without replicating hardware complexity.
IBox — Instruction fetch and decode (842 lines, front-end only)
EBox — Integer and control-flow execution (2,257 lines, 93 methods)
FBox — Floating-point execution (2,639 lines, 236 methods)
MBox — Memory access and translation (2,256 lines, load/store/LL-SC)
CBox — Serialization, barriers, coherency (1,345 lines, 29 methods)
PalBox — Privileged execution (2,122 lines, 175 methods)
Total: 11,461 lines across six Box headers.
1.Boxes are functional domains, not execution stages — they define what work occurs, not when
2.Grains own execution control; Boxes perform the work — grain->execute(slot) dispatches to the appropriate Box
3.EX stage is where all real work occurs — Boxes execute synchronously within EX
4.CBox enforces global correctness — all ordering, barrier, and coherency rules live here
5.PAL code is first-class, not a special case — it executes through the normal pipeline in PAL mode
6.Six normative interaction rules prevent architectural drift — IBox never mutates state, EBox never does I/O, MBox never decides ordering, CBox never computes, PalBox always serializes, Boxes never own time
7.This design enables correctness first, optimization later
See Also: Chapter 5 - Memory System Architecture (next chapter).