I’ve been decompiling for the past (almost) two years, and it’s fun to see the bugs, compiler quirks, programmer superstitions, things that coincidentally work because of compiler behavior not because of correctness, as well as the things modern tooling would have caught that 30-year old versions of GCC hadn’t gotten around to yet.
replyThere were even things I thought I had to manually optimize in the early 2000s that the GCC optimizer was already taking care of in the mid-90s.
deleted
replyHave you written about your discoveries anywhere? They sound pretty interesting.
replyHow can you tell the difference between something manually optimized and something automatically optimized?
replyThere's not really an exact science to it, but manually-optimised code is usually more structured/systematic to make it easier for the human author to manage the dependencies and state across the board, while automatically-optimised code is free to arrange things however it would like.
replyAs an example of the kinds of optimisations that the best human programmers were doing before compilers took over, see Michael Abrash's Black Book: https://www.phatcode.net/res/224/files/html/index.html - you can intuit how a human might organise their code to make the most of these while still keeping it maintainable.
Heh. Today I found thanks to the 9front people that some GB games used carts' sram as 'swap'.
replygames/gb didn't save the sram in the emulator save files, so upon restoring the snapshot and saving in the cartridge memory you got a mismatch. It got fixed really fast, the emulators are really simple plan9 C compared to anything else.