RPCEmu on AArch64 Linux

Has anyone tried this recently? On a Pi 4 w/ Raspbian for example? I presume that the recompiler is a long way off.

A recompiler RPCEmu build on a new 64bit Raspberry Pi OS installation on an RPi400 failed, “Fatal error : no recompiler available for this architecture”. Interpreter built but ran at about RPi0.2 speed.

Ta. Good to know where we are. [ Those RPi0.2, are they still available? ;-) ]

Just seen the new WifiSheep YT running RO 3.71 on a RISC-V64 system (Allwinner D1) using RPCEmu 0.9.4.

Well, it ‘worked’! Sorta ARM2 speed.

Isn’t there a dynarec build for the Apple M1? That should build under AArch64 linux without too much tweaking?

I did start to have a go at writing one, but didn’t realise it’d already been done. There’s nothing much that’s Apple specific that I’d run into code wise IIRC. You may have to enable execution on the JIT code buffers, but that’s about it.

I got it to about double the interpreted version speed, but I had some issues (mainly caused by me not really knowing what I’m doing I suspect).

Here’s a comparison running ROMark5 (Processor – Looped instructions) on RPCEmu interpreter version on a few arm64 and one x86 machine running Linux. Also included is the Geekbench 5 single core score and recompiler on x86

CPU					CPU Clock	Geekbench 5.4		RPCEmu 0.9.4 Interpreter	RPCEmu 0.9.4 Recompiler
							Single Core Score	ROMark5 CPU %age		ROMark5 CPU %age
Apple M1				3.2GHz		1707			147%
Snapdragon 8 Gen 1 (Cortex-X2)		3.0GHz		1222			123%
Snapdragon 8cx Gen 3 (Cortex-X1)	3.0GHz		1250			112%		
Rpi4 Cortex-A72				2.4GHz		 322	 		38%

Intel(R) Core(TM) i7-4770K		4.7GHz		1269			128%				1305%

I should probably mention we have a prototype AArch64 recompiler, whilst still in progress it does offer a significant performance increase over the interpreter.

At some point it’ll be rolled into a future release of RPCEmu.

@Peter: is the AArch64 recompiler open source? I’d definitely would like to beta test that. (on M1)

is the AArch64 recompiler open source? I’d definitely would like to beta test that. (on M1)

Unfortunately not yet. Due to the previous behaviour of those in the RISC OS Market ¹ we no longer feel able to publish work-in-progress code of certain features.

¹ ‘Market’, not ‘Community’

is the AArch64 recompiler open source? I’d definitely would like to beta test that. (on M1)

As I’ve finally got my act together and registered as a dev (and can therefore sign things, in theory, so other’s can run them) you can try my rubbish version if you like, it basically recompiles 1 instruction (I think), badly, but it does still seem to be a bit faster than the interpreter on the M1.

If I’ve managed to wrange Qts packaging tool correctly, there should be a .dmg here:

rpcemu-recompiler

(I make no guarantees it’ll even run, or if it does, then proceed to work to any standard whatsoever… :) )

Edit: I have tried building it on Aarch64 linux (debian to be precise) but it doesn’t work. :( I suspect it may be a GCC vs LLVM vs my generated function calls, but I’ve not investegated further.

If I’ve managed to wrange Qts packaging tool correctly, there should be a .dmg here:

rpcemu-recompiler

(I make no guarantees it’ll even run, or if it does, then proceed to work to any standard whatsoever… :) )

The dmg does run on my M1 Mac mini. The boot is rather noisy, with a loud intermittent buzz. A very very brief look shows this recompiler to be a bit less than twice as fast as the interpreter.

Same here. the dmg runs and for example the Iron Dignity demo runs a bit smoother.
I’ll have a look at building under Linux. (Don’t hold your breath ;-) )

@MrRooster: the memory management fixes for APPLE seem to be quite out of sync with other ARM64 builds. Also GCC has aarch64 as identifier, not ARM64.
It crashes immediately because it tries to run code in a JIT block that is not yet filled. (seems to be a offset issue.)
since you have for APPLE a block size of 4096 but for ARM64 a block size of 1792 it seems there may be some cross talk between the APPLE and ARM64 code.
For now, gdb is quite a help. It will even show the address in the JIT block where it crashed.

@Jan yeah, I did make those changes when trying to get it to build on linux (Marking memory as executable, using aarch64 as well as ARM64, etc..) , it was working as expected, i.e. trying to executed JITd code. (My initial attempts just tried to get it to execute the JIT’d code that calls the interpreted version). But was tripping up… somewhere.

I did only try for a few minutes though, and it was on a linux build running under a VM on the mac, which wasn’t the most stable of environments to develop in. :) (I don’t have these code changes anymore either, they’re not in the build above).

My gut feeling is it’s differences in GCC and LLVMs procedure calls, the Apple code I wrote conformed to APCS64, but I get the impression (from other comments in this forum) Linux might do it’s own thing.

I didn’t really try hard to get it working though, as I’d lost interest in it as I realised it was a bit beyond my current skill levels, and the effort I’d need to put in to learn enough is currently being expended trying to figure out multi processing on x86.

edit: (Also, the people who know what they’re doing are writing one, so it doesn’t seem worth continuing with my ‘knocked up in a shed’ version. ;) )

edit2: Also, just to be 100% clear, that’s very hacky, mid being played around with code. I wouldn’t normally release it, it’s only there because a licence file told me to do so. ;)

With the Pi5, that we can now consider as a competitive desktop computer, full speed Arculator and RPCEmu would be so great :)

With the development of RPCEmu now being closed source and no updates, I think we won’t see anything in the near future.
I much prefer a open-source development of RPCemu. Possibly at gihub?
In the early days of RPCemu it was easy to contribute.

RPCEmu closed source. I was thinking only the other day that if that were to happen it’d be bad. No further developments either?

now being closed source

Is there a source for this?

The code can be downloaded from the site, and it is licensed GPL.

Perhaps it’s just “not as easy” to participate as it could be, especially if the maintainer is currently doing other things…?

Say, to survive as a separate computing platform, is this truly the way to go?

An aarch64 version of the recompiler would be so nice. For Raspberry Pi OS, first, but for the new Apple Silicon Mac too.

Say, to survive as a separate computing platform, is this truly the way to go?

In order to use RISC OS on the latest platforms, ARM or not, emulation is already the only way.

Nota: the work on the open source version of RISC OS 4.00 is also very promising, in order to provide a fully legal solution to users. It’s also interesting, as it could include drivers for new RPCEmu models (Phoebe computer, or a RPCEmu computer).