Figure 1 — LAMBDA CR6 Idempotent Self-Invocation Flow
CALL enters the method and splits the lump, establishing CR6 as the c-list self-reference. LAMBDA CR6 re-enters the method body without gate re-validation. The return address is invariant — repeated LAMBDA CR6 writes the same value to the same register. Two RETURNs total: one clears the flag (base case), the second pops the CALL frame.
CALL enters method (lump split)
CR14 ← code region (X-only) | CR6 ← c-list region (L-only)
lambda_active = 0
initial state
lambda_pc = undefined
not yet set
Method body executes ... software counts down (n = 5, 4, 3, 2, 1)
Data registers track the recursion argument. Hardware tracks nothing.
LAMBDA CR6 — self-invocation
if !lambda_active: lambda_active ← 1
lambda_pc ← PC+4 (idempotent — same value each time)
lambda_active = 1
lambda_pc = addr_after
Branch to method entry (re-enter)
Same method, same domain, same capabilities — no gate re-validation needed
RECURSION ITERATIONS (n times)
Each iteration:
1. Method body re-executes with decremented argument
2. LAMBDA CR6 fires again — lambda_active ALREADY 1
3. lambda_pc ← PC+4 (SAME value overwrites SAME register = idempotent)
4. Branch to method entry again
Why idempotent?
lambda_active is already 1 → no change
lambda_pc = same addr → same value overwrites
Stack growth: ZERO frames per iteration. Hardware state: 1 bit + 1 PC register.
O(1) hardware cost regardless of recursion depth
Compare: CALL CR6 would push 2N stack words, re-validate gate N times — O(N) cost, zero security benefit
RETURN #1 (base case: n = 0)
lambda_active = 1 → PC ← lambda_pc (addr_after_lambda)
lambda_active ← 0
Execution resumes at addr_after_lambda
lambda_active = 0 now. Machine is back to normal CALL context.
RETURN #2 (real return)
lambda_active = 0 → real RETURN. Pop CALL frame from initial entry.
✔ DONE
Two RETURNs total, regardless of recursion depth