No more big 32-bit cores for RISC OS from 2022

The countdown clock for our beloved 32-bit RISC OS has begun.

ARM has announced that “Starting with Arm’s 2022 IP, all future Cortex-A “big” cores will only support 64-bit”. i.e no more 32-bit cores for RISC OS to run on.

There is no mention of what will happen to the smaller, less powerful class of cores such as the Cortex-A53, so these may still be around for a bit longer.

So rough timings might be:
2021: ARM announce their last big 32-bit ARM core, which will be available to their licensees
2022: Last 32-bit ARM cpus come to consumer market in devices by Qualcomm, Broadcom etc.
2023: Fastest cpu for RISC OS will be between the Cortex-A72 cores (currently used by the Raspberry Pi4) and the successor to the current Cortex-A78.

We all knew this day would come, but the date is quite close. I realise that RISC OS probably has a few years after the 2022 cut-off before there are no more platforms available to us, but the clock is now ticking.

https://www.theregister.com/2020/10/08/arm_32bit_support/

Rather inevitable really, everything else that is commonly used is compiled, so can be built for 32 or 64 bit as required, and since pretty much everybody has gone to 64 bit, keeping the 32 bit around makes about as much sense these days as keeping 26 bit around did back when Acorn met its demise.

but the clock is now ticking.

It always has been. The question is, what’s the way forward?

…raise a 64-bit bounty & find people who can and want to do the job ;-)

The question is, what’s the way forward?

There will be more knowledgable heads on this but at a guess the options are:

1. Convert every element of the OS source to C and compile for a 64 bit platform using a compiler capable of outputting 64 bit code. Convert all applications with any 32bit code in the same fashion. All new applications need to be similarly compiled.
2. Create a 64bit emulator for a generic 32 bit platform and run the OS and applications in that emulator.

I did consider adding “give up on the future proofing and hoard some old boards to use, forever” but that doesn’t match the “way forward” element of your question.

Convert every element of the OS source to C and compile for a 64 bit platform using a compiler capable of outputting 64 bit code

That’s the one that seems logical to me. This is a good moment to thank Julie Stamp for having made a start on the process.

Note that the source includes the HAL. I’ve recently spent some time working on a small part of it, and it reminds me how much I wish it had been in C already.

That’s the one that seems logical to me.

Forcing a move to a native 64 bit is “interesting” – when I said

Convert all applications with any 32bit code in the same fashion.

… I could see all the devotees of things like Impression-X having screaming fits.

This is a good moment to thank Julie Stamp for having made a start on the process.

Indeed. It’s a long task and probably little thanks.

Note that the source includes the HAL.

Given its origin (much involvement in the RO-wars) I’m surprised it isn’t totally in C, but it seems C is only 8.5% (Kb of source) what that comes down to in terms of final code will surely differ.

Create a 64bit emulator for a generic 32 bit platform and run the OS and applications in that emulator.

This, I feel, is likely what will happen in reality.

Convert every element of the OS source to C and compile for a 64 bit platform

This may or may not be a good thing.

For sure – we need to be in something that is not raw assembler for continued viability (like in 2026 when the ARM API changes in some weird way and Linux just shrugs it off as a three-line patch).

However, given that apart from BASIC programs, absolutely NOTHING from the past will run on a 64 bit system, perhaps it might be time to look at the behaviour of the OS as a whole, with a view to fixing some of the rubbishy bits once and for all. Concepts such as modules running with the same access level as the kernel should be killed with extreme prejudice. All OS workspace should be completely inaccessible to the user mode apps, and things that need to access kernel level stuff should have an API where the data is copied to a temporary buffer that is user mode readable.
As much as it might be nice having OS_EnterOS to get full privs, a future incarnation of RISC OS ought to have the ability to refuse to permit this.

No longer pass SWI by embedded number (it may be that ARM64 doesn’t do that anyway – I haven’t looked).

Along with this, look at having a mixed co-operative/pre-emptive Wimp. With a kernel that is aware of the fact that different processes exist.

So it’ll be “RISC OS like” but in a way a little more 21st century and a little less 1987.

O’course, the eternal question – who is going to write such a thing?

I could see all the devotees of things like Impression-X having screaming fits.

This is why I see some sort of emulation being the most likely outcome – because otherwise huge swathes of software would simply vanish.

Take a look in !Store and PackMan. That’s your lot, as stuff still available could be updated (depending on how much the API changes and how difficult that makes it). Impression? Artworks? Both assembler, aren’t they? PhotoDesk has a lot of assembler. That’s not to say it’s impossible, just quite unlikely.

with a view to fixing some of the rubbishy bits once and for all.

Keyboard handler and allied items.

