v5 Linker: merging module bytecode

Relocate function IDs and Main jump addresses in separate coordinate systems.
Preserve function-local jumps and input artifacts.
Validate dependency order before deterministic concatenation.

1 / 6

Readiness

Derive module initializer artifacts and absolute instruction indexes.

2 / 6

Worked reconstruction

Suppose util has two functions and seven Main instructions. main has local function ID 0 and a Main JUMP_IF_FALSE target 5:

Operand in main artifact	Offset	Linked value
Function ID 0	previous function count 2	2
MAKE_CLOSURE 0 in Main	previous function count 2	2
MAKE_CLOSURE 0 inside a function	previous function count 2	2
Main JUMP_IF_FALSE 5	previous Main length 7	12
Function-local JUMP 5	no instruction relocation	5
CALL 2	arity, not an address	2

Function IDs and instruction addresses are different number spaces. A module's Main moves inside the concatenated Main, while each function keeps its own separate code slice. Only its closure-ID operands need the function offset; its local jumps stay unchanged. Jump targets equal to the old Main length also shift: they represent that initializer's end, now the next initializer's start in the merged stream.

3 / 6

Diagnose before implementing

A linker correctly shifts every closure ID but leaves Main jumps unchanged. With util length 7, main’s local back edge targets instruction 2. Where does it jump incorrectly, and what should the target be?

4 / 6

Independent transfer

Work a three-module layout with function counts 2,1,3 and Main lengths 7,4,9. Derive the third module’s function and Main offsets, including a jump to its one-past-end label. Then explain how to test linking twice without relying only on output length.

5 / 6

Carry forward

Carry linked Bytecode with stable unique IDs and relocated Main targets into the v5 capstone. Save a multi-module program with a loop in a later initializer; straight-line examples cannot expose missing jump relocation.

6 / 6