Integrated 68K in AROS

[bloodline]

So when I was more active in the AROS project I was very vocal about trying to integrate a 68K emulator into the system so older application could be run.

My first idea was to simply let a 68k emulator run in the native environment and see what happens. But endian and ABI issues immediately rule this out.

My second attempt was a project called "Emulatron" (a version of which can still be found on my GitHub) . This ran the 68K emulator in a private address space, with a custom set of exec type libraries, where each function entry had a 0x4E70 instruction, which halted my 68k emulation, allowed me to trap the function call perform the desired operation naively and then return control and any results back to the calling program. Essentially Wine for AmigaOS.

This worked quite well, but was a huge amount of work, and I simply ran out of time and interest, problems with missing hardware features made this project a real headache. The project is still there if anyone wants to carry the torch.

Now, I'm wondering if such an approach could be made the other way around. Since I now have a working Amiga Emulator which can boot Amiga OS and run programs. Perhaps this idea can be revitalised, but starting with a working Amiga emulation and then patching the OS running in the emulation (or preferably running a special build of 68k AROS) to call the native AROS functions via a similar mechanism I used in Emulatron.

Anyway, I wanted to open this up for discussion! Let's discuss.

[clebin]

On a related note, have you seen Michal Schulz's current work on Patreon? Port of AROS to ARM/RPI and transparent JIT 68k emulation.

https://www.patreon.com/michal_schulz

[bloodline]

Originally Posted by clebin

On a related note, have you seen Michal Schulz's current work on Patreon? Port of AROS to ARM/RPI and transparent JIT 68k emulation.

https://www.patreon.com/michal_schulz

We have been in communication about this

[mschulz]

Originally Posted by bloodline

We have been in communication about this

Indeed, and during the discussion it turned out we have few different ideas. The question is, which would you all prefer

Matt's idea is to use M68K JIT running on bare metal ARM and emulating parts of the Amiga chipset. One could run AmigaOS on top of it and eventually replace parts of it (or maybe whole AmigaOS later on) with AROS.

On the other hand, I have nearly complete m68k JIT designed explicitly for ARM, where every m68k instruction is translated to (statistically) 2 ARM instructions, only, giving a hope for really good performance. First tests with synthetic as well as real world benchmarks oscillate around 630 MIPS on RasPi 3b+. Now, my approach would be, to run the m68k JIT directly on RasPi (bare metal, no other operating system above us!). Then, instead of emulating chipset and running AmigaOS on top of it, we could run m68k AROS with all the drivers needed for RasPi. That would be something like Amithlon, but for ARM, without Linux and with all drivers provided directly by AROS.

Of course I will also integrate my JIT in ARM-BE version of AROS, no doubt. The m68k AROS on RasPi is just a nice idea to toy with.

What do you think?

[bloodline]

For the record, I find Michal's approach more exciting long term. My idea is to try and get things moving quickly.

[gulliver]

Originally Posted by mschulz

On the other hand, I have nearly complete m68k JIT designed explicitly for ARM, where every m68k instruction is translated to (statistically) 2 ARM instructions, only, giving a hope for really good performance. First tests with synthetic as well as real world benchmarks oscillate around 630 MIPS on RasPi 3b+. Now, my approach would be, to run the m68k JIT directly on RasPi (bare metal, no other operating system above us!).

A bare metal Amiga 68k virtualization/emulation with JIT on a Raspberry Pi is to a me a fantastic idea.

BTW, if you really get over 500 mips on it, it will certainly make the Raspberry Pi a very atractive choice to anyone.

I am looking forward to any progress on this.

[ptyerman]

Sounds great! Anything Amithlon alike should also be well received.
An Amithlon alike system on ARM is what a lot of people have dreamed of for a while!

[mschulz]

Originally Posted by gulliver

BTW, if you really get over 500 mips on it, it will certainly make the Raspberry Pi a very atractive choice to anyone.

