3 ms·
What would be even more interesting is a JIT-based emulator that worked by compiling bytecode into Javascript, then relying on the browser to compile it back in
by DarkShikari 16y ago
What would be even more interesting is a JIT-based emulator that worked by compiling bytecode into Javascript, then relying on the browser to compile it back into machine code.
A machine-independent, JIT-compiled JS emulator might actually end up being faster than some purely-interpreted native-code emulators. And unlike a purely native JIT emulator, it wouldn't need a compilation component (the browser would do that itself).
Obviously such a thing would be dramatically slower than a native JIT emulator -- but surprisingly few emulators are JIT-based.
(Possible catch: I know for a fact that some Nintendo DS games use small amounts of self-modifying code. This probably is true of previous generations, too.)
- grantg 16y agoNot a good idea with hand-coded ROMs for CPUs that are in single-digit MHz that use interrupts liberally, it would cause code cache invalidation a lot. Some stats for SML2 running (Audio ON (web audio for mac in about:flags for chrome, mozAudio for Firefox 4), scaling OFF): Chrome 12: http://i.imgur.com/JjpT5.jpg http://i.imgur.com/JjpT5.jpg 27.0% CPU load Firefox 4: http://i.imgur.com/yEzzw.jpg http://i.imgur.com/yEzzw.jpg 68.6% CPU load