QEMU TCG as JIT replacement?

KillaByte · 12 October 2009, 19:05

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.

Leffmann · 12 October 2009, 21:57

EDIT: removed bug report

gilgamesh · 13 October 2009, 13:48

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

Toni Wilen · 13 October 2009, 14:38

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..

gilgamesh · 13 October 2009, 23:45

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.

Toni Wilen · 14 October 2009, 21:20

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..

gilgamesh · 14 October 2009, 21:33

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.

Toni Wilen · 14 October 2009, 21:41

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..

KillaByte · 15 October 2009, 07:07

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

Toni Wilen · 15 October 2009, 08:27

Quote:

Originally Posted by KillaByte

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?

KillaByte · 15 October 2009, 15:14

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:

Code:

# cat cpuinfo
CPU:            COLDFIRE(m520x)
MMU:            none
FPU:            none
Clocking:       208.8MHz
BogoMips:       139.26
Calibration:    69632000 loops

Toni Wilen · 15 October 2009, 16:47

Quote:

Originally Posted by KillaByte

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:

Code:

# cat cpuinfo
CPU:            COLDFIRE(m520x)
MMU:            none
FPU:            none
Clocking:       208.8MHz
BogoMips:       139.26
Calibration:    69632000 loops

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.

KillaByte · 15 October 2009, 22:05

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.

Toni Wilen · 16 October 2009, 08:45

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.

KillaByte · 16 October 2009, 10:28

Quote:

Originally Posted by Toni Wilen

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

How did they do it on the Dragon Coldfire then?

Quote:

Why do you make a card with ColdFire processors only now? Motorola has been producing ColdFire processors for a long time...
A: Recently, Motorola has developed and produced several series of the ColdFire processors but none of them were compatible enough with 68k processors to be able to run AmigaOS3.x. This changed with appearance of the MCF54xx processors family. These are the first ColdFire processors based on the V4e core. MCF5475, included in DRAGON, is the most powerful processor in this family. The first production of these processors is beginning just now (January 2005). We expect DRAGON to be the first commercially produced computer board based on this newest Freescale processor from the ColdFire/68k family.

Quote:

Originally Posted by Toni Wilen

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.

Thought so. Well - maybe this is worth revisiting sometime in the future if someone extends the m68k support.

Toni Wilen · 16 October 2009, 10:37

Quote:

Originally Posted by KillaByte

How did they do it on the Dragon Coldfire then?

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.

gilgamesh · 31 October 2009, 19:34

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

Sorry, no fact. But maybe still interesting?

r.cade · 31 October 2009, 21:33

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?

Romanujan · 13 October 2013, 16:16

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...

pandy71 · 15 October 2013, 15:34

Quote:

Originally Posted by Romanujan

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...

12 October 2009, 19:05	#1
KillaByte Registered User Join Date: Jun 2009 Location: Germany Posts: 77	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.

12 October 2009, 21:57	#2
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	EDIT: removed bug report Last edited by Leffmann; 12 October 2009 at 22:25.

15 October 2009, 15:14	#11
KillaByte Registered User Join Date: Jun 2009 Location: Germany Posts: 77	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: Code: # cat cpuinfo CPU: COLDFIRE(m520x) MMU: none FPU: none Clocking: 208.8MHz BogoMips: 139.26 Calibration: 69632000 loops

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
FS-UAE - Why it have no JIT?	nexusle	support.FS-UAE	19	13 May 2012 13:39
JIT error	Thom87	support.WinUAE	6	05 October 2008 20:38
Jit Error	CPC464	support.WinUAE	0	19 August 2002 12:12
JIT problem	Unregistered	support.WinUAE	0	19 July 2002 06:00
JIT Emulation	Doozy	support.WinUAE	2	17 January 2002 07:14

13 October 2009, 13:48	#3
gilgamesh Linux snob Join Date: Sep 2008 Location: Monkey Island Posts: 997	That reminds me of the idea that I posted here of using llvm as JIT. Don't know which one is better.

13 October 2009, 14:38	#4
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	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..

13 October 2009, 23:45	#5
gilgamesh Linux snob Join Date: Sep 2008 Location: Monkey Island Posts: 997	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.

14 October 2009, 21:20	#6
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	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..

14 October 2009, 21:33	#7
gilgamesh Linux snob Join Date: Sep 2008 Location: Monkey Island Posts: 997	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.

14 October 2009, 21:41	#8
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	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..

15 October 2009, 07:07	#9
KillaByte Registered User Join Date: Jun 2009 Location: Germany Posts: 77	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

15 October 2009, 22:05	#13
KillaByte Registered User Join Date: Jun 2009 Location: Germany Posts: 77	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.

16 October 2009, 08:45	#14
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	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.

31 October 2009, 19:34	#17
gilgamesh Linux snob Join Date: Sep 2008 Location: Monkey Island Posts: 997	The qemu M680x0 emulation project at gitorious looks interesting. There's not much info, though. Sorry, no fact. But maybe still interesting?

31 October 2009, 21:33	#18
r.cade Registered User Join Date: Aug 2006 Location: Augusta, Georgia, USA Posts: 548	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?

13 October 2013, 16:16	#19
Romanujan Registered User Join Date: Dec 2007 Location: Szczecin/Poland Posts: 424	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...

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)