> I'm afraid that's too vague for me to grasp the problem you are talking about. I'd > say - it depends, but we need to be more specific in order to avoid assumptions. The > only two kinds of "self-modifying code" I can think of are these two: > > a.) compressed code > > b.) encrypted code
Those are both correct. However, there's a third case: all of the systems that currently use DRCs run code almost exclusively from RAM, and they all use overlays to do so. And a fourth case: code that actively constructs other code based on the game state and then runs it. And a fifth where some code is copied into RAM by an external protection device.
All of these combine to mean the same RAM location could have dozens or hundreds of unique pieces of code occupying it over the lifespan of a game.
So to achive static recompilation, you need:
1) to guarantee 100% coverage of the game's code on a single interpreter run 2) some way to track all of the different code configurations that occur in RAM during that run, which can number in the hundreds on ST-V games, let alone systems with more RAM like Naomi
And after that, all you can hope for is the exact same performance improvement that a DRC already yields without having to deal with any of those problems. Therefore, there is zero reason for MAMEdev to pursue this.
Index 
Flat 
Re: It's called "static recompiler"
Reply
Re: It's called "static recompiler"
