64bit Risc OS.

Any chance that RISC OS will ever go 64 bit for use on the RPi4+?

@ Joe

Welcome to the forum!

Any chance that RISC OS will ever go 64 bit for use on the RPi4+?

There are people working on this and the challenges that it will bring, you can read about it in more details here:

https://www.riscosopen.org/wiki/documentation/show/Addressing%20the%20end-of-life%20of%20AArch32

In general, RISC OS is an OS that was written around the ARM 2 / ARM 3 Architecture and in full on assembly language (although if over the years some components have been either added in C or being rewritten in C).

This means that RISC OS did not have the “first wave of OS evolution” (that we observed between the end of the 80s beginning of the 90s), which was rewriting them in C in order to simplify the porting between the various CPU Architectures new generations and even between entirely different CPU Architectures (in some cases).

AArch64 presents some key difference with AArch32, which will be challenging for RISC OS to overcome, and so it will take a bit of time to see a new RISC OS 64bit. However, make no mistake, “IF” and “WHEN” a RISC OS 64bit will be available, it won’t be able to run old RISC OS 26 and 32bit software without using an emulator, or if such software has not been expressly ported (and modified) to run on RISC OS 64bit.

This may also include some software written for interpreted languages like BBC BASIC (which can use “data pointers” for example, that at the moment are 32bit and on a BBC BASIC 64bit they will be 64bit for obvious reasons) etc.

So, it will be a big change regardless if it’s made just as a mere “translation” or if it’s done as a full OS redesign.

Step 1: C Kernel and multi-processing
Step 2: recompiling for 64-bit, and rewriting everything or using an emulator (or 32-bit modes)

Shouldn’t take more than a couple of weeks :)

No

However, make no mistake, “IF” and “WHEN” a RISC OS 64bit will be available, it won’t be able to run old RISC OS 26 and 32bit software without using an emulator

I believe that even Armv9 still allows 32-bit user mode code (although it remains to be seen whether a 64-bit RISC OS would make use of this facility). Modules would need to be 64-bitted though.

