chips

I'm using a code generation approach both for 6502 and Z80, not as extreme and elegant as demonstrated here though. Instead of a pure data description I have python scripts which generate C source code. The 6502 is perfect for code generation because instructions are very uniform, and the "interesting" part of instructions are the addressing modes which always run the same sequence of operations in front of the actual instruction-specific "payload". The Z80 instruction set has many more special cases, but it can be decoded "algorithmically" as well, see here: http://www.z80.info/decoding.htm My Z80 emulator basically implements this "recipe" in python, and generates a huge "unrolled" switch-case statement with one case-branch per instruction (ok not quite, the CB prefix instruction range is still decoded algorithmically to reduce the resu

One idea I had in my own modular emulators a while ago was to reduce the "state that's passed around" to the input/output pins of the microchip emulators the higher level system emulator is built from. This pin-state often fits into a single 64-bit integer (at least for typical 8-bit home computers), and another advantage is that the emulator's code structure can be kept very close to the schematics of the real hardware (the wiring between chips can be mapped 1:1 to bits in 64-bit integers). The emulators are written in C, not Rust, but I bet this approach would also work perfectly with Rust's borrow checker (since there's no shared state in memory the borrow checker shouldn't even "activate"). An emulator is essentially built from functions which take a 64-bit integer as input, and return another 64-bit integer. https://github.com/floooh

I think I'm seeing this in C code too with clang. I'm having fairly big code-generated switch-case statements in my CPU emulators with hundreds to thousands of case-blocks (Z80: [1], 6502: [2]), and those take up to 7 seconds to compile with -O3, which is really unusually long for a single C compilation unit of that size (compared to the same number of lines across many smaller functions). If the problem has exponential behaviour it could easily blow up to minutes or hours for larger functions. [1] https://github.com/floooh/chips/blob/d0f690f2598f967f75cb360... [2] https://github.com/floooh/chips/blob/d0f690f2598f967f75cb360...