Calling fixed code in a register bank #
ExecWithin.call combines charged argument preparation, a proved routine in an injectively
renamed register bank, and a charged continuation. The continuation receives the routine's entire
postcondition and the unchanged registers outside its bank. The postcondition may describe both
results and memory frames: register renaming leaves memory unchanged, so no separate memory
transport proof is needed.
Unlike bounded-footprint data-structure contracts, this rule does not require every word in the caller state to fit or specify a finite footprint. It retains exactly the hypotheses of the supplied execution proof, including routines that tolerate arbitrary unused memory.
Main results #
Data.comap_set,Data.comap_set_of_forall_ne: transport register updates through a bank view.Exec.rename_post,ExecWithin.rename_post: retain postconditions and the caller register frame.ExecWithin.call: inline a fixed-code routine with additive instruction accounting.
These composition lemmas use the existing register-renaming semantics. Data.comap_set
was extracted from the priority-queue calling convention by Renfei Zhou.
Run a routine in a larger register file, retaining its entire postcondition and the frame outside its bank. Renaming preserves the exact instruction count.
Bounded-time version of Exec.rename_post.
Call a routine in an injective register bank and pass its postcondition and register frame to
the continuation. Preparation, routine execution, and continuation are all charged; renaming
itself emits no instruction. Any memory assertion in Q refers to the actual returned memory.