<< Click to Display Table of Contents >> Navigation:  ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 1 - System Overview > 1.6 Control and Data Flow

At a high level, execution flows through the system as follows:

 

1.Instructions are fetched and decoded by the IBox frontend. Decoding produces a grain — a cached instruction abstraction that is reused on subsequent fetches of the same pattern.

2.The grain enters the six-stage pipeline and advances through Fetch, Decode, Issue, Execute, Memory, and Writeback stages.

3.All architectural work occurs in the Execute (EX) stage. The grain's execute() method dispatches work to one or more Boxes (EBox for integer, FBox for floating-point, MBox for memory, CBox for barriers, PalBox for privileged operations).

4.Memory accesses flow through MBox to GuestMemory. Virtual addresses are translated via the DTB (data) or ITB (instruction) translation buffers. Physical addresses route to SafeMemory (RAM) or MMIO regions (devices).

5.Serialization is enforced explicitly through barriers (MB, WMB, EXCB, TRAPB) and PAL transitions. Barriers stall the pipeline frontend until release conditions are met.

6.Exceptions and interrupts are queued by the FaultDispatcher and delivered precisely at the Writeback commit point. Delivery flushes younger pipeline slots, preserves state, and vectors execution to PAL handlers.

7.Devices interact with the CPU through MMIO reads/writes (strongly ordered, synchronous) and interrupts (asynchronous, sampled between instructions).

8.Architectural state commits only in the Writeback stage. No earlier stage produces architecturally visible effects.

 

No layer bypasses another's authority. The one-way dependency hierarchy enforces this: ExecutionCoordinator → AlphaCPU → IBox → AlphaPipeline/Boxes → GuestMemory/FaultDispatcher.

 

See Also: Chapter 2 - Execution Model; Chapter 3 - Pipeline Architecture; Chapter 4 - Functional Execution Domains ("Boxes).