Wimp Poll, Key_Pressed
+24 Character Code (4 bytes)

Highest character code? &1FF

This is why I see some sort of emulation being the most likely outcome – because otherwise huge swathes of software would simply vanish.

Hence my comment about Impression X. Is that even fully 32bit yet? I don’t mean “mostly but it works with a bit of help from Aemulor”, no, really 32bit.

Convert every element of the OS source to C and compile for a 64 bit platform

Would it be feasible to write a tool to decompile most of the assembler automatically (to C or some other intermediate representation)? Or does one already exist? I guess there’d be a few bits like self-modifying code that would need manual intervention.

Create a 64bit emulator for a generic 32 bit platform and run the OS and applications in that emulator.

I think the ideal solution would be a sort of combination of the two: converting as much of the OS as possible to run as native 64 bit code but including an emulation layer for any applications (or bits of the OS) that haven’t been ported. I’m not sure if this is more work than option 1 or if it saves time. It could even include 26 bit emulation.

I also wonder if Jon Abbott’s JIT compiler would be useful here if it could be persuaded to output 64 bit code.

Keyboard handler and allied items.

Argh! I wasn’t going to go near that nest of horrors.

I wonder how many other RISC OS users are like me, in not really caring about 99% of the old software? For me, if I could have !Draw, !Zap, BBC BASIC & the WIMP desktop, I wouldn’t miss anything else.

Apart from a certain amount of nostalgia, “give up on the future proofing and hoard some old boards to use, forever” may well be the way I’ll go. Sadly.

I might – or might not – get myself a Pi4. I wonder how long my Pi3 will last…such things don’t last forever.

But then neither will I. Our son, who cut his teeth (metaphorically!) on a Psion 5, moved on years ago.

Actually, even the loss of !Zap wouldn’t upset me too much, as long as I still had BBC BASIC and the WIMP desktop: I don’t use much of its (amazing) functionality, and what little I do use of it I could replicate in an app of my own, written in BASIC, fairly easily.

I guess there’d be a few bits like self-modifying code

Does self-modifying stuff work properly on the modern machines?

Of keyboard handler:

Argh! I wasn’t going to go near that nest of horrors.

:)
In recent times I’ve poked about in Filer, Wimp and Switcher. Some of the things I’ve tried to do drag me into the keyboard/character handling.

Worse though, in some respects, is the constant shifting with the regard to use of particular registers for a particular purpose. Different developers for different modules clearly choosing register numbers by throwing darts at a set of playing cards blindfold or something.

Actually, even the loss of !Zap wouldn’t upset me too much,

That would be cataclysmic.

If I had a clue about how text editors worked, I’d think of writing something that “behaves like a simple Zap” in C.
It’s not Zap so much as the fact that everything else I’ve tried ¹ is utter $#¡+ in comparison. Even Notepad++ isn’t as flexible as Zap. The ability to switch from text to dissembly to hex words or bytes is really useful. And the code colourisation is well thought out. I’ve encountered some real horror shows in that respect.

¹ With the exception of StrongEd, that can do most (if not all) of what Zap does, only differently. I’m not taken with its visual appearance though…

is the constant shifting with the regard to use of particular registers for a particular purpose.

I wonder how much of that is due to botching the keyboard interface into a BBC-like OSBYTE clone, and then bolting on stuff without addressing the fundamental issues with the keyboard subsystem?

by throwing darts at a set of playing cards blindfold or something.

He who is in possession of the pink dinosaur gets to pick the registers, and everybody else can STFU until it’s their turn. ;-)

I guess there’d be a few bits like self-modifying code

Does self-modifying stuff work properly on the modern machines?

and hoard some old boards to use forever may well be the way ….

I have a cupboard full of old boards. Pi 1, 2, 3, 4?

I have a cupboard full of old boards. Pi 1, 2, 3, 4?

I had a cupboard full, not including a 4, until we moved. Now I only have one 3B, our son has the rest and may be playing with them, he said he might. He’ll do things with them I wouldn’t have; he’s not a RISC OS man, and is also more inclined than I am to bother with the GPIO side of things.

everything else I’ve tried is utter $#¡+ in comparison

Totally agree. Atom is what I use on the Mac, but Zap is one of the reasons I flip over to the Pi fairly often. I’d certainly miss it, but the features of it that I use – like you, switching to hex words or bytes, and code colourization* – are all things I wouldn’t find too difficult to replicate in a BASIC app. (In C? Impossible…for me at any rate.)

In an earlier version of Zap that I used to run on A5000s and RiscPCs but which no longer works on the Pi, I had managed to make my own variation that displayed all the normally non-printing bytes as single characters, colour coded, which gives you the same information as the byte display, but a little easier to read and a lot denser on screen. I’ve not (yet) bothered to replicate that in BASIC…harder would be the equally handy keyboard driver that enabled me to touch type any of the 256 bytes using one character key possibly combined with one or more modifier keys…