Well, these are the numbers I see It's not a CPU performance test but instead a 4bpp chunky2planar procedure (http://coreprogramming.pl/c2p/WPA.s.txt) processing a 25600x4800 pixel (about 122 megabytes) large chunky bitmap. I have decided to use c2p as a test because it uses almost all available m68k instructions (my JIT has cache for only 8 m68k registers) Now, single loop of this procedure converts 32 bytes of input data and one loop is 100 m68k instructions long.

There are 3840000 iterations with 100 instructions each, so to say 384 millions of m68k opcodes to execute. On RasPi3b+ it takes about 0.6 seconds.

I will try to run dhrystone test asap, since this one should give slightly more reliable results

[hooverphonique]

So this m68 JIT is not just a cpu emulator, but must also forward any AmigaOS calls from a running m68k app to AROS (below the emulator), and then return the result back to the app through the emulator, is that correctly understood?

[mschulz]

Originally Posted by hooverphonique

So this m68 JIT is not just a cpu emulator, but must also forward any AmigaOS calls from a running m68k app to AROS (below the emulator), and then return the result back to the app through the emulator, is that correctly understood?

Yes and no. Currently the m68k JIT is *just* a CPU emulator aimed only at fastest possible execution of the code, without looking back at small nuances such as instruction timing. When integrated with AROS it will allow switching between m68k mode and ARM mode in order to provide as close m68k integration as possible (with some luck comparable to Pecunia/Trance).

On the other hand, when run directly on RasPi, one could use this JIT to execute the m68k on bare metal ARM machine (with some slowdown of course) and e.g. compile entire AROS as m68k code with drivers for Raspberry. That way you would in principle turn RasPi to a m68k virtual machine running AROS m68k and all classic software on it. No, AmigaOS would not work since the JIT translates only the CPU code, no Amiga hardware support there. Think of Chipset-less Amiga clones such as DraCo

[Gorf]

What do you think?

All of it!

No, seriously: I think a combination of your efforts would be best.

I see the charm of letting the 68k-JIT run on bare-metal, "below" the OS.
But how about allowing native ARM-code to bypass the JIT? (and execute it maybe on the second core?)

This way the result should be almost the same as running the JIT under ARM-AROS ... with just kind of a reversed default. Would this be possible?

And additionally a 68k-binary should be able to run in "high compatibility mode", that provides (some) chipset emulation. This should be selectable like via tool types or cli.

Too ambitious?

[hooverphonique]

Originally Posted by mschulz

Yes and no. Currently the m68k JIT is *just* a CPU emulator. When integrated with AROS it will allow switching between m68k mode and ARM mode in order to provide as close m68k integration as possible.

But what is the point of an m68k mode if not compatibility with classic amigaos binaries then? With the emulator on top of AROS, where are os calls from amigaos apps supposed to go, if not through the emulator?

Originally Posted by mschulz

On the other hand, when run directly on RasPi, one could use this JIT to execute the m68k on bare metal ARM machine (with some slowdown of course) and e.g. compile entire AROS as m68k code with drivers for Raspberry. That way you would in principle turn RasPi to a m68k virtual machine running AROS m68k and all classic software on it. No, AmigaOS would not work since the JIT translates only the CPU code, no Amiga hardware support there. Think of Chipset-less Amiga clones such as DraCo

But is AROS compiled for m68k ABI-compatible with classic amiga binaries?
How would AROS talk to its RasPi drivers in this case?

[Gorf]

Originally Posted by hooverphonique

But what is the point of an m68k mode if not compatibility with classic amigaos binaries then? With the emulator on top of AROS, where are os calls from amigaos apps supposed to go, if not through the emulator?

What makes you think it would not be compatible with "classic amigaos binaries".
At least with system friendly ones it should.
Just like on MOS or OS4.
For software/games that need direkt access to the hardware, some other emulation layer is needed of course.
This could be some UAE-version or Matt's bare metal emulation

System calls from the 68k-side could be handled by its counterparts on the ARM-side and/or by a set of (duplicate/fake) 68k libraries.

But is AROS compiled for m68k ABI-compatible with classic amiga binaries?

Yes - that is the whole point of AROS 68k. And it works mostly.
You can test "AROS Vision" on UAE.

How would AROS talk to its RasPi drivers in this case?

