|
<< Click to Display Table of Contents >> Navigation: ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 2 - Execution Model > 2.5 Execution Progress and Stalls |
Execution progresses unless explicitly blocked by an architectural condition. The run loop guarantees forward progress when:
•No stall conditions are active
•No higher-priority exception is pending
•No barrier is blocking the frontend
When all stages are clear, the pipeline's tick() returns BoxResult::advance() and the ring buffer rotates forward.
Execution may stall due to:
•Memory barriers (MB, WMB, EXCB, TRAPB) — stall until drain/release conditions are met
•Fault dispatch and exception delivery — pipeline flush and PAL entry
•TLB misses — DTB or ITB miss triggers a fault that stalls until resolved by PAL
•Floating-point execution occupying EX — FBox operations execute synchronously, stalling the pipeline
•PAL entry or exit — CALL_PAL serializes the pipeline; HW_REI restores state
•Branch misprediction recovery — younger slots are flushed and fetch restarts
Stalls are explicit and visible in pipeline state. The pipeline reports stalls via BoxResult::stallPipeline() and the isFrontendStalled() / isPipelineStalled() query methods.
Stalls may occur at different scopes:
•Slot-level stalls — a specific instruction cannot advance (e.g., FP operation in EX)
•Frontend stalls — instruction fetch is blocked (e.g., barrier active, TLB miss)
•Pipeline-wide serialization — no younger instruction may execute (e.g., CALL_PAL, MB with pending stores)
The scope of a stall is determined by architectural rules, not heuristics. Every stall has a well-defined release condition.
See Also: Chapter 6 - Serialization and Stall Model (barrier mechanics); 3.12 Stalls and Serialization .