static binary translation

[RockinB]

I came across a neat little document on static binary translation. After I've read it, I've realized that this technique is much better applicable in reality than I thought before. It is easier to do and not as complex as a dynamic recompiler, especially when considering the Saturn as the target.


This approach might be a method to get mega drive games emulated on Saturn. Or to speed up NGPC games, the cpu core used there is slow as hell and there doesn't exist any alternative core.


See here:

An Emulator Writer's HOWTO for Static Binary Translation

Abstract of above

Asteroids Static Binary Translation


The interesting thing is, that the approach is platform independent and that it leaves most of the optimizations to the sophisticated gcc compiler, only a few minor optimization have to (or can) be done on your own.



It has been applied successfully to games that I've probably played before: Tailgunner on GP32 and others.



Oh yeah, this got me thinking again about hardware rendering support in my snes9x port...

 

[vbt]

Moved from "Games & emus worth porting" as it deserved its own topic.

 

[Mask of Destiny]

Static binary translation tends not to be very reliable. It's very hard to figure out which parts of a binary are data and which are code. It's more practical for emulating applications under an OS (for instance running x86 Windows programs under Windows NT for Alpha) than for game console stuff.

 

[RockinB]

Static binary translation tends not to be very reliable. It's very hard to figure out which parts of a binary are data and which are code. It's more practical for emulating applications under an OS (for instance running x86 Windows programs under Windows NT for Alpha) than for game console stuff.

You mean the jump table approach to record jump target labels at runtime of a ROM? That would need to be found out on a PC, that's right. Since this type of SBT is platform independent and since all emus on Saturn are ports of Windows/*nix version emulators, that should be no problem. In that case, It would be appropriate to upload the patched emu, such that multiple people can record jump target files, which can be merged later on.

 

[ExCyber]

Static binary translation tends not to be very reliable. It's very hard to figure out which parts of a binary are data and which are code. It's more practical for emulating applications under an OS (for instance running x86 Windows programs under Windows NT for Alpha) than for game console stuff.

Wouldn't it also work for arcade emulation in situations where a particular system only hosts one or a handful of games? In that case, manual analysis for ambiguous code/data blocks is probably feasible, assuming that the automated analysis was good in the first place...

 

[Mask of Destiny]

Certainly with manual analysis on troublesome blocks you can achieve good results with static binary translation. Running the game thoroughly in a more traditional emulator that outputs hints as to whats code and whats data can cut down on the amount of manual work that needs to be done.

Of course, by the time you do all that manual work you start to wonder whether you would have been better off with a dynarec. Writing a working dynarec isn't fundamentally much harder than writing a decent static recompiler. The real challenge is finding a good balance between the amount of optimization done, the time spent doing the recompilation and the amount of memory used.

I'm toying with the idea of putting together a 6502 dynarec for the 68K (more for fun than anything practical). I already have more projects than I have time for so it may just stay a fun dream.