Pretty sure you’re still going to be stymied by things like cycle-counted code to line up I/O writes with the state of the hardware, though. I don’t suppose there’s tricks for that.
That’s correct — but one of those events is external interrupts (from the graphics, audio, or cartridge hardware), which complicates things a bit since your “checkpoints” can be anywhere in the code rather than just at a specific set of register accesses.
You could work around this by tracking cycles per-basic-block while running transpiled code, and falling back to cycle-accurate software emulation when you get close to a hardware interrupt.
Most of the point of recompiling (JIT or AOT) is to amortize instruction decode and dispatch costs versus an interpreter. If you have to do the cycle accurate bookkeeping anyway, you're most of the way to the overhead of an interpreter again. There'll be some savings around partial instruction streams that don't have effects outside the CPU core that can just be run as a burst, but I'm not sure it'll be a game changing amount.
Instructions are only written once but could potentially be written by any store with zero page indirect[1] or indexed addressing.
[1] that is ($AA,X) or ($AA),Y
That said, the stack was used as a fast indirect jump address location pretty frequently, as described here, essentially abusing the fact that PHS and RTS are 1 byte instructions: http://www.6502.org/tutorials/6502opcodes.html#RTS
And really since basically all PC-modifying instructions operate on either relative (b*), absolute-indirect (jmp), absolute (jmp, jsr), or stack-indirect (rts, rti) there's no special benefit you get from having code in the zero page anyways afaik.
You save one cycle off each instruction that modifies another instruction, which can important for inner loops. See eg http://www.linusakesson.net/programming/gcr-decoding/index.p..., although that's a disk-induced realtime requirement, rather than hblank/beam-induced.
Thanks for clarifying :)
Personally, I disagree with the author of that article's conclusion here, that the [only] "solution is to embed an interpreter runtime in the generated binary." You can statically recompile this code!
You "just" need to run a concolic interpreter over the code, generating out new static instruction streams for each possible phi-node (branch) state, and then coalescing them back together where you find you've generated the same instruction stream. You can early-terminate these spec-exec paths when you find yourself back at an instruction postdominated by entirely static code [within the body of the unrolled runtime coroutine sequence].
Might sound like an unbounded exponential check, but in practice 1. merging back together will usually happen within, at most, five instructions, because these are almost always last-minute bit-packing-hacks to get code to fit within a given constrained ROM image size; and 2. there are always only two concolically-discoverable valid interpretations of a given instruction stream (if doing mid-instruction jumps), and only one concolically-discoverable valid interpretation of data-as-code / RAM-as-code. (NES games don't assemble and JIT arbitrary code streams. They don't have the work RAM for it. They're at most unpacking existing, non-arbitrary code streams; or taking something that is primarily a code stream, and then reusing it as data elsewhere, maybe a PRNG seed, or a 1-bit noise texture.)
A large part of my job lately is decompiling and "reconstructing meaning" for object code compiled for lousy underspecified abstract-machine architectures. There are a lot of modern compiler-theoretic tools and tricks that can make short work of "statically" recompiling any but the hardest of hard cases. They're sadly virtually unknown outside of academia, though (probably because they're based on various graphical transformations of the code proposed after the Dragon Book was published, which is the point in history where most people in industry's knowledge of compilers seems to stop.)