* Although I’d only bother with HTML & BASIC colourization, and I’ve already got the HTML colourization in Atom…

Presumably applications written in BASIC would just work on the 64bit OS (once RISC OS works on a 64bit processor). Perhaps it would be better to rewite the simpler apps in BASIC rather than c to future proof them.

Aemulor will need to exist for some time for Impression so will have to cope with 64 bit – we should have a bounty for updating Aemulor to run in 64 bit.

Perhaps it would be better to rewite the simpler apps in BASIC rather than c to future proof them.

Isn’t that increasing the workload?
A “simple” recompile of the existing source with a 64bit capable compiler vs. conversion, dealing with missing features in BASIC, and then testing an effectively new item.

There’s probably already a cross-platform compiler that can do the C recompile today¹. There is no trace of a RISC OS BBC BASIC interpreter for 64 bit hardware – for obvious reasons.

I think the change will probably be option 1 and 2 in bits.

As for Aemulor, it’s a stop-gap. A crutch for 26bit reliant items that’s extended the usable life of some things for nearly 20 years. Time to move on or emulate a 26 bit environment in something like RPCEmu for items of historical curiosity.
Even Rick is contemplating abandoning Zap.²

¹ Guessing, but quite likely.

Even Rick is contemplating abandoning Zap.

Which part of “That would be cataclysmic” implies abandonment?

The hard cold harsh reality is that stuff written in assembler for a 26/32 bit OS will not work in a 64 bit world.
Don’t think of it as ARM, think of it as porting it to something like MIPS, because if you remove the PSR/R14 things and various quirks like alignment issues, the 26 bit world and the 32 bit world have many similarities. That I could write something on my Pi that also runs on an ARM2 with Arthur ought to be testament enough.
The 64 bit world? Completely different thing. Twice as many registers, for a start. And while I’ve not looked in detail, I believe conditional execution is no longer a thing. Probably too much a pain in the ass to do speculatively?

So, as much as I like Zap and as much as I want to keep on using it, if RISC OS makes a transition to 64 bit, Zap will be a casualty. Another one lost to the changes of the ARM. So it’s worth thinking ahead to potential alternatives. To ask “what is it that makes Zap…Zap?”.

then Fred would find himself with a partner in the StrongED modifications

Unlikely – isn’t StrongEd also written in assembler?
Same story, different name…

Perhaps it would be better to rewite the simpler apps in BASIC

Simple indeed. Things that don’t need speed (won’t be crunching numbers), don’t need anything resembling semi intelligent memory handling (unless you’re happy to manage it all yourself), and don’t need to mess too much with data structures (because native BASIC is a bit icky there).

rather than c to future proof them.

Easy way to obliterate that argument is to point you at any Linux kernel. As long as a compiler exists, stuff written in C can be compiled. Some careful coding and not making dumb assumptions (like the size of int or structure packing) and you ought to have something that will happily build for whatever architecture is under discussion as soon as there’s a compiler for it.
Linux for ARM, x86, MIPS, 68K, etc etc – you don’t think those are ports do you? There are some really low level bits written in assembler (necessity) that are system specific. The rest of the way up, it’s the same thing.

Consider also OvationPro. Not only 32 bit native, there’s also an x86 version. ;-)

The hard cold harsh reality is that stuff written in assembler for a 26/32 bit OS will not work in a 64 bit world.

Maybe, if the source is available, a machine translation could do 99% of the work. After all, the 64bit ARM should be a lot faster, so for legacy software you don’t have to worry too much if you lose some performance on the way, so you can do the translation very “conservative”.

In “binary only world”, it is a lot more difficult. Besides full emulation – no idea.

Anyway, with the current state of RISC OS, you’d first need to get an idea what will have to change to make RISC OS happy on 64bit ARM. Then, you’d need an automatic translation approach for the ASM stuff – rewriting everything in C is a nice idea, but I fear the lack of competent developers will make this unlikely to happen. The problem with the “auto translation” approach is that you need experts on both 32bit ARM and 64bit ARM, with a good understanding of RISC OS thrown in. A big task.

It looks a bit like the 1998 “end of Phoebe” situation – no HAL, no 32bit-clean OS, so it looked a lot like “it will be Emulation from now on”.

One of the reasons I keep pushing Lua is that is available on any platform with an ANSI C compiler. My experience with Linux is rudimentary, but I would be surprised if there were any Linux distributions that did not already incorporate at least one version of Lua 5.x (0 < x < 5) as a standard component.

The third option is to continue using Virtual Risc PC.