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

the work on the open source version of RISC OS 4.00 is also very promising

Do you have any pointers to where this work is happening?

the work on the open source version of RISC OS 4.00 is also very promising

Do you have any pointers to where this work is happening?

I think it’s a reference to Peter’s work on the RISC OS 4.00 which was kept going within Pace, ie. he’s based it on the last 26 bit commit to the kernel from ROOL’s sources (before the HAL-ification started) then grafted on either contemporary modules or where applicable the more recent code from ROOL’s tree (since things like the Wimp can still be built as 26 bit since they appear PlingSystem).

It’s not a reference to RISC OS Limited’s RISC OS 4.00 which branched off a few years earlier. Nor RISC OS Select.

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.

What is the problem with the legality of existing solutions? Like “I use my RISC OS license with the emulator” or “I bought the Classic RISC OS ROM collecton” or “I bought the RISC OS 4 Virtually Free”?

Of course, having an Open Source version has other advantages, and having it for free is also an advantage.

It’s also interesting, as it could include drivers for new RPCEmu models (Phoebe computer, or a RPCEmu computer).

At least one of the Howkins brothers are on record saying to be not interested to develop RPCEmu into a direction different to “perfecting classic hardware emulation”. The fact that RPCEmu still does not implemennt virtual RISC OS 5 hardware after more than 16 years is a strong sign that developers seem to be not interested in that path. How will a 26bit post-RISC OS 3.71 pre-RISC OS 4.0x change that?

now being closed source

Is there a source for this?

Not sure if you deliberately shortened the quote the way you did it. Jan said “With the development of RPCEmu now being closed source and no updates” which describes the current situation quite well – between releases, no code changes and hence no development is done in a publically available repo. There are still source drops for all release versions of course, as required by the GPL.

So you could say that “RPCEmu is still Open Source” and you could also say “RPCEmu development is no longer as open as in the past”. Although what this “past” means is unclear, because it went through some different ways of organizing the development, including various forks.

In the past I have had an active part in the development of RPCemu.
That was possible because the development was open to all.
There has been a gradual shift to closed source development with many open source projects.
The consequence of that shift is that it allows for a closed source version that runs in parallel with the ‘open’ source version. Where the closed source version is often more optimized and contains features that are not released to the public. Often this is accompanied by a commercial version of the same product.

It’s rather unfair to those that contributed to be shut out of development and at the same time money is made by people from their contributions..

In the current world of RISC OS there is still a viable market for an emulator etc. However there were already commercial emulators.

No matter what, the future of open-source development of RPCemu is now in the hands of a few and it is clear that ‘they’ will decide what you can have and what not. Also it is clear that they are reluctant in sharing any development of a ARM64 JIT and deny others to contribute. (apparently the development is already done for many years!)
If RPCemu is now owned by a company then that should be done properly as well as being made clear to the general public.

All opinions aside, my message is simply ‘say what you do and do as you say.’ That will clear up misunderstandings and misconceptions.

Bottomline: RPCemu is useful for many people and allows them to run RISC OS on many platforms. That user-base is always grateful for released improvements and updates. They never complain.

Unfortunately platforms like OSX (Apple) have been quite unpopular with the RPCemu developers. This has resulted in unofficial releases from third parties and even that can’t keep up because the development is behind closed doors.

My personal feelings do not matter in these. There is no real ‘right’ or ‘wrong’ here.
That said, i do believe that the RISC OS community as a whole would benefit from a fully open-source emulator that also supports JIT on ARM64.

I hope I haven’t stepped on too many toes here.