via libs/handlers?

but a good question.

[hooverphonique]

Originally Posted by Gorf

What makes you think it would not be compatible with "classic amigaos binaries".

If the emulator is just a cpu emulator, OS calls from m68k amigaos apps would have nowhere to go - they won't find their way to AROS (on the ARM side) just by magic.

Originally Posted by Gorf

At least with system friendly ones it should.

I'm only talking system friendly here

Originally Posted by Gorf

System calls from the 68k-side could be handled by its counterparts on the ARM-side and/or by a set of (duplicate/fake) 68k libraries.

Yes - this is what I was talking about above for it to work.

[bloodline]

Originally Posted by Gorf

All of it!

No, seriously: I think a combination of your efforts would be best.

I see the charm of letting the 68k-JIT run on bare-metal, "below" the OS.
But how about allowing native ARM-code to bypass the JIT? (and execute it maybe on the second core?)

This way the result should be almost the same as running the JIT under ARM-AROS ... with just kind of a reversed default. Would this be possible?

And additionally a 68k-binary should be able to run in "high compatibility mode", that provides (some) chipset emulation. This should be selectable like via tool types or cli.

Too ambitious?

Indeed, I don’t see our efforts as mutually exclusive, but we are gong need a serious chat about how Emu68 handles interrupts...

[mschulz]

Originally Posted by hooverphonique

But what is the point of an m68k mode if not compatibility with classic amigaos binaries then?

Misunderstanding. At the current state (it is under development and not yet complete) this is just pure m68k code translator which cannot call anything on the host side. This is so due to the way I develop it: I'm working on the source code on macOS, cross-compile the code to 32-bit ARM binary which I finally execute through qemu-arm running on Docker (linux virtual environment). Please keep in mind the project is in extremely early stage (it is few weeks old, only!). For that reason it is easier for me to concentrate on m68k emulation aspects first, leaving the integration with AROS for later.

But since you ask exactly this, here is how the emulator will work, at least more or less. On ARM side the pages with m68k code will be marked as XN (eXecute Never) so that an attempt to jump there will trigger a page fault. The exception handler will recognize that a call to m68k code was requested, will jump back to user mode, return address (of ARM code) will be pushed on the m68k stack, Program Counter will be set and main JIT execution loop will start.

The loop will work as following:

- Check if current PC corresponds to ARM or m68k code. If ARM, then leave JIT loop
- Request translation unit (something like instruction cache) for given m68k PC. The JIT engine will either return the unit immediately in case it was already translated and is still in the cache, or will perform translation.
- The ARM code in translation unit will be called. As a result of the above code call the PC might have changed
- Go back to step 1.

The details are not absolutely polished yet and I am aware that this is just a rough plan, but this is more or less how it will work. Such construction will allow me to jump from ARM code to m68k code (either directly by calling JIT engine or through MMU page fault handler) and to call ARM code from m68k code.

Originally Posted by hooverphonique

With the emulator on top of AROS, where are os calls from amigaos apps supposed to go, if not through the emulator?

As described above. Additionaly, the ABI of big endian AROS on ARM will be adjusted so that library call to the function is feasible from both m68k and ARM sides.

Originally Posted by hooverphonique

How would AROS talk to its RasPi drivers in this case?

That depends on which project idea we are talking about. In case of regular ARM-based AROS the whole AROS can be ARM code and as such does not need anything particular to talk to the ARM hardware.

If we are talking about bare metal m68k cpu emulator, then one could talk to the ARM hardware from m68k side with ease. The ARM cpu does not have any IO ports with special instructions, everything is accessible through MMIO (memory mapped IO). Therefore, it would be theoretically possible to compile all hardware drivers as well as nearly entire AROS as m68k code and let it all run through m68k JIT.

Please note our hardware drivers are written in C and, therefore, it does not really what CPU they are compiled for.

PS. Please forgive me if something is unclear. As said - very early stage

[hooverphonique]

Originally Posted by mschulz

PS. Please forgive me if something is unclear. As said - very early stage

Thanks for the clarifications - no need for apologizing