A very high speed emulation can be useful to execute regression tests, or to run interesting programs. Or possibly just to run very accurate emulations on slower platforms.

Over on Stardot, Chris Evans aka scarybeasts has published a work-in-progress emulator that uses just-in-time compilation to deliver very high performance: 10GHz equivalent 6502 speed on a 3GHz x86, for example, or 3GHz 6502 on a 2GHz x86.

It's been tested on many programs including software protection and custom tape loaders, so certainly handles the usual hazards of self-modifying code. It includes a replay facility and a 6502-level debugger.

"The -fast flag is nice for BASIC testing. It runs the CPU as fast as possible while ticking the timers and video hardware at wall clock speed"

See the threads:
Announcement: New emulator: beebjit
Update and some timings: New beebjit release: v0.9.1

From the announcement:


I'd be hopeful that this work could at some point be applied to other targets, such as ARM, or even JavaScript.

Just want to add some enthusiastic support for this project - Chris has achieved something I hadn't thought possible, since, not only does it dynamically recompile 6502 into native x86 code as it encounters it, but also maintains a runtime system emulation layer (in this case, emulating the BBC Micro hardware), which handles the 6522s, disk/tape system, video system, and interrupt handling (among other things) with no cost to the compiled code.

My understanding of how this works is that compiled basic blocks don't have any provision for handling interrupts, so they run as fast as possible; meanwhile, if an interrupt is expected in the near future, the emulator falls back into an "interpreted" mode and performs accurate synchronised emulation of the whole system. I'm not sure how other emulated components are kept in sync with the jitted code in the absence of a pending interrupt, but I can attest that it works very well, and is to date probably the most accurate BBC Micro emulator, as well as the fastest!

If it runs fast enough, it might perhaps be possible to rip ahead with a basic block, and then if it finds something of interest should have happened in between times, throw away the resultant state updates, and restart the block in a more pedestrian mode.

Just the collapsing of a block into just the final updates to flags and memory could be quite a saving.