68000 Exceptions on 68030 Emu & Emu Style?

[DavidS]

Background First:

I am attempting to get a port of EmuTOS with some extras to run almost native on the Raspberry Pi 2/3. I say almost native as it is running on a emulated 68030 (mostly, no MMU yet), though the drivers are GEM, BIOS, XBIOS and TSR on the 68030 side. The exception being that the core USB driver is on the ARM side and loaded before the 68030 emulation (at least for now), as the Keyboard and Mouse are USB.

The 68030 core I am implementing is going to allow the multi core usage (one per ARM core, so 4 68030 cores).

The trouble 1 Exceptions:
I seem to be having some trouble with the 68030/68020 exception stack, not sure which portion is the trouble maker, though it is there.

I have no trouble at all if I just compile for 68000 and use the 68000 style exception stack.

As such I am wondering if there would be any problem if I implement the CPU emulator using a 68000 style exception stack while supporting the 68030 instruction set and full 32 bit addressing?

Trouble 2 Emulation Model:
Using a lazy JIT emulation I am thus far getting slower results than using a simple hand optimized ARM Assembly software emulation.

Is it worth it to keep on attempting to get the lazy JIT up to speed, or should I just focus on the software emulation?

Thank you in advance:
I thank anyone for there input in advance.

[AtariZoll]

By interrupts only difference in stackframe is additional 16-bit Vector offset saved in case of 68010-30 . Addresses are full 32-bit at every 68000 CPU in stackframe. I don't think that problem is stackframe. Unless there is case of incorrectly set stackframe flag/system variable in EmuTOS.

I don't know much about EmuTOS. As see, you did some port of it. Maybe there are some important parts missing, or not used properly in code ?

In TOS 2.06 there is test for stackframe system variable (set according to detected CPU at boot) at every trap, and then using proper code section. Probably something similar is in EmuTOS.

May I ask what you making - what can do with 4 emulated 68030 "cores" ?

[SteveBagley]

Trouble 2 Emulation Model:
Using a lazy JIT emulation I am thus far getting slower results than using a simple hand optimized ARM Assembly software emulation.

Is it worth it to keep on attempting to get the lazy JIT up to speed, or should I just focus on the software emulation?

It's a good question actually -- Darek Mihock, author of Gemulator (and then writing emulators at Microsoft and Intel), wrote some fascinating blog posts on this very issue, see:

http://emulators.com/nx_toc.htm

There's a lot of stuff, but there seems to be a short-ish summary in this:

http://emulators.com/docs/VirtNoJit_Paper.pdf

He definitely favors the trad. emulation approach over JITting… It's also worth bearing in mind that JIT will only benefit when you can amortize the cost of compilation by running the code many times.

Steve

[BlankVector]

I am attempting to get a port of EmuTOS with some extras to run almost native on the Raspberry Pi 2/3. I say almost native as it is running on a emulated 68030 (mostly, no MMU yet), though the drivers are GEM, BIOS, XBIOS and TSR on the 68030 side.

Very good, this is the thing to do.
Then you could later move the some parts to native ARM, it that makes sense.

I seem to be having some trouble with the 68030/68020 exception stack, not sure which portion is the trouble maker, though it is there.

The first question is to determine which kind of trouble. And use a debugger or some traces to see what happens.

Regarding to EmuTOS, at startup it autodetects the actual CPU. Then it uses the proper stack frame where appropriate. The first thing to check is to verify which CPU is detected.

Is it worth it to keep on attempting to get the lazy JIT up to speed, or should I just focus on the software emulation?

JIT or multi-core support are nice speed-ups, but if the whole thing does not work at all, that's useless.

[DavidS]

Trouble 2 Emulation Model:
Using a lazy JIT emulation I am thus far getting slower results than using a simple hand optimized ARM Assembly software emulation.

Is it worth it to keep on attempting to get the lazy JIT up to speed, or should I just focus on the software emulation?

It's a good question actually -- Darek Mihock, author of Gemulator (and then writing emulators at Microsoft and Intel), wrote some fascinating blog posts on this very issue, see:

http://emulators.com/nx_toc.htm

There's a lot of stuff, but there seems to be a short-ish summary in this:

http://emulators.com/docs/VirtNoJit_Paper.pdf

He definitely favors the trad. emulation approach over JITting… It's also worth bearing in mind that JIT will only benefit when you can amortize the cost of compilation by running the code many times.

Steve

Thank you for that. I would say it is quite worth going with a simple translation emulator.

[DavidS]

I figured out the stack frame trouble. I was doing an extra bytswap that was unneeded (as oposite endianes between the 680x0 and the ARM in the Raspberry Pi's).

Kind of a brain fart on my part.

[DavidS]

I know I have not said anything in a bit, though I am still working on this. It is interesting on the RPi 3B.

I am making heavy use of Aranym on Raspbian Linux in the mean time.