Question about JIT

[Atheist]

JIT, "Just In Time", the conversion of instructions from 680x0 instructions to a combination of PPC RISC instrutions that achieve the same thing in the CPU.

Can this be done, a 680x0 program, be run through a RISC JIT, and then that combination of commands be saved back to disk as a new file. Then just run that "RISCed" program, from then on? Could this be done to a BASIC program?

On one end its CISC command A, then it gets converted to RISC command B (C, (D)), just save it then to disk and build the new program. It would have to examine the branches as well.

[xeron]

In theory this is perfectly possible. It would just be a compiler for the "68000" language.

[Warface]

AFAIR Coyoteflux or some other group made a 68K->PPC converter or the like. Never heard overly positive reports though, and I myself never tried it.

[PiR]

Well, I think it could be done but...
for what purpose? :-)

If you have the binary - leave it as it is. It was the best thing programmer and original compiler could think of. Mayby after few years you'll have better JIT tool, so why to spoil the binary with something worse? And if you want native code - better take the sources and the native compiler IMO. The result will be MUCH better.

Speaking about BASIC - there was (and still is) a tool for Amiga (and ST) called GFA BASIC that compiled the BASIC code, before running it.

[Karlos]

@Atheist,

I can see what youre getting at but there wouldn't be a lot of point. The only real bottleneck in many JIT systems is the transcription time, which you would eliminate this way. However, as any winuae user could point out, the transcription overhead really isnt noticable at all. Even this grumpy old K6-2 outperforms a genuine 68060 by a factor of 4x or so. I can imagine a well written PPC JIT for 680x0 emulation could be a lot better still (eg, you could keep the 680x0 registers in PPC registers and still have room to manouvre).

xeron wrote:
In theory this is perfectly possible. It would just be a compiler for the "68000" language.

Agreed, but I can see some real nasty problems with any form of self modifying code, or code that makes assumptions about address spaces etc.


As for that CoyoteFlux thing, it was called PPC680x0 and worked at source code level only, IIRC.

[yoodoo]

Speaking of GFA BASIC...

I'm always surprised it never pops up more when everyone clamours for an "easy" language for AOS4/MOS.  It always seemed quite cleanly implemented (compared to AMOS) and not quite so hacky (compared to Blitz).

Time to fire up another porting/release the code petition on ANN

[Warface]

The only real bottleneck in many JIT systems is the transcription time, which you would eliminate this way. However, as any winuae user could point out, the transcription overhead really isnt noticable at all.

Thinking more about the issue...

Dunno about WinUAE JIT, but on morphos Trance is a task in the background, and fiddles with the code in the spare time of the CPU, so you can't notice stops in the code running - only that it gets hell a lotsa more faster after the first 2-4 loops.

The two goals with "precompiling" 68K binaries into JIT PPC code can be the following two: speed and lessening memory consumption (no use of JIT buffers).

However:

The speed issue - the only extra speed you gain is the first 2-4 loops run by the non-JIT compile. That's not that much to make all the fuss worth it. The non looping code is pretty irrevelant speed wise.

The memory usage issue: JIT only buffers the looping code, and the non-JIT 68K emulator uses some memory too. It seems that a precompiled program can gain a lot - but it's a false impression. PPC code is occupying much larger space usually than 68K code (it's because of cache aligning issues and others(

So all in all, having precompiled JIT code is not that big idea at all, and have little advantages, not to mention, it even has some drawbacks...

[iamaboringperson]

What I'm thinking, is if you are talking about basic programs, wouldn't it be a better option to just write a ppc base basic compiler? To me that would be a much better option than just a 68k->ppc compiler.

Are you refering to source code you have?

[Dr_Righteous]

You can always run it through a disassembler then run it through the PPC converter... Dunno how well that'd work, but hey...

[Atheist]

iamaboringperson wrote:
Are you refering to source code you have?

For instance Power Packer, the source might not be available, so the JIT converts every instruction to PPC then runs it. I thought the JIT could be used to run the program, command by command, but instead of running, it saves the resulting commands into a file. Effectively converting it into a PPC program.


A1!

[ncafferkey]

Atheist wrote:

For instance Power Packer, the source might not be available, so the JIT converts every instruction to PPC then runs it. I thought the JIT could be used to run the program, command by command, but instead of running, it saves the resulting commands into a file. Effectively converting it into a PPC program.

This is known as static translation rather than JIT's dynamic translation. There are several problems in getting this approach to work at all, including the difficulty of finding all the code, and self-modifying code (but any program in this category isn't properly written anyway).

I agree that there usually won't be much advantage over JIT in speed, but I'm not so sure about memory. Isn't it the case that UAE and Amithlon require many megabytes of JIT cache to perform well? Not many binaries are that large!

I've written a static translator for the Atari VCS, but that was relatively simple because the VCS is so basic and has it's code in ROM.

[Karlos]

ncafferkey wrote:
I agree that there usually won't be much advantage over JIT in speed, but I'm not so sure about memory. Isn't it the case that UAE and Amithlon require many megabytes of JIT cache to perform well?

Well, WinUAE has from 1-8Mb cache for the JIT, so you could argue it's not that much. It works very much like an instruction cache on a CPU, the most recently/frequently used code is cached there. I have experimented with the size to see what difference it makes. Overall bigger is better but to be honest, I haven't noticed much difference between them. I just set it to 8Mb to reduce the transcription overhead (I guess it covers the kernel and whatever application I am running), but even with a 1Mb cache it seems to run pretty well. No doubt compact amiga code helps there ;-) The code part of any program is usually fairly small...

[Karlos]

Atheist wrote:
For instance Power Packer, the source might not be available, so the JIT converts every instruction to PPC then runs it. I thought the JIT could be used to run the program, command by command, but instead of running, it saves the resulting commands into a file. Effectively converting it into a PPC program.

Not quite. A JIT usually works on blocks of code. A block is transcripted the first time it is used and the transcripted block is then stored for later re-use. It can be purged if not used again and replaced with something else. This way the amount of memory needed is reduced, we simply cache upto a predefined amount of transcripted code.