ARM Emulator bounty?

Would it be a good idea to set up a bounty for a RISC PC emulator?

Based or not on existing source (RPCEmu), with a dynamic recompiler (or better, as code translation for example) and compatibility with RISC OS 3.5 to 5.×. Linux support (as a guest OS) could also be a good solution if the emulated CPU is really fast.

I think it could be useful :
1/ to get access to old software.
2/ to test things on a virtual machine (software or kernel bits)
3/ as GCCSDK driver or Linux helper.

Of course the emulator should be made in a way that implies it cannot hang the host OS.

I could put 200£ or more on this project. Really more if speed is good (50%+ speed of Pi) and Linux support is present.

Is it a good idea?
Is it possible to make this kind of software?
Other suggestions?

What’s wrong with the existing ones?

compatibility with RISC OS 3.5 to 5.×

As the host OS or guest OS? I can’t imagine a RiscPC emulator running on RISC OS 3.5 (i.e. ARM610/ARM710) would be particularly fast!

Is it a good idea?

It’s a good idea. But I’m not sure if it’s suitable for a bounty – the ROOL bounties tend to focus on improving OS components rather than improving 3rd party software (assuming an exiting emulator like RPCEmu is used as the basis)

On the other hand, creating a high-performance ARM-on-ARM dynamic recompiler which can deal with emulating the MMU isn’t a trivial task.

Is it possible to make this kind of software?

Of course! It’s something I’m interested in doing myself, if I ever have enough spare time.

What’s wrong with the existing ones?

I’m assuming he’s talking about creating a Risc PC emulator which runs on RISC OS, or maybe just an emulator which will run on ARM. And there aren’t any existing emulators which will do either of those things (at a usable speed).

What’s wrong with the existing ones?

The RPC emulators? There is no RPC emulator for RISC OS.
The bounties? They are all greats :)

As the host OS or guest OS? I can’t imagine a RiscPC emulator running on RISC OS 3.5 (i.e. ARM610/ARM710) would be particularly fast!

Guest OS.

It’s a good idea. But I’m not sure if it’s suitable for a bounty – the ROOL bounties tend to focus on improving OS components rather than improving 3rd party software (assuming an exiting emulator like RPCEmu is used as the basis)

OK, I see my mistake now… I speak of a RPC emulator (or a port of a RPCEmu) for RISC OS.
The point is that 1/ it would help for 26 bits software and 2/ if speed is good, it would be a great starting point for ROS virtualization under ROS.

I’m assuming he’s talking about creating a Risc PC emulator which runs on RISC OS, or maybe just an emulator which will run on ARM. And there aren’t any existing emulators which will do either of those things (at a usable speed).

Correct :)

A competitor for Aemulor?

Or of Archemu…
… but for RISC PC emulation.

Instead of an emulator would it not be more prudent to extend RO to support a hypervisor?

The latest ARM chips have hardware support for this and it may be possible to implement a hypervisor of some sort for IOC and IOMD on ARMv4+

Instead of an emulator would it not be more prudent to extend RO to support a hypervisor?

I think you’re a little confused over what a hypervisor is. A hypervisor is a means for multiple operating systems to coexist. It won’t do anything to help with the fact that RISC OS 3/4 will be assuming a RiscPC-era CPU and other hardware – so you’ll still need an emulator to deal with all of that.

Whether the emulator is a standard RISC OS application or sits in some kind of hypervisor framework is basically irrelevant; we still need the emulator to begin with!

Strictly speaking its a means of presenting the guest host with a virtual hardware platform.

I get what you’re saying though. What I’m getting at is that without the host OS being aware of guests, you’re stuck with basic emulation which is slow. If the host is aware, you can hypervise the physical hardware and in particular speed up memory access which is the performance killer.

For example, if you were to move the vectors high and map the entire lower memory range in/out when the host OS passes to the guest, you’ve saved a ton of code and performance having to either emulate or trap memory access. The rest of the guest hardware platform is emulated, the exception being the CPU which can be covered by a JIT as 90% of instructions are forward compatible and can be left to run native.

