← Church Machine

Figure 5 — Machine-Status Fast Path

LAMBDA uses two machine-status registers instead of the call stack, enabling zero-stack abstraction entry and return. The common case completes in ~3 cycles with no memory access for stack push or pop. CALL/CHANGE save and restore LAMBDA state when nesting is required.

Machine-Status Registers (hardware, not memory) lambdaActive lambdaReturnNIA LAMBDA Entry LAMBDA CRd 1 mLoad: X Permission Check on CRd Single gate check — no c-list traversal needed 2 Write Machine-Status Registers lambdaActive ← true lambdaReturnNIA ← PC + 4 3 PC ← entry.location (branch) Same scope: all CRs, DRs, flags unchanged ... target code executes ... Stack NOT touched RETURN (fast path) RETURN lambdaActive == true? YES PC ← lambdaReturnNIA lambdaActive ← false   (clear flag, done) ✓ Complete (~1 cycle) Total: ~3 cycles round-trip Zero stack access. Zero memory bus contention. NO RETURN (stack path) lambdaActive == false → use call stack Pop frame, restore CRs/DRs/flags, revalidate via mLoad 1 Pop Call Stack Frame Restore PC, CRs, DRs, flags + LAMBDA state 2 mLoad Revalidation (CR6, CR14) Version, seal, bounds re-checked on restored CRs 3 C-List Restore & PC Resume CR15 ← caller's c-list, PC ← return address ✓ Complete (3+ cycles) CALL and CHANGE Preserve LAMBDA State If LAMBDA is active when CALL executes, the stack frame saves lambdaActive + lambdaReturnNIA, then clears the flag. RETURN from CALL restores LAMBDA state → nested LAMBDA resumes. Key Insight: Register-Only Fast Path LAMBDA replaces the call stack with two machine-status registers. In the common case (no nested CALL), abstraction entry and return complete in ~3 cycles with zero stack access, zero memory bus contention, and zero revalidation overhead.
LAMBDA fast path (register-only)
Machine-status registers
Stack path (CALL fallback)
Design rationale