QEMU TCG as JIT replacement?
 

Since Bernie seems to have left the Amiga development scene and nobody else wants to touch the current JIT implementation (which is getting in the way of cool new things like 64bit and MMU support) maybe it's time to look for a replacement.

Since IBM (my employer) bought out Transitive (responsible for the Rosetta PPC emulation in MacOS X) I thought I might ask one of these blokes if he's willing to look into writing a replacement. Turns out that this wouldn't be the best idea since the risk of IBM IP trickling into UAE would be too high.

But one of our former KVM developers pointed me to the Tiny Code Generator that's part of QEMU. In his opinion that's the most capable Open Source dynamic recompiler available today. It already seems to support m68k as a target platform, too.

So maybe this is something worth looking into.

EDIT: removed bug report

That reminds me of the idea that I posted here of using llvm as JIT. Don't know which one is better.

I am not interested in JIT. (debug some intel asm code generator = no thanks)

I might be interested if someone else does some checking first, I am not going to waste time for something if it will be totally incompatible..

What parts belong to JIT exactly? Would you have to reimplement the functions in compemu.h, or do something else? (There's not much documentation in the code ;))

I am just curious.

Reimplementation or "API" change isn't important. It is only a some boring programming.

Supported features in JIT engine are important.

Is it really made for emulation? (instead of simulating some "generic" 680x0 CPU) Supervisor mode emulated 100%? Exceptions? (including non-existing opcode exceptions) Support memory "holes"? (Amiga has IO and memory here and there) and so on..

Point is: if it misses some important feature -> I don't want to find it _WHEN_ it is being merged..

Oh yes, I see. And no. What I really meant was: Which parts of WinUAE's source tree belong to the JIT? Or where does JIT sit exactly?

I am confused by the sourcecode. Since there are no comments, it is hard to get an impression of the overall structure. Right now I am trying to compile the beast, to see what is really going on.

compemu.c, compemu.fpp.c, compemu_support.c, compstbl.c, compemu_optimizer_x86.c, compemu_raw_x86.c, JIT CPU loop in newcpu.c, events_jit.h

I guess thats it, more or less..

Well - right now it's made to run (Linux) binaries targeted at any of the supported target CPUs on any of the supported host CPUs.

In terms of target CPU it's optimized for Coldfire targets right now so I have no idea if the support is complete enough for older m68k CPUs.

Here's the list with the supported CPUs:
http://www.qemu.org/status.html

Where does it say that there is M68K TCG?

TCG ist used for all the supported QEMU targets right now. I successfully booted the Coldfire test kernel that is available from the download page.

EDIT:
There doesn't seem to be any MMU emulation yet, though:

This is totally useless information (never believe in MHz rates in emulation). Where is the code? (I checked sources quickly and didn't see any m68k/coldfire related emulation code..) How does it work? I thought TCG was the dynamic compiler in qemu..

This was the point in my previous post. Hard facts or don't bother.

I'm not exactly familiar with the file organization of QEMU but in the 0.11.0 source archive there's a folder called target-m68k that seems to hold the majority of the 68k code. There's also m68k-dis.c and m68k-semi.c in the archive root.

The hw folder contains dummy_m68k.c, mcf5206.c and mcf5208.c which seem to be related to Coldfire full system emulation.

Elbox used the MCF5475 on their Dragon card. In their FAQ they stated that the MCF54xx line were the first Coldfire CPUs compatible enough for Amiga use.

There are no Coldfire CPUs that are transparently compatible with Amiga OS. It is impossible.

I checked QEMU sources yet again: it is Coldfire emulation with some 680x0 features added but not all 680x0 features are implemented (USP, FSAVE, FRESTORE, most MOVEC to/from special registers etc..)

-> Unusable for Amiga emulation.

How did they do it on the Dragon Coldfire then?
Thought so. Well - maybe this is worth revisiting sometime in the future if someone extends the m68k support.

Patching/trapping, like 680x0.library does with missing FPU instructions. (and I am sure not all instructions can be patched on the fly because they don't cause exceptions)

Anyway, we are talking about 680x0 EMULATION. No more talk about Coldfire stuff or "something that looks like 68020", maybe.

I repeat: facts only.

The qemu M680x0 emulation project at gitorious looks interesting. There's not much info, though.

Sorry, no fact. But maybe still interesting?

Can you build a version of WinUAE that doesn't have JIT and be able to target x64, etc? Would that improve anything over the x86 version?

Maybe the GCCJIT (http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00228.html) is a proper way to go? One JIT engine, support for several host CPU architectures, no worrying about x86 mess in *UAE...

MC68k emulated on ARM?

Amiga accelerator/emulator on Xilinx Zynq with hybrid mode? Perhaps first (Win)UAE on non Windows. WinUAE is not Windows...
When software meet hardware to meet software...