68k -> ??? JIT

[bloodline]

Hi all, since I have a spare hour, my mind has been wandering back to A.org discussions of old and I thought I might start a new one.

I have been reading up about the new WebKit FTL JIT, and it's facinating. It's no secret that the 68k->x86 JIT in UAE is a scary beast that no one wants to touch, which is a shame since it's somewhat stuck in the past, and unable to benefit from modern CPU features that the x86-64 offer and obviously it's not portable to alternative architectures like the ARM (and the new ARM64).

It would be nice if the remaining devs who visit this site could throw a few thoughts into this thread about their understanding of JIT compilers and how we could optimise portable 68k emulation.

:-)

[Rob]

Have you looked into Rachy's 68k-PPC JIT for E-UAE.

[bloodline]

Have you looked into Rachy's 68k-PPC JIT for E-UAE.

I haven't and probably should... My thoughts are around something more "generic", hinting towards LLVM options ;-)

[Heiroglyph]

Aranym has x64 working and Arm in progress. They use the UAE JIT and were the originators of the MMU that UAE is using I believe.

I know it's not what you were getting at, but it's something.

[bloodline]

Aranym has x64 working and Arm in progress. They use the UAE JIT and were the originators of the MMU that UAE is using I believe.

Good spot! I've just had a look and it seems they do have a JIT in development for the x86-64. I can see suggestions of an ARM port, but I'll have to look deeper to see.

I know it's not what you were getting at, but it's something.

Actually, while I was hoping for something more generic, given that it is VERY unlikely we will see any new CPU architectures other than the X86-64 and the ARM for a very long time, this news is better than I had hoped.

I guess when Toni gets bored with PPC support, we will see these Aranym JITs back ported to UAE :-)

[Thorham]

Makes me wonder if it's not an option to use some other language's JIT compiler. Something that's available for many systems, like Java. Compile 68k to Java byte code, Java JIT compiles byte code to target machine code.

[Heiroglyph]

Good spot! I've just had a look and it seems they do have a JIT in development for the x86-64. I can see suggestions of an ARM port, but I'll have to look deeper to see.

Yup, look here: http://wiki.aranym.org/platform_specific_information

...ARM (experimental) currently support JIT compiler for the CPU emulator...

I've written a pretty basic 680x0 emulator with partial JIT support, but it's hard to beat the UAE JIT for code coverage, performance and reliability, especially with so many projects depending on it.

Syn68k is interesting and somewhat portable, but their lisp-like syntax for opcode descriptions is pretty daunting to muddle through.

All the others I've seen are just straight up interpreters, so they're portable, but all brute force.

Actually, while I was hoping for something more generic, given that it is VERY unlikely we will see any new CPU architectures other than the X86-64 and the ARM for a very long time, this news is better than I had hoped.

Agreed, although I'm personally more interested in runtime environments like the one in MorphOS or Wine than emulators.

I'd love to see a JIT that was portable, but focused purely on speed and not perfectly emulating the quirks of ancient hardware.

Vamos would be a great platform to develop other than it's mostly written in Python. I keep thinking of rewriting it in C and adding a JIT (probably UAE), but it's a pretty big codebase for someone that doesn't know Python. I can stumble through reading it like any programming language, but it's awkward and I'm really not interested in Python as a language.

I guess when Toni gets bored with PPC support, we will see these Aranym JITs back ported to UAE :-)

I'm sure he'll do it at some point. I'm pretty sure he stays in contact with them.

I would be interested in whether they are taking advantage of the extra registers and whether it's faster. The overhead of x64 sizes might make it a break even for emulating a 32bit CPU.

[Heiroglyph]

Makes me wonder if it's not an option to use some other language's JIT compiler. Something that's available for many systems, like Java. Compile 68k to Java byte code, Java JIT compiles byte code to target machine code.

I think you might be better served with a register based VM than a stack based VM though.

Android's Dalvik is register based (I think), and Swift.

I've been meaning to look into Sljit for the same reason but haven't had much time lately. http://sljit.sourceforge.net/

[bloodline]

Yup, look here: http://wiki.aranym.org/platform_specific_information


Vamos would be a great platform to develop other than it's mostly written in Python. I keep thinking of rewriting it in C and adding a JIT (probably UAE), but it's a pretty big codebase for someone that doesn't know Python. I can stumble through reading it like any programming language, but it's awkward and I'm really not interested in Python as a language.

I was interested in Vamos too, but I got so bogged down in Python, gave up... I can't figure out how the Python->C bridge works so he is able to use the 68k interpreter he uses.

If you rewrite it in a sensible language like C, I'll be right back with you.

I would be interested in whether they are taking advantage of the extra registers and whether it's faster. The overhead of x64 sizes might make it a break even for emulating a 32bit CPU.

Hmmm, doesn't x86-64 allow you to treat registers as halves, upper and lower, so any logic/arithmetic operations would be 32bit in the respective halves (with overflows etc)? Or am I confusing it with ordinary x86?

If I'm right, you could pack two 68k registers (perhaps just the 68k address registers) in a single x86-64 register and that would definitely confer a speed advantage.

[Heiroglyph]

Hmmm, doesn't x86-64 allow you to treat registers as halves, upper and lower, so any logic/arithmetic operations would be 32bit in the respective halves (with overflows etc)? Or am I confusing it with ordinary x86?

If I'm right, you could pack two 68k registers (perhaps just the 68k address registers) in a single x86-64 register and that would definitely confer a speed advantage.

Not really.  You can access the lower 32bits, but accessing the upper 32 requires a lot of manual work, plus many instructions zero out the upper 32 bits when accessing the lower half of a register.

I had considered using SSE registers for less frequently accessed 68k registers that would need to otherwise be dumped back to memory. It would waste a huge number of bits per register and be slower than direct register mapping, but would be far faster than a memory access.

That's not in the least portable though and Arm is only getting more popular.

[psxphill]

I haven't and probably should... My thoughts are around something more "generic", hinting towards LLVM options ;-)

I know someone else that wants to use LVVM for DRC in emulators, so I'm interested in hearing if anyone ever does do it.

[matthey]

Hmmm, doesn't x86-64 allow you to treat registers as halves, upper and lower, so any logic/arithmetic operations would be 32bit in the respective halves (with overflows etc)? Or am I confusing it with ordinary x86?

If I'm right, you could pack two 68k registers (perhaps just the 68k address registers) in a single x86-64 register and that would definitely confer a speed advantage.

Maybe this register sharing sounds good in theory but it's not so practical in practice. In general with both 68k and x86, there are no instructions to operate on the upper half of a register so this data has to be swapped to the lower half of the register, do an operation and then swap back to the upper half (approx. 3 instructions & 3 cycles). Maybe it wouldn't be so bad if the data in the upper half was less frequently used but accessing cache can sometimes be done in 1 cycle with 1 instruction. Samurai Crow has suggested somewhat similar techniques of register sharing for a 68k compiler. That is also limited but there are a few cases where it may be practical. A boolean variable can be used in the upper half of a different 16 or 8 bit variable in a register. Some newer processors like the 68060 can make some internal optimizations when operations the size of the register are used. In most cases it's just not practical to share registers like this.

Edit: Heiroglyph beat me to it

[SamuraiCrow]

Mike "Sidewinder" Ness uses LLVM in an emulator at his current job at Unisys.  He emulates a 36 bit mainframe on AMD64 instruction set.  That's right, 9 bit bytes.

[matthey]

Mike "Sidewinder" Ness uses LLVM in an emulator at his current job at Unisys.  He emulates a 36 bit mainframe on AMD64 instruction set.  That's right, 9 bit bytes.

Register sharing would work in some cases. If the hardware emulating has more general purpose registers than the hardware being emulated and fast bit extraction and/or shift/rotate/swap instructions, the data can be extracted.moved from one register to a temporary register where it is used from. This could be done with 1 instruction and 1 cycle on some hardware. I'm not sure AMD64/x86_64 (16 gp registers) could do this but ARMv8 (32 gp registers) and maybe PPC (32 gp registers) could. The 68k has bitfield instructions that can do this in 1 cycle but they are slow on the 68060 (but could be 1 cycle). The 68k wasn't quite orthogonal enough for me to emulate an x86_32 (8 gp registers) using the 8 68k data registers in DOSBox either. I tried to improve the orthogonality and added x86 equivalent instructions (good for 68k also) with a new ISA which would have helped but Gunnar rejected it for the new Phoenix/Apollo cores. He added more registers (unnecessary for x86_32 emulation but good for emulating RISC) but in a way that won't be very orthogonal.

[bloodline]

Having spent a few days reading, an idea that occurred to me was a 68k-> asm.js compiler and then take advantage of the various JavaScript JITs to speed emulation.