Figure 9 — Three Dispatch Styles: Same CALL, Three Resolutions

The caller always writes CALL(Abstraction.Method(args)). How CR14 resolves the method is an implementation detail hidden inside the abstraction. Three styles trade security for speed.

CALLER PERSPECTIVE — IDENTICAL IN ALL THREE CASES CALL( Abstraction.Method( args ) ) Caller cannot tell which dispatch style the abstraction uses CR6 → C-List CR6 → C-List CR6 → C-List (a) Symbolic Resolver Maximum isolation • Runtime symbol lookup SECURITY █████ HIGHEST CR6 (Active C-List) Symbolic entries: "Mint", "GC", "Lookup" CR14 (Active Nucleus) Dispatcher / Resolver code DISPATCH FLOW 1 Read method index from CALL 2 Look up symbolic name in CR6 3 Resolve symbol to code block (internal jump table) 4 Execute code block on DRs 5 RETURN → full stack unwind (mLoad revalidates CR5/CR6/CR14) Example: Thread.Mint ; Caller: CALL(Thread.Mint(type,sz,acc)) ; CR14 dispatcher internally: resolve "Mint" from CR6 check budget, delegate → Namespace.Mint() METRICS Cycles per dispatch: 8-15 Stack accesses: 2 (push+pop) mLoad calls on RETURN: 3 (CR5+CR6+CR14) Caller visibility: Zero ✔ USE CASES • System services (Mint, GC) • Security-critical abstractions • Crypto / key management • Hello Mum messaging (b) LAMBDA Fast-Path Zero stack access • Machine-status registers SECURITY ████▁ MEDIUM CR6 (Active C-List) Method GTs with X permission CR14 (Active Nucleus) Code with LAMBDA instructions DISPATCH FLOW 1 Load method GT from CR6 2 LAMBDA CRn, x 3 Check X permission on GT (no domain crossing) 4 Save PC+4 to machine-status (NOT stack!) 5 Execute method body on DRs 6 RETURN → fast path (1 cycle) restore PC, clear flag, zero stack Example: SlideRule.Multiply ; CR2 has GT with X perm MOV DR1, <operand_a> MOV DR2, <operand_b> LAMBDA CR2, multiply ; DR1 = result (2-3 cyc) METRICS Cycles per dispatch: 2-3 ★ Stack accesses: 0 (zero!) ★ mLoad calls on RETURN: 0 (fast path) Caller visibility: Zero ✔ USE CASES • Arithmetic (SlideRule, Abacus) • Geometry (Circle) • Utility / helper functions • Clamp / macro-like reuse (c) Traditional Binary Familiar model • Direct offset dispatch SECURITY ███▁▁ STANDARD CR6 (Active C-List) Method entries (data / metadata) CR14 (Active Nucleus) Compiled binary (offset table) DISPATCH FLOW 1 Read method index from CALL 2 Compute offset from base addr 3 Direct jump to method code (no symbol resolution) 4 Execute method body on DRs 5 RETURN → full stack unwind (mLoad revalidates CR5/CR6/CR14) Example: Access.asm ; CR14 = compiled code object ; Methods at known offsets entry: MOV DR1, 42 ADD DR1, DR1, DR2 ... METRICS Cycles per dispatch: 5-8 Stack accesses: 2 (push+pop) mLoad calls on RETURN: 3 (CR5+CR6+CR14) Caller visibility: Zero ✔ USE CASES • General application code • Familiar C/Rust-style binaries • Legacy code wrapping • Access.asm default example SIDE-BY-SIDE COMPARISON Property Symbolic Resolver LAMBDA Fast-Path Traditional Binary CR14 contains Dispatcher / resolver code Code with LAMBDA instrs Compiled binary Resolution Runtime symbol lookup X-permission jump Offset from base addr Cycles 8-15 2-3 ★ 5-8 Stack usage Full CALL ceremony Zero ★ Standard call/return Permission E (Enter) X (Execute) E (Enter) Domain crossing Yes (new CR6+CR14) No (same domain) Yes (new CR6+CR14) KEY INSIGHTS Same caller interface, three internal mechanisms: The caller always writes CALL(Abstraction.Method(args)). The CALL ceremony switches CR6 and CR14 identically in all three cases. What differs is how CR14 resolves the method name to executable code. The caller never knows which style is used — that's the power of encapsulation through capabilities. LAMBDA is unique — it eliminates the CALL/RETURN overhead within a domain: While (a) and (c) both use the full CALL ceremony (stack push, mLoad revalidation on RETURN), LAMBDA saves the return address to a machine-status register and restores it in 1 cycle. Zero stack, zero mLoad. Abstraction creator chooses the tradeoff: High-security services (Mint, crypto) use symbolic dispatch for maximum isolation. Compute utilities use LAMBDA for speed. General code uses traditional binaries. Different abstractions in the same system can mix styles.