Qemu does something similar. And Box86 does that while keeping 3D acceleration on converting X86->ARM linux binaries.

https://github.com/ptitSeb/box86

Moore's law has blessed all of us with nearly infinite compute relative to systems from a decade ago.

Now, that we've relentlessly squandered all of it, well, that's on us.

It's quite common way to get good performance out of emulated code, althought usually it's JIT.

But yeah, it is crazy complex

In addition to the examples other commenters have given, it’s also how Rosetta 2 works to translate x86_64 to arm64 for supporting Intel binaries on M1/M2 Macs

Well, think about it this way - suppose you have a block of C code and you compile it to object code, like:

    if (hitByMissile == True) {
      lives--;
      if (lives == 0) playing = False;
    }
    ; next address is 0x8f02

it might turn into:

    ld a, (4011h)
    jr z, 8f02h
    ld a, (4020h)
    dec a
    ld (4020h), a
    jr z, 8f02h
    xor a, a
    ld (0x4021h), a
    ; next address is 8f02h

That might disassemble back to C as:

    if (var4011 != 0) {
      var4020--;
      if (var4020 == 0) {
        var4021 == 0;
      }
    }

like that. Less readable, because we have no variable names, and not identical to the source code but probably close enough, but the important thing is we don't care if we understand it or not. If we declare a variable that our original code stores at 4020h in a 16-bit address space, but it ends up somewhere wildly different in our 32-bit address space because we're recompiling on a newer machine, we don't care - we just care that the name gets used consistently.

If you then read through the disassembled source you could start to piece together what the variables are, though.

PowerPC

Add "computing" to your query to disambiguate.

PowerPC