I wish I understood enough assembly to be able to help. I’ve tried to work through some simpler modules with the hope of C-ifying them, but no luck :(

Edit: Something I forgot about: 32-bit user mode is optional in Armv9, so you’d need a chip that actually supports it. They may be few and far-between.

I believe that even Armv9 still allows 32-bit user mode code (although it remains to be seen whether a 64-bit RISC OS would make use of this facility). Modules would need to be 64-bitted though.

How does the Linux port run in user mode? Could there be a short cut to getting RISC OS to run natively on newer processors via a similar method?

Linux is not comparable, there are no shortcuts.

Linux is not comparable, there are no shortcuts.

I’m sure I’m exposing my lack of technical knowledge here, but if 32 bit RISC OS can run in user mode on the likes of the Cortex A76 under linux then why can’t a boot loader be constructed to allow it to run natively?

Linux is not comparable, there are no shortcuts.

This, exactly this.

I’m sure I’m exposing my lack of technical knowledge here, but if 32 bit RISC OS can run in user mode on the likes of the Cortex A76 under linux then why can’t a boot loader be constructed to allow it to run natively?

Dear Andrew, beside of the fact that is such a case we would be running Linux as an OS and RISC OS as an App, that would also still require an ARM capable of running AArch32 in user mode. Now, I understand some people may want to hold on this hope, however Aarch32 is fully optional on ARMv9, so no warranty there is going to be an ARM that will be able to do that.

I wish I understood enough assembly to be able to help. I’ve tried to work through some simpler modules with the hope of C-ifying them, but no luck :(

There are ways around the 64bit situation. One is to use binary translation (I think I have mentioned this in the past). However, when it comes down to binary translate an OS and on the fly (JIT), then the binary translator needs support from something. That something has to be an Hypervisor. Otherwise, the only solution is Emulation.

I have started to experiment with this and got to a point where I have a ~2MB executable Hypervisor code that boots off uboot and runs a Linux Virtual Machine on AArch64. It works on Rpi only at the moment.

I am now working to add the RPi emulation layer to it (literally last Monday night it built and linked for the very first time with some ported code from the Linux Kernel I needed to complete the RPi board emulation layer), so that Linux could boot and use graphics etc.

When this stage is completed, I’ll try to boot a RISC OS Virtual Machine on it.

When I have completed this stage, I’ll start adding MAMBO (an Aarch32 to Aarch64 jit binary translator) to the hypervisor, so that the hypervisor could JIT an AArch32 VM to AArch64 code and execute it live.

I do not hide that all of the above is crazy experimental, so absolutely no promises and no warranty it will ever work. So, again at this very moment, the only real answer is what Stewart mentioned: “No”

Another possible way is to keep translating RISC OS components from Assembly to C, but again, this doesn’t give any warranty either of successfully being able to build RISC OS on AArch64 without (at least some) substantial changes.

So, once again, there are no short cuts, no tricks, no funky solutions. It’s either going to be a lot of work whatever is the desired approach one wants to try (and with no warrantee of success) OR Emulation all the way.

When I have completed this stage, I’ll start adding MAMBO (an Aarch32 to Aarch64 jit binary translator) to the hypervisor, so that the hypervisor could JIT an AArch32 VM to AArch64 code and execute it live.

This sounds really interesting. Would your hypervisor be capable of running RISC OS without JIT on hardware that supports AArch32 in user mode? If so, that’s pretty much what I was trying to suggest. If it works then I think you’d have provided a solution that’ll keep RISC OS going until it can be 64 bitted properly.

This sounds really interesting.

Thanks, appreciate it, although if it’s at a too early stage to say, but I hope it will become interesting for RISC OS yes.

Would your hypervisor be capable of running RISC OS without JIT on hardware that supports AArch32 in user mode?

No, this is not the goal I am trying to achieve at the moment, nor I am interested in pursuing something that probably will work on 1 CPU if at all on any.

My goal is to initially target AArch32 and run RISC OS as it would on a regular RPi. Just using and being confined to the resources the Hypervisor will assign to it. I am also trying to have intercommunication with the Hypervisor via shared memory and messages.

I have some research paper that shows how MAMBO could be used in conjunction with an hypervisor to enable jitting of an OS from AArch32 to AArch64, it’s a complex approach (way out of my league right now, but I’ll try it anyway once I’ll have a RISC OS VM working on the AArch32 target).

At this very moment, I can only boot Linux based VMs and they are specifically built for the hypervisor, so I am not close to be able to boot RISC OS on it yet, but the ARM Hypervisor extensions appear to be working and being in used. So, I can assign whatever resources I want to the Linux VM (for example 2 cores and 2 GB RAM and use an image based disk) and it stays confined in them.

Next I am trying to add support for frame-buffering etc. to have a graphic desktop on it.

The reason I started to work on an hypervisor is because of the ROOL speech at the ROUGOL show in 2019, where Steve Revill clearly stated that they are focusing on running RISC OS on its own, and that is exactly what the hypervisor will do. It doesn’t use Linux (or requires Linux) in dom 0 as Xen and KVM pretty much do.

So, when RISC OS will boot on the hypervisor it will be just RISC OS and run as it always did. I also want to achieve an hypervisor that will require no changes on both RISC OS, Linux, BSD, Windows 11 to run on it and I want to have the management API controlled from RISC OS (so, in the future, instead of having to preconfigure the Hypervisor to boot Linux or RISC OS, a user will have a WIMP app to just set resources and spin up an new VM, but I am so far away from that right now).

Right now, I’d be happy if Vanilla RISC OS would boot on it to the Desktop, maybe in the coming months it will become a reality.

When I have completed this stage, I’ll start adding MAMBO (an Aarch32 to Aarch64 jit binary translator) to the hypervisor, so that the hypervisor could JIT an AArch32 VM to AArch64 code and execute it live.

Interesting. If I understand correctly, you’ve implemented an EL2 Hypervisor?

Would your hypervisor be capable of running RISC OS without JIT on hardware that supports AArch32 in user mode?

To run RO in USER mode would require CPU Paravirtualization, so a JIT would be required.

Err – what is a Hypervisor?

Edit: Something I forgot about: 32-bit user mode is optional in Armv9, so you?d need a chip that actually supports it. They may be few and far-between.

The Snapdragon 8 Gen 1 contains 3x armv9 Cortex-A710 @2.5GHz that has EL0 aarch32.

Err – what is a Hypervisor?

GIYF.

https://en.wikipedia.org/wiki/Hypervisor

@ Jon

Interesting. If I understand correctly, you’ve implemented an EL2 Hypervisor?

I would say more like: I am (desperately) trying to implement an EL2 Hypervisor, YES.

In more details for who might be interested, it’s a Type 1 (bare-metal), EL2 Monolithic hypervisor, so that it can be used to build a RISC OS distribution without using any other operating system below RISC OS.

For everyone else interested:

If it will ever work, it will bring quite a lot of advantages to RISC OS, I think I have listed quite a few of them in another post.

It may also be used to help transitioning to 64bit in the sense that it could buy time to ROD/ROOL to develop an actual 64 bit RISC OS (if they can and want to do that), by being combined with an AArch32 to AArch64 binary translator.

An Hypervisor is not an emulator in the traditional sense, RISC OS will be executed on the ARM CPU (not a software emulated CPU like it happens in RPCEmu for example), however the rest of the “computer hardware” is generally emulated, for instance the RPi GPIO will be emulated.

So, an OS is going to be faster than running in an Emulator, but not as fast as if it would be executed on the bare-metal hardware. However, in the case of RISC OS it may be as fast as when executed on the bare-metal, this mostly because (at the moment) RISC OS is not using much of the HW acceleration features offered by the hardware, so, most likely it will run as fast as it does on the bare-metal RPi (we’ll see).

You want to watch out for the fact that some instructions used to return to USR mode are also valid when running in USR mode, in other words they don’t get trapped (easily). TEQP, maybe, it’s been a long time since I abandonned my attempt.

You want to watch out for the fact that some instructions used to return to USR mode are also valid when running in USR mode, in other words they don’t get trapped (easily).

Thanks, yup I have noticed it’s a bit of a pain… anyway, I am doing it for fun, let’s see till where I can go. If I get too stuck, I’ll just upload all my work if someone feels brave enough to help.

it’s a Type 1 (bare-metal), EL2 Monolithic hypervisor,

Bare metal? Are you not using mailboxes to communicate with the chipset?

some instructions used to return to USR mode are also valid when running in USR mode

This would only be an issue for CPU paravirtualization, which would only be required for VM’s with CPU’s that aren’t native cores. Most CPU still support 32bit cores, so this could be avoided in the short-term.

It’s something I was planning to implement in ADFFS 3.0, but am watching progress on this project as my long-term goal was to implement a type 2 Hypervisor. A type 1 has various advantages as it removes the need to paravirtualize the OS – which ADFFS currently does and would greatly simplify emulating an IOC or IOMD chipset within a VM on ARMv7.

Bare metal?

Bare-metal = the hypervisor runs on its own, no need for an underlining OS.

Are you not using mailboxes to communicate with the chipset?

yes, I am using mailboxes.

But, again, I am in the absolutely early days of it.

Jon & Paolo this looks like the perfect time to get to together and work it all out

Jon & Paolo this looks like the perfect time to get to together and work it all out

Rob, sure. I was planning to upload my work on GitHub anyway, for whoever is interested in helping me. I just need to work out a couple of issues and then push it all on GitHub.

Would you be interested in what I was working on last year? It’s Aarch64, compiled with gcc, and boots a RaspPi3 to loading a RISC OS ROM image into memory from SD card and runs it in Non-Secure arm32, emulating the hardware in Aarch64 code. It’s a bit weird, a different approach to an OS, but there’s probably something in there that’s worth using.

https://github.com/Simon-Willcocks/IsambardOS/blob/main/README.md

Would you be interested in what I was working on last year?

Thanks and yes, I am interested in reusing every piece of code I can to lower my work-load, right now the list of things to do for me has reached “total madness levels” in terms of code and components (to build both below and about RISC OS).

Th eDesktop lacks so many features that it’s a miracle someone is still using it in 2022… (sorry for the rant), but guys there were plenty of things that could have been done (over so many years) without modifying the main OS… anyway, my list of TODOs it’s crazy long, but I am slowly getting through it.

Thanks again to whoever is willing to help with whatever, info, corrections, suggestions, code snippets, even semi-built tools! :)

The idea behind it is to run as much as possible at EL0/USR level, allowing access to hardware through virtual addresses. I’d like to shift RISC OS over to that, too, so that future cores that only support arm32 in USR mode can still be used.

To try it in QEMU, you need modifications…

Maybe we can convince the qemu team to allow files to be pre-loaded in processor “RAM”.

I tried to make it as modular as possible, so the boot sequence can be stopped at almost any point before the whole threads/maps vs. processes/threads discussion. I’m rather proud of the partner threads approach, though.