RISC OS Open plots great escape from 32-bit purgatory
- Reference: 1743501674
- News link: https://www.theregister.co.uk/2025/04/01/risc_os_open_moonshots/
- Source link:
On Friday, RISC OS Open Limited (ROOL), the organization maintaining the FOSS version of the original Acorn RISC Machine OS, [1]announced its Moonshots initiative. ROOL is looking for money, developers, and community support to fund porting RISC OS to Arm64 – because the 64-bit instruction set is the only one that most modern Arm cores support, from the kernel level up, at least.
ROOL boss Steve Revill – whom we [2]interviewed in 2023 – also published an [3]open letter [PDF] explaining what ROOL needs to do and estimates how much work it will take. ROOL also has a [4]roadmap of the modernizations it feels RISC OS needs. The [5]Moonshots initiative is an ambitious extension of the existing [6]bounties program , which allows the community to sponsor specific features they want in RISC OS.
[7]
It's already getting some sponsors, Revill told The Register :
Since we launched the Moonshots, I've already started hearing from people in industry that have automation tools for assembly → C translation, which is a research area which has come on a long way since I last looked at it. I've not really had time to digest but perhaps that will be a way to significantly reduce the size of this particular big ticket – maybe to just a moderately big ticket!
RISC OS is the original native operating system for Arm processors and a true survivor. As The Register described for the [8]25th anniversary of the Acorn Archimedes way back in 2012, the OS evolved from a version called Arthur, which itself was born from the OS used in Acorn's 6502-based microcomputers, when it shipped with Acorn Computers' first Arm-powered Archimedes machines. The first official public release, Arthur version 1.2, was in September 1987. For context, that's before Windows 2.0 or OS/2 1.0, both of which appeared in December 1987. The Reg FOSS desk [9]talked to project lead Paul Fellows in 2022.
[10]
The 1987 Arthur UI – click to enlarge
RISC OS was the slightly more professional name given when version 2.0 shipped in April 1989 – six months before OS/2 1.2 and indeed NeXTstep 1.0, or macOS as Apple calls it these days. Apple now calls the latest version of NeXTstep macOS, and OS/2 1.2 was the version that introduced the 3D-shaded buttons that Windows 3.0 made famous when it [11]first appeared over a year later.
It's interesting to us the difference between the Arm world RISC OS lives in, and that of x86, in terms of CPU backwards compatibility.
[12]
[13]
In the land of x86, all 64-bit chips – variously called AMD64, x64, x86-64, or simply x86 for old time's sake – also support x86-32, and indeed 16-bit code all the way back to its 8086 chip from 1978. In 2023, [14]Intel proposed a simplified specification, x86S, which would drop 16 and 32-bit support. The next year it [15]formed an x86 ISA advisory group, but the x86S idea did not go down well and was [16]cancelled in December. It's part and parcel with the x86 world's ethos of backwards compatibility.
[17]Got an old Raspberry Pi spare? Try RISC OS. It is, literally, something else
[18]RISC OS: 35-year-old original Arm operating system is alive and well
[19]What will you do with your Raspberry Pi 4 this week? RISC it for a biscuit perhaps?
[20]RISC OS runs on fastest hardware ever
With Arm, it's a lot less bloat, if that's what you want. Chip designers can pick off-the-shelf Arm CPU core designs to license for their processors, or indeed design their own Arm-compatible cores using a top-tier architecture license. To keep costs down, hardware makers only license the parts they want. If they don't need to run old 32-bit code, they may reduce costs by omitting the Arm32 instruction set, if the selected core or architectural license allows.
On top of that, for general-purpose application processors, the kind you'd want to put in a server or PC, Arm has been going further and further down the path of providing 64-bit-only cores, [21]starting with kernel mode , and [22]then user mode .
The result is that while Intel lost the battle to remove its old instruction sets, most modern Arm-based processors and system-on-a-chip families include either limited Arm32 support, or none. For example, the Arm Cortex-A76 [23]CPU cores in the [24]Raspberry Pi 5 can run Arm32 applications, but they can't boot a native 32-bit Arm OS. The cores only support 64-bit code at the kernel level.
[25]
RISC OS 5.30 – click to enlarge
Thus if RISC OS is to live on, running native on future Arm hardware, it needs to be 64-bit sooner than later. Right now, it's 32-bit.
Even getting to that point was a bit of a Herculean effort, so the OS has been through a degree of processor migration at least once. When Acorn left the scene, and the RISC OS community got the rights to continue working on the desktop OS, relaunched in the form of RISC OS 4, the operating system – still written pretty much in hand-coded assembly – used Arm's original 26-bit addressing from the 1980s. 32-bit registers, 26-bit memory addresses. The upper six bits of the program counter held the CPU flags.
[26]
Back in the early Arm days, 26-bit addressing gave the OS access to up to 64MB of physical RAM at any one time, which seemed more than enough. By the arrival of the ARM6 CPU at the turn of the 1990s, the architecture supported full 32-bit, and later 26-bit addressing was dumped. (Gray-haired users of early 680x0 Macs may dimly remember when Apple faced a [27]broadly comparable issue .)
Acorn clung onto 26-bit, even though 32-bit Arm cores were available through the 1990s and beyond, partly at least because going to 32-bit would break application compatibility. If there was one thing the Acorn ecosystem needed, it was as many apps as it could keep hold of, arguably.
RISC OS version 5, a fork produced by Castle Technology in the early 2000s, bit the bullet and went fully 32-bit so that it could run on the 32-bit-only processor in Castle's [28]Iyonix computer , which ironically enough was powered by an Intel Xscale that was Arm-based for [29]reasons that if we went into would make this long-ish article officially long. (Let alone getting into the RISCOS Ltd RISC OS 4 vs Castle Technology RISC OS 5 fight that was eventually [30]settled .)
[31]
That 32-bit change-over with version 5 was relatively modest, rather than a complete rewrite. It needed some [32]new 32-bit build tools , and as we said, the new 32-bit RISC OS could not run 26-bit-based binaries – although the [33]Aemulor compatibility layer fixed that.
The shift to 64-bit is much, much more challenging, as the [34]RISC OS wiki explains . With the change from 26-bit to 32-bit addressing, the instruction set remained pretty much the same. Moving from 26- to 32-bit addresses involved ensuring flags were't stored or assumed in the upper bits of pointers, for instance.
But with 32- to 64-bit, the instruction set changes completely. 64-bit Arm is a fresh start, with a 64-bit MIPS-like RISC approach. 32-bit Arm is ... 32-bit Arm. It's 32-bit RISC with little quirks from the geniuses at Acorn, such as the multiple load and store instructions. That means the OS, all of that hand-coded assembly, has to be rewritten in 64-bit Arm code. As the [35]sponsorship page says, the current plan is to redo the heart of RISC OS "from hand-crafted Arm assembly language to high-level language (eg, portable ANSI C)."
It's a big goal. Revill's open letter says:
Our team at ROOL has estimated that this will require a dedicated group of developers working full-time over several years.
RISC OS remains unique. It's a modernized, updated version of a proprietary 1980s OS. It can run – and run well – on any Raspberry Pi from the first model up to the Pi 4 and Pi 400. However, there is no Raspberry Pi 5 version and, according to ROOL, there won't be unless this Moonshot succeeds. It's tiny, fast, and simple, and in the humble opinion of this vulture, it has the most elegant desktop GUI ever created other than classic MacOS. However, it does have profound limitations, such as [36]not-quite-comprehensive memory protection – for lingering historical compatibility reasons, once again – and no support for modern multi-core processors.
We would love to see this moonshot succeed. It's a taste of how small and unbloated the best 20th century OSes were. There's nothing else quite like it in the world today. ®
Boot-up-note
Speaking of RISC OS, it's worth mentioning [37]Pyromaniac , a very cool project to implement RISC OS from scratch in Python, with Arm emulation built-in to run RISC OS executables on non-Arm systems. The code is not publicly available, but can be tried out at the command-line level [38]in the cloud, here . It's designed to run on Linux, macOS, and Windows.
Pyromaniac provides 64-bit and 32-bit RISC OS environments, including [39]a desktop . It was developed by [40]Gerph , who among many other things, worked for RISCOS Ltd back in the day, which produced in the late 1990s to the 2000s the RISC OS 4, Select, and 6 family of the original operating system [41]from the ashes of Acorn.
The Pyromaniac software also powers an [42]online RISC OS build server .
Get our [43]Tech Resources
[1] https://www.riscosopen.org/news/articles/2025/03/28/moonshots-initiative-to-secure-the-future-of-the-os
[2] https://www.theregister.com/2023/01/17/retro_tech_week_rool/
[3] https://www.riscosopen.org/others/2025-03-28-OpenLetter.pdf
[4] https://www.riscosopen.org/wiki/documentation/show/RISC%20OS%20Roadmap
[5] https://www.riscosopen.org/content/documents/risc-os-moonshots
[6] https://www.riscosopen.org/bounty/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z-wNny3w13fGpm55lPiPCQAAAY4&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[8] https://www.theregister.com/Print/2012/06/01/acorn_archimedes_is_25_years_old/
[9] https://www.theregister.com/2022/06/23/how_risc_os_happened/
[10] https://regmedia.co.uk/2012/05/16/arch_1.png
[11] https://www.theregister.com/2013/05/23/microsoft_windows3_birthday/
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z-wNny3w13fGpm55lPiPCQAAAY4&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z-wNny3w13fGpm55lPiPCQAAAY4&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[14] https://www.theregister.com/2023/05/25/intel_proposes_dropping_16_bit_mode/
[15] https://www.theregister.com/2024/10/15/intel_amd_x86_future/
[16] https://www.tomshardware.com/pc-components/cpus/intel-terminates-x86s-initiative-unilateral-quest-to-de-bloat-x86-instruction-set-comes-to-an-end
[17] https://www.theregister.com/2024/05/02/rool_530_is_here/
[18] https://www.theregister.com/2022/06/21/risc_os_35/
[19] https://www.theregister.com/2020/10/27/risc_os_5_28/
[20] https://www.theregister.com/2010/06/25/riscos_beagleboard/
[21] https://www.theregister.com/2018/05/31/arm_cortex_a76/
[22] https://www.theregister.com/2020/10/08/arm_32bit_support/
[23] https://www.raspberrypi.com/documentation/computers/processors.html#bcm2712
[24] https://www.theregister.com/2023/09/28/raspberry_pi_5_revealed/
[25] https://regmedia.co.uk/2024/05/01/ro530-desktop.jpg
[26] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z-wNny3w13fGpm55lPiPCQAAAY4&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[27] https://lowendmac.com/2015/32-bit-addressing-on-older-macs/
[28] https://chrisacorns.computinghistory.org.uk/AfterAcorn/Castle_Iyonix.html
[29] https://www.theregister.com/2006/06/27/intel_sells_xscale/
[30] https://www.theregister.com/2004/07/19/risc_os_agreement/
[31] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z-wNny3w13fGpm55lPiPCQAAAY4&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[32] http://www.riscos.com/news/news_items/PR220201.htm
[33] https://sendiri.co.uk/aemulor/
[34] https://www.riscosopen.org/wiki/documentation/show/Addressing%20the%20end-of-life%20of%20AArch32
[35] https://www.riscosopen.org/bounty/polls/45
[36] https://gerph.org/riscos/ramble/memory-regions.html
[37] https://pyromaniac.riscos.online/
[38] https://shell.riscos.online/static/term64.html
[39] https://presentation.riscos.online/pyromaniac3/index.html
[40] https://gerph.org/
[41] https://www.theregister.com/1999/03/06/riscos_to_continue_os/
[42] https://build.riscos.online/
[43] https://whitepapers.theregister.com/
"from hand-crafted Arm assembly language to high-level language (eg, portable ANSI C)."
Why not be up-to-date and use Rust?
There's quite a few people in RISC OS land that are a bit twitchy about C because it's new and fangled. :-)
My personal view is that as RISC OS is so lightweight it should be used as a process environment under somethinge else, using VM to run multiple instances of RO. You would then have a primary VM running the desktop (like a DOM0 Xen instance), and other background instances could just have enough modules loaded to provide a process environment and some kind of shim to the WIMP to re-route calls to the primary desktop.
This would keep compatibility whilst allowing a migration path.
But that requires more developers than are available in the RISC OS world I'm afraid.
> You would then have a primary VM running the desktop (like a DOM0 Xen instance)
You know what, that was my own suggestion in a Stardot thread a few years ago. Great minds think alike. ;-)
Please note the "I'll get my coat" icon before giving me a thumbs down.
These are Reg commentards. We are not rational human beings or we would have better things to do
> Why not be up-to-date and use Rust?
You know what, I did think that myself! :-)
Slight snag is that I would not be terribly surprised if the runtime support needed is bigger than the whole core of RISC OS... the LLVM compiler suite _definitely_ is.
32-bit registers, 26-bit memory addresses. The upper six bits of the program counter held the CPU flags
I remember an interview where answering one of the questions required realising that since all instructions were word aligned, the lower two bits could be (ab)used for storing state.
They're called [1]Tagged pointers. And they're relatively respectable these days, especially in languages with a GC.
I can tell you a lot more exciting hacks.
[1] https://en.wikipedia.org/wiki/Tagged_pointer
Thanks for that. The interview would have been early 2001. I hadn't done any work on ARM for more than ten years at that time. P.S. I got the job.
El Reg's description there isn't quite correct.
26-bit ARM uses the low two bits of the 32-bit program counter for current operating mode (user, supervisor, fast interrupt or regular interrupt) and it also uses the top six bits for status flags (from highest down: negative, zero, carry, overflow, interrupt disable, fast interrupt disable). So it has only 24 bits for the address part of the program counter but — as you note — instructions are always word aligned so that gives a 2^26 = 64mb space for program code.
As of the RISC PC, data can occupy the full 4gb of address space. It's just program code that is limited in size, and there's an MMU if you wanted to swap program code in and out of the safe range, albeit at the usual cost of program complexity.
If they could go for 64-bit ARM *without* touching the existing UI, I would be very happy. However I suspect they will try to modernize it all and ruin the whole point of the familiar cozy environment.
I don't think they have the luxury of so many developers sat around twiddling their fingers and they know what their users would and wouldn't like.
>Arm Holdings plc
>Total equity US$5.29 billion (2024)
Would be cool if they could find a measly million to through at this moonshot, surely it would at least partially count as a PR investment rather than just an expense?
Nobody left at ARM will have even heard of RISC OS
> Would be cool if they could find a measly million
Yes, that was the first company to cross my mind, as well.
Slight snag: I believe that some of the folks behind VirtualAcorn...
http://www.virtualacorn.co.uk/
The leading commercial RISC OS emulator for proprietary OSes -- like there are any others -- are, I believe, Arm employees.
And Virtual Acorn now owns the _other_ fork of RISC OS:
http://www.riscos.com/
The FOSS one is 32-bit, FOSS, and runs on 32-bit Arm chips.
The 3QD version is mainly 26-bit, is sold as an upgrade for Acorn hardware and compatibles, and it's been extensively refactored and has a HAL. And it's proprietary: the license was bought directly from Acorn.
ROOL came from Castle Technology, which continued making Acorn hardware after Acorn shut up shop... But the 32-bit version of RISC OS for Castle's all-new Iyonix PC came from Pace, which bought Acorn's set-top box and network-computer business.
The folks behind RISC OS Ltd didn't even know there _was_ another RO licensee. They thought they had an exclusive.
They were, I gather, *not happy* to discover there was another separate pre-existing RISC OS licensee.
I am told the two groups do not like each other much.
It was a small scene for a long time and there was plenty of time for deep-seated long-lasting rivalries and grudges and bad blood. :-(
Disclaimer: all AIUI from various 3rd party accounts. I was merely a spectator in the later stages.
ARM and x86 evolution was very different
The PC was, by design, a fairly open system. Because of that, loading an OS meant booting from a floppy (and later a harddisc), probing around for what hardware was available (unless you just used BIOS functions) and starting up.
ARM didn't develop like that at all - most early ARM devices were closed things that came with an OS (the Archimedes, Newton, GBA, Android phones...) and while it has been possible to install alternative OSs these have been extremely limited. Even today, with more choice and options, you don't get an Android, or RISC OS, image. You get one for this board (a Beagle) and a different one for that board (a Pi) and yet a different one for some other board. Because they all start up and behave (and have peripherals mapped) differently.
As such, there's no need to have much concern about backwards compatibility. If we ignore devices like the Pi, the majority of ARM things will be running whatever the manufacturer installed and that's that - phones, tablets, ereaders, etc etc etc.
All our current OS's should be x64 only, drop 16/32 support, remove the bloat and a lot of very dodgy patched code.
If Microsoft had nay sense, they would would support x32/x64 only with Windows 11 branch until end of life and target Windows 12 as x64, I bet we may even see a speed boost ?
There is still probably a lot of 32-bit code in use doing useful things which can't be rebuilt to 64-bit economically or at all, so keeping the capability to execute 32-bit code seems like a reasonable thing to do.
>There is still probably a lot of 32-bit code in use doing useful things which can't be rebuilt to 64-bit economically or at all,
Not in the real world of industrial process control and vital infrastructure.
Here we have 8bit and don't even know where the actual processor came from - never mind the source code
> All our current OS's should be x64 only
Um. You do know x64 is Intel, right?
Otherwise, though, this is more or less that Apple and MS have done...
For Acorn
For the Archimedes
For RISC OS
For ROOL