What you’re then left with is implementing shared interfaces for devices, such as HD / IO etc which is where the host OS needs to be aware of the guest accesses at HAL level and the guess needs to use hypervised drivers.

Somewhat tangentially, perhaps, but prompted by the mention of Linux as a guest OS – what would the hurdles be to overcome in developing a WINE-like solution? Where the actual processor is the right one to run a given binary, CPU-emulation is irrelevant but you need to give the binary the right access to the CPU and the right software environment in which to do its stuff.

Remember RISCOSE? but (from memory) that was at a time when ARMLinux was far less mature and the idea looked more at implementing RISCOS-like behaviour for x86 (and other) Linux applications.

In the meantime, I’ll be getting a Pi2 for Raspbian and use the B only for RO5 (with Aemulor).

The idea of riscose was to run existing RISC OS binaries on Linux. I think there was ARM emulation and implementations of each SWI.

Also http://robe.sourceforge.net

IMHO, it’s really too much work. To use a Pi version of RISC OS under virtualization would be much simpler. And fast too.

The idea of riscose was to run existing RISC OS binaries on Linux. I think there was ARM emulation and implementations of each SWI.

So, I imagine, easier to achieve without the ARM emulation stage? Not that that would necessarily make it easy enough to be worth pursuing, of course!

Interesting idea. Implementing a CPU JIT would be fairly easy This could be done using a module with a set of SWI’s or other means, to implement handling of modifications to flags in 26 bit R15, as well as for the MMU operations.

The extended HW emulation could take a bit more work, though it is all well documented. If you map the HW registers to be non-readable/non-writable and trap access exceptions to those memory areas, you could more easily implement the extended HW emulation.

I do think that this could be done as a part of RISC OS, as that would improve the potential performance, and allow running any RiscPC version of RISC OS.

If I can add to the idea:
How about also including a bounty for a version of RISC OS 5 that runs in 26 bit mode on RiscPC hardware and emulators, thus providing better compatibility with older software.

To clarify on the concept of JIT emulation. Maintain two copies of the emulated memory area, have address translation done as a portion of loading. Replace any and all writes to R15 that modify the flag bits, all SWI calls, all coprocessor access, and all reads from R15 that expect the flags to be preserved with one of a few SWI calls that would look at the original, untranslated copy of memory for the original instruction, and do a quick software emulation of that instruction.

Doing things this way should make it possible to achieve speeds of as much as 50% of the host system.

There would have to be someway to make sure to call Wimp_Poll often enough to allow other things to run, though that is a thought for whoever implements such a thing.

I noticed Running RISCOS on QEMU while searching for something else. Jon also seems to have spotted it back when it happened. Perhaps someone might want to chase up the developer and encourage him to revive it.

There’s also the ARM-on-ARM JIT that I started work on for ArcEm (with the view that it could later be ported to RPCEmu).

https://www.riscosopen.org/forum/forums/3/topics/9211?page=2#posts-67260

At some point I’d like to return to it, but I’ve got no idea when that will be.

There’s a dusty one of mine, here: https://sourceforge.net/p/ro-lf/code/HEAD/tree/ROLF/rolf/Libs/Compatibility/

Seems like this could become more important now to keep RISC OS going. There now exist 64-bit only ARM CPU’s, so what does this mean for RISC OS in 15 or 20 years, will the 32-Bit ARM fade away? If we lose the 32 bit ARM we will need an alternate way to keep RISC OS going on newer HW.

I know this is an old thread, but I think somebody managed to compile the Qt version of RPCEmu for RISC OS, and apparently it runs. I don’t know what kind of glitches there were, but ISTR the basics worked.

I know this is an old thread, but I think somebody managed to compile the Qt version of RPCEmu for RISC OS, and apparently it runs. I don’t know what kind of glitches there were, but ISTR the basics worked.

Chris Gransden had a version running, but it had problems with key presses (RPCEmu uses some kind of low-level Qt call that is not properly implemented in RISC OS Qt and also not in MacOSX Qt).

And it was “interpreter only”, so no ARM-on-ARM JIT yet!