3 ms·
I'm skeptical that applying decompilers to C makes sense for these old games that were most likely programmed originally in assembler. Many of the examples in t
by ekimekim 7y ago
I'm skeptical that applying decompilers to C makes sense for these old games that were most likely programmed originally in assembler. Many of the examples in the post show the decompiled C being more complicated due to type casts, creation of temporary variables, missing inputs and even entire missing instructions, etc.
Maybe it's just that I've worked with Z80 assembler a fair bit, but I feel like what's going on is much clearer when you're operating in the same language as the original authors were, able to see exactly what it's doing instead of a rough approximation of some C that would generate semantically equivalent code.
- zozbot234 7y agoThe thing about C is that it's portable assembly; decompiling to C is a good way to end up with reasonably portable code with little undue effort.
- pjmlp 7y agoEven Basic and Pascal are portable Assemblies.
- ekimekim 7y agoThese games aren't portable to begin with - they use hardware-specific memory mapped IO, pixel processing units, DMA routines, etc. Simply taking the code and making it C doesn't let you run it elsewhere any more than taking the code for airplane systems and running it on your laptop will allow your laptop to fly. The decompilation here is intended primarily to aid understanding or make changes, and I think targeting the system's specific assembly would serve that goal far better. (to clarify: I'm talking specifically about retro video games here, because of a) the tight binding to hardware and b) the fact they were written in asm to begin with. I make no judgement on reverse engineering in general.)
- olliej 7y agoGhidra specifically intends to handle arbitrary bizarre embedded systems, so does a good job.