Hacker News new | past | comments | ask | show | jobs | submit login

This is amazing -- seems almost like a better way to play an Xbox 360 game on PC, without an emulator. Could even be what Microsoft wanted, for better retrocompatibility support. I wonder if it can also be done to other consoles? Let's hope it gives good fruits.



There are at least a couple of other examples of similar projects:

NES -> native executables: http://andrewkelley.me/post/jamulator.html

x86/Windows starcraft -> arm/Linux for openpandora: https://pyra-handheld.com/boards/threads/starcraft.73844/

(Tools used for this: https://github.com/notaz/ia32rtools)

For a lot of consoles, particularly older ones, this tends to yield worse performance than a JIT. Between different memory layouts, weird threaded code, jump tables, (and especially) self modifying code, a JIT can do a much better job building efficient code since it has all of the runtime information.

For newer consoles which more closely resemble PC hardware, things are definitely better; the current generation will basically look like the Starcraft port; an API compatibility layer.


Honestly, I think the emulator approach is a lot better -- you can do a lot more with JIT than trying to translate instructions AOT 1:1.


Yeah - as evidenced by the NES story the other day, the elegance of AOT blows up completely as soon as there's any form of self-modifying code or even memory arithmetic tricks or jump tables. It's all possible to work around, but JIT is cleaner and more flexible in the long run.


I'm fairly sure that the 360 specifically did not allow self modifying code. Makes it a good candidate for this approach.


In the case of self-modifying code, I wonder if the techniques behind profile-guided optimisation could work for decompilation:

https://en.m.wikipedia.org/wiki/Profile-guided_optimization

In other words, you create a JIT to run the executable, building a profile of the execution paths at runtime, and use that profile to guide a static decompilation process. That way it should be easier to identify the sections of self-modifying code, as well as model the behaviour of this code.

The only difficulty I can see is how much time it might take to map out all the code paths, but in principal it's possible, and there may be some efficient approaches for doing so.


This is an emulator. It looks very promising... we'll see how long it takes.


Seems like the core part is a static recompiler, probably with emulation of the extra hardware tacked on.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: