nx_ifetch_emit.nx

nx_ifetch_emit.nx -- INSTRUCTION-FETCH translation test (virtual-memory-paging-mmu, CPU-datapath completion rung). The data-load/store rung proved the CPU translates DATA addresses under Sv39; this proves the CPU also translates the INSTRUCTION FETCH -- i.e. the PC itself is virtual in S/U-mode and the next instruction is read through the page table. Table-computes a bare-metal rv64 image: 1. M-mode (physical PC): install mtvec=&handler; lay a gigapage code PTE root[VPN2=3] (VA 0xC0000000.. -> PA 0x80000000..); csrrw satp (Sv39 ON); mepc = the VIRTUAL address 0xC0000000+cont_off; mstatus.MPP = S; mret. 2. mret lands the PC at a VIRTUAL address -> the CPU FETCHES the continuation through the page table (VA 0xC00000xx -> PA 0x800000xx) and runs it in S-mode -> emits "IOK". VA != PA, so "IOK" can only print if the fetch was genuinely translated (not a physical read of the PC). 3. CONTROL (gate re-emits with the code PTE's Valid bit cleared, 0x20000006): the mret targets an UNMAPPED virtual PC -> the FETCH walk faults -> instruction-page-fault (mcause=12) -> vectors to mtvec (the handler is fetched physically in M-mode) -> the handler confirms mcause==12 and emits "IPF". "IPF" (and the absence of "IOK") proves the fetch faults on a bad code page. Zero hand-written machine code: a tiny rv64 encoder + two-pass forward-branch resolution. nx_ifetch_emit -> runtime/_hdl_build/_ifetch_virt.bin + .gold Sovereign, no gcc/.sh. license_tier: ORIGINAL