68k -> ??? JIT

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

[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/

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