6 ms·

I'm still baffled by RE community aiming for "100% asm match", needing to reproduce specific compiler version, instead of aiming for functional equivalence and

• Jegber 20d ago
  Game behavior can be tied so closely to quirky hardware behavior that I doubt such a tool would be simple to create. You’d have to verify that your code produces the same hardware state. And different (ie more efficient) code almost by definition produces a different hardware state than the original code. Thus changing the game.
  • qarl2 20d ago
    Really though? You have to try really hard to make your code that unstable - and well written code isn't that. Seems more like voodoo.
    • DSMan195276 20d ago
      Who said games were well written? Older games are often very sloppy and buggy, and abuse the specific hardware they're designed for to get extra performance, unique graphical effects, etc. Emulators constantly run into games that don't run because of specific hardware nuances that may or may not have been intentionally used (Ex. relying on exact cycle counts, reading uninitialized memory, changing values while they're used, etc.).
      • unknownfuture 20d ago
        I wouldn't characterize that as sloppy or buggy in any way (though certainly that is also true for some games). Exploiting hardware in new and novel ways was an essential part of developing for older consoles. This is something someone only familiar with writing code for general purpose devices or higher level languages can't imagine. But when you're building for one very specific hardware platform you can tailor your code to that platform in ways that simply aren't possible when building for portability.
      • qarl2 20d ago
        Sure. I guess I'm assuming that sloppy and buggy software didn't much become popular. Because it was sloppy and buggy.
        • DSMan195276 19d ago
          Why would you assume that? That's not even true of regular software :D But also, as long as the game works on the specific hardware it was designed for then that's all that mattered, which was my point. If it reads uninitialized memory or depends on exact cycle counts or some undocumented hardware behavior then that's _fine_ if it still works on the real hardware, plenty of that was even intentionally done to achieve things otherwise impossible on that hardware. At the same time it makes it almost impossible to verify even trivial changes to a function. Once you start accounting for all the potential state differences the answer to "does this function work the same?" will basically always be 'no' unless the code is identical. The only way to eliminate various kinds of state from being a concern is to analyze where the function is _used_, rather than just the function itself, and that's an entirely different and much harder kind of challenge.
          • qarl2 19d ago
            > Why would you assume that? Why would I assume that sloppy and buggy software would be less popular? I'll have to get back to you on that one.
• unknownfuture 20d ago
  Because byte-for-byte identical output is far easier to measure than trying to test for functional equivalence. This is also partly a preservation activity so (as best we can create it) identical code generating identical output is a big part of the point.
• qingcharles 20d ago
  It's usually just the first sweep to make sure everything is understood and documented before you start to make mods.
• xyzsparetimexyz 20d ago
  No. Halting problem.