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

if the first new gen HW sets us back to RiscPC class HW

How could it be? All the Pi4 on the planet will not vanish!
The question is: will we have something stronger than the Pi4?

For now, we even not using 1/4 of the power of the Pi4.
So we still have a pretty good margin in term of evolution.

And a Raspberry Pi 4 Model B+ at 1.8 GHz (2.35 GHz overclock) is a big probability. For the Pi 5, we’ll see later, but I guess another ARM incarnation will be out before a switch to RISC V. I guess too that this incarnation could be 64bit only, and so will need RISC OS on Linux, or a bootstrap for vanilla RISC OS.

I bet on Cortex-A78. Cortex-X1 would be fantastic, but probably just a dream :)

The first generation of RPi (1-3) uses a 40nm fab to keep costs down.
The Rpi4 uses 28nm fab. So still cheap enough.

The next logical step could be cortex-a75. The only problem is 10nm fab
tends to be used for this. Looks like the jump in cost would be too great
to use 10nm fab.

The cortex-a75 is the last ‘a’ cpu which RISC OS could potentially run on.
Everything after this that has aarch32 only allows user mode so RISC OS won’t run without a lot of work.

> I will arange for a meeting with WDC

You intend for a re-match of off-the-shelf vs custom – like Iyonix vs Micro Digital Omega?

And I know that people are talking about destroying our OS instead of advancing it.

Who would that be? Please cite an example. Or is it just a case of “everyone with a different opinion than mine is wrong”?

prefer to see it advanced, which requires us to stay 32bit Classic ARM ISA.

This is your personal idea of “advanced”, I call it “dying”. RISC OS needs to get over its intimate intertwining with AArch32 sooner or later, or it will be a retro-only/emulation-only OS in the forseeable future (i.e. the same situation after Phoebe cancellation and before RISC OS 5, the HAL and the IYONIX). IMHO of course.

When the HAL was introduced, quite a few people also thought that that was an eternal mistake and only Acorn-bred subsystems and chips should ever be supported by RISC OS.

I look at the nonsense of hurry up and C the OS so we can go AARCH64, as just that nonsense.

The theory is that the people that don’t do development work are far more likely to know C than know ARM Assembler.

That allows all development to be easier to pickup than learning ARM.
The fact that a source set in C can be recompiled as AARCH64 is a bonus now and essential eventually.

So, why couldn’t ASM (with effort, of course) be made 64 bit compatible?

So, why couldn’t ASM (with effort, of course) be made 64 bit compatible?

The two Aarch32 and Aarch64 are wildly different to the extent that it would probably be as easy to port to x86 (i.e. not even vaguely easy)

The advantage of an OS that is rewritten in C (or other higher level language) is that you can switch from producing a 32 bit version to producing a 64 bit version rapidly

So, why couldn’t ASM (with effort, of course) be made 64 bit compatible?

It’s a bit like sending a spaceship to the nearest star. By the time it gets half way you’ve designed and sent another one that’s over taken it.

The two Aarch32 and Aarch64 are wildly different to the extent that it would probably be as easy to port to x86 (i.e. not even vaguely easy)

Shame. I am a C programmer originally (learned it on Risc PC way back when), but I admit it would be a little sad to see assembly (and assembly in BASIC) relegated to emulators and novelty projects in the future.

The advantage of an OS that is rewritten in C (or other higher level language) is that you can switch from producing a 32 bit version to producing a 64 bit version rapidly

Can’t argue with that.

The theory is that the people that don’t do development work are far more likely to know C than know ARM Assembler.

That allows all development to be easier to pickup than learning ARM.
The fact that a source set in C can be recompiled as AARCH64 is a bonus now and essential eventually.

I was debating whether to comment, because I feel that I may get drawn into a conversation that I don’t have time to participate in, and I’m just returning to RISC OS after a 30 year absence. However, this particular comment resonated with me.

Over 25 years ago, I sold my A5000 – and with it my involvement in the ARM world came to an end. I have spent most of the intervening 25 years writing code, mostly in C and C++. I quite like C++, and really like C++11, but it took me five years to properly understand it and be able to use it properly. Now it is my system programming language of choice. I also used to write code in x86 assembler, but I haven’t done any of that for ten years or more either. I don’t think I could write more than a “hello, world” program in x86 assembler these days, and I don’t think I could do even that in ARM assembler. In my programming career, I’ve written and debugged device drivers and filesystem drivers, mostly for embedded systems. Almost all of this work has been in C. I was struck by Gerph’s comments about his return to RISC OS programming being “fun”: I have been very lucky in that I’ve almost always had fun writing code.

I’m hesitant to commit to doing anything with RISC OS, because my time really is limited (and the RPi4 I currently run RISC OS on every now and then is actually intended for a non-RISC OS project). However, I have neither the time nor the inclination to learn 32-bit ARM programming. I looked at some of the smaller bits of assembler, wondering if I could perhaps convert them to C, and turned away shuddering. I am in awe of Julie Stamp, and those like her, who have rewritten large and complex elements of RISC OS
in C. I don’t know where to begin to think about speculating on the merest possibility of starting.

I speak only for myself, but I suspect that I am not the only programmer in this situation who looks at RISC OS and thinks “that’s interesting”, but shies away from any major involvement because of the hideous amount of incredibly clever assembler in the source. I applaud the immense effort that some people are already putting into converting as much of the assembler into C as possible, but I fear that unless and until the barrier for entry (I absolutely detest that phrase, but I’m tired and can’t think of a better way of saying what I mean) then the trickle of new developers will eventually become nothing more than an occasional dribble, and that would be sad. There will always be someone who is intellectually stimulated by the idea of learning a new dialect of assembler, but there will never be many.

Oh dear. I hate walls of text, and now I are one. I’ll stop typing.

In my programming career, I’ve written and debugged device drivers and filesystem drivers, mostly for embedded systems

RO is nearly an embedded system and it’s short of people who know how to write device drivers.
Think about that a little.

I have been very lucky in that I’ve almost always had fun writing code.

Many years ago my father told me what he had been told by his father and…

Basically, if you don’t enjoy what you’re doing then go and get a job you do enjoy. When you do then at least two people benefit:

1. You, because you now have fun while collecting the pay
2. The person that takes your old job because they can, hopefully, have fun while collecting the pay too.

Of course there’s also the benefit to the others still at the old workplace who don’t have to listen. :)

I’ve had 4 people, so far, come back visiting and insist on thanking me for the advice.

RO is nearly an embedded system and it’s short of people who know how to write device drivers.
Think about that a little.

I know. But as I said, I’m very short of time as it is. I’ve burned myself out more than once by taking on one project too many because it looked interesting. I may yet decide to treat myself to the DDE for Chrimbo, after which I’ll almost feel obliged to write some code with it to justify the extravagance.

I need a clone. But preferably not an evil clone who would spend all his time plotting my destruction, instead of writing code.

it does not matter, we have the real ARM CPUs and always will

The problem is that the ones we want (i.e. desktop class) will go two ways: the Aarch32 ones will go out of production, and the Aarch64 ones will be no use to us unless we either convert the OS or go over to emulation.

The ones we’re using nowadays were driven by the needs of mobile phone manufacturers. They buy millions – that will never be true for the RISC OS market. But the mobile phone manufacturers are moving on, to Aarch64 – and why wouldn’t they? I cannot think of any reason why Aarch32 would offer them an advantage.

So the way I see it, all the big quantities (and we’re hanging on their coat tails, so to speak) will have gone Aarch64. What’s left running Aarch32 will be for embedded systems, and won’t offer the graphics and MMU that we need.

Conversion to C would make it possible to implement RISC OS, not only on Aarch64, but anything else too – and I’m thinking primarily of Risc-V here – if we find we can’t get cheap boards with an ARM CPU that we could use.

For an embedded programmer there is no notable difference between AArch32 assembler like this:

LDR  R0, =(1 << (20))	// R0=GPIO1
LDR  R1, =0x40048080	// R1=SYSAHBCLKCTRL0=0x40048080
LDR  R2, [R1]		
ORR  R2, R2, R0		
STR  R2, [R1]		

And C like this – except this C will compile also into AArch64:

unsigned long *SYSAHBCLKCTRL0;
SYSAHBCLKCTRL0 = (unsigned long *) 0x40048080;
// GPIO1 clock
*SYSAHBCLKCTRL0 |= (1 << (20));

And by the way, RPCEmu AArch32 emulation is programmed in C, so no such big step towards a wrapper for remaining AArch32 modules to run on AArch64

You are making a lot of (mostly likely to be incorrect)

I’m afraid it’ll be correct.

It will be easier to produce newer AARCH32 (or Classic ARM) ISA based CPUs

It would be extremely difficult. But, in a way you’re right, as a 64bit port (with 32bit apps compatibility) will be even more complex. ARM is not x86. On x86 you can still launch 32bit applications. With AARCH64, forget AARCH32 apps. And without apps, RISC OS has absolutely no argument to oppose to Android or Linux.

So what?

1. We’ll probably dead before the last 32bit SBC boards will be obsolete. And probably long before we exploit the full power of the Pi4 B or Pi4 B+.
2. The work toward migration component by component to C will continue. And one day, a “straight” port (beware of 32→64bit issues) will just be possible. It’s not today, but we have still time.
3. Work toward legal issues to raise Amber core to ARM9 level should begin. Just in case and because it would be fun too. Work around reintegration of modern components in 26bit OS is important too… to get a real and free RISCOS 5 / 26bit offer.
4. Work around RISC OS on Linux and Qemu port should continue. The first one gives us access to the latest AARCH32 cores. The second one will benefit from the work of the Linux community around 32→64bit translation code.

which does not cover the full instruction set for any of the 3 ISAs it is supposed to cover.

An interesting statement. The only exceptions I’m aware of are accidental side-effect instructions that aren’t officially supported and aren’t guaranteed to be available on every nominally identical implementation, and a few that are only there for backwards compatibility and whose use is deprecated. If you’re aware of any others, do tell. I still have friends at ARM who would like to know.

Edit: of course any new instructions/variants since 2007 might not be covered. I’ve no idea whether UAL has been updated since I retired.

Yes I must say that I agree with those that say if we lose ARM32 we may have 0 or fewer users on the new target.

It entirely depends on what RISC OS will look like on whatever new target it will run on.

Hypothetically, if a ground-up rewrite of RISC OS is done and a well-working compatibility layer is provided for existing software (think MacOS-now-on-ARN-with-Rosetta2), I would expect RISC OS to keep its user base mainly intact. Mainly the same story as before with the move to RISC OS 3, to Risc PC/RISC OS 3.5, to StrongARM, to 32bit, to ARMv7, to ARMv8.

If there is no compatibility layer to keep the old software running, the user base will be very small (and the developer base probably too – who likes to develop stuff that no one uses?).

You just do not get the feel of ARM on any other CPU, regardless how you want to word it, no matter how you wish to skew marketing.

There is no part of RISC OS that provides a “feel of ARM”. My main RISC OS usage is, for a variety of reasons, on emulators like RPCEmu. It feels just fine, because it runs RISC OS. The fact that it emulates an ARM CPU is completely irrelevant.

RISC OS is one of the few OSes left for those that are interested in using a computer

You mean apart from MacOS, Windows, Linux, iOS, Android and any other OS that still exists?

There are so many computer usage patterns in the world, and so many different users wanting different things from their OS. If RISC OS vanishes tomorrow, the vast majority of computer users would not even notice it.

(how many RISC OS users do you know that do not write any code at all, I am guessing close to 0).

The majority of RISC OS users I know do not code. A minority used to develop on RISC OS, but is now only doing small things now and then. An even smaller minority is actively developing software. The smallest possible minority of 0 does development in ARM Assembler unless they are forced to (because e.g. they maintain legacy software).

So for all users I know, the fact that currently RISC OS runs on AArch32 is largely irrelevant. If there was an x64 version tomorrow, with perfect emulation, the vast majority would happily switch.

If there was an x64 version tomorrow, with perfect emulation, the vast majority would happily switch.

As long as it’s got BBC BASIC and !Draw, the desktop works, and BASIC handles the WIMP exactly it does now, I don’t honestly even care about emulation. At all, never mind perfect. It’d be nice if Zap worked as well, but I could write something in BASIC that would perform the relatively limited tasks I use Zap for quite easily if I had to.

Okay, I’m almost certainly not typical. But who is?

The majority of RISC OS users I know do not code.

Actually Steffen, I think you could shorten that sentence – just substitute the “RISC OS” with “computer”

I would put a good bet on all of us knowing more general computer users, of any OS, that don’t code.
There’s over a hundred staff in my department (IT) and I reckon that over 70 of those wouldn’t know a script from a binary.
Move out to the general user base, and they, mostly, know what icon to click and where the power buttons are(mostly).

You just do not get the feel of ARM on any other CPU, regardless how you want to word it,

?

You don’t get the feel of x86 on ARM. Undoubtably the same for MIPS. Or a 6502…

One could argue, even, these days, that you don’t get the feel of ARM on ARM.

So, uh, it’s a weird thing to say. Processor families are sort of entities to themselves. Even 6502 and Z80 (way popular back in the day) behave differently enough that one isn’t going to mix ’em up.

If there is no compatibility layer to keep the old software running, the user base will be very small (and the developer base probably too

That’s why I said (what seems like forever ago) that the compatibility solution has to be given equal priority to the OS. In essence, either baked in or released at the same time. Then we can hit the ground running, because a new OS that doesn’t have any software? Not so useful.

There is no part of RISC OS that provides a “feel of ARM”.

I suppose this depends on what “feel” actually means. A lot of the current RISC OS API is heavily tied to the behaviour of the processor (assume R14 is return address, R13 is stack, entry stuff is in R0-Rx, pull address off the stack directly into PC to claim, dick around with the CPSR in this way to go back to user mode, etc etc).
What’s R14 if we’re thinking of porting RISC OS to x86? [it’s a rhetorical question, David]

You mean apart from

That’s exactly it. There are probably few people around that care what they are using, they only care that it does what they want it to do.
Consider my little NetRadio. It’s some sort of system-on-a-chip, the ESP32. It has WiFi baked in. The SPI port is wired to a hardware MP3 decoder. The IIC port is wired to an LCD controller. Two buttons are wired to GPIO. A smallish (about 10K) bit of C code (that takes FOREVER to compile) has the task of connecting to my AP, then connecting to a station, changing volume by button press, or station by longer press, also decoding and displaying embedded track name metadata. And the main loop? Currently has no buffering so it reads 32 bytes from the connection and tosses them directly to the audio chip.
I know the processor is a dual core jobbie with a flat memory space (no MMU). How much memory there actually is? No idea (I think about half a megabyte; but not sure how that’s partitioned between flash and SRAM). What sort of processor it is? No idea. What the code looks like in assembly language? No idea. What clock speed it’s running at? Actually, a button press tells me 240MHz. But honestly I don’t much care about that either.
What I care is that I can plug it in, have it connect to PPN Radio, and play me Iced Earth while telling me the current song is called Raven Wing.

I would imagine the majority of people these days probably don’t know that much more about their system than what the badge says. It’s a Samsung S20. It’s an iPhone XIV. It’s a Hauw… however the hell you spell it. It’s a Dell laptop. It’s…..
But what’s inside? Does anybody still care, so long as it works?

I am surprised that you know many RISC OS users that NEVER touch creating any code, even when they need something small and quick.

That’s something that you and I (and a number of those around these fora) can do. For me, coding is essential because, as you say, there are small and quick solutions to little problems that can be put together to perform specific tasks for which existing solutions don’t exist, or would be too complicated.
Consider, for instance, I have a list of names I want sorted. They are CSV format. Well, I could I suppose fire up some sort of spreadsheet, import the names, sort ‘em. It would nominally take maybe three or four minutes assuming I have a PC running and a spreadsheet package on it.
Or it would take maybe half an hour with BASIC to write something from scratch. And the best bit? A bit of faffing with the character encoding and I can choose whether I would like “Ângstrom” to appear after ’A’, amongst ‘A’, or after ‘Z’. Can the spreadsheet do that?

and they, mostly, know what icon to click and where the power buttons are(mostly).

How to start up Snapchat, how to take a selfie…

As an intermediate step RISC OS kernel could be made to work on an AArch64 Cortex-A with EL-0-only AArch32 like this:

AArch32 user mode program calling SWI “OS_Write0” will cause EL-1 exception, which can be trapped, and AArch64 exception handler can set up a wrapper, switch to User Mode, SWI “OS_Write0” kernel procedure will run as EL-0 AArch32, return will cause an EL-0 exception, which is trapped, and AArch64 exception handler restores stack, and return to AArch32 user mode program which called SWI “OS_Write0”

https://developer.arm.com/architectures/learn-the-architecture/aarch64-instruction-set-architecture/system-calls

Consider, for instance, I have a list of names I want sorted. They are CSV format. … Or it would take maybe half an hour with BASIC to write something from scratch.

That is where I would use RiscLua, and it would be a matter of minutes. If the list of names in CSV format is in a file list with nowt else and the names are in double or single quotes, stick the three characters =>{ at the front and } at the back. Then the code

x = dofile (list)
table.sort (x)
for _, item in ipairs (x) do print (item) end

@DavidS

I understand you like 32-bit ARM architecture, so do I, having worked on an ARM assembler, itself written in ARM assembly (about 25,000 lines of assembly code):

http://terje-slettebo.atwebpages.com/eng/extasm.html

However, I think the 64-bit ARM architecture is quite well designed, once I got over the immediate shock of seeing everything that has been changed. :)

For sure, it’s rather different than 32-bit ARM code, no longer having support for:

- Conditional execution of all instructions (now there’s only conditional branch, just like almost every other processor).
- Shift and operate in the same instruction, which can lead to some rather compact and elegant code.
- No multi-register load/store. I really like the ability to load/store the entire register set with a single instruction. That’s no more.
- The PC is no longer treated as a normal register.

However, I also realise that the world moves on, and apparently, what used to give a performance advantage now works the other way. For example conditional execution means we avoid pipieline flushes, but since they have been removed, it indicates that for today’s deeply pipelined processors with speculative execution, these may be hard to support.

I definitely wouldn’t want us to get stuck in 32-bit ARM. If you want that, there’s always emulators and old computers on eBay.

I’d like RISC OS to evolve and thrive into the future, because the more I use other operating systems, such as Windows, the more I miss RISC OS. It really is the best OS I’ve ever used, and I’d love for it to be my main OS.

I can’t do that, yet, because it’s missing some important things, such as a modern, fast web browser.

We can’t afford to get stuck on 32-bit ARM models. I think those who have said that these will fade away, being relegated to low power, low performance devices are right, so one way or another, we’ll need to move on to newer hardware.

For sure, we could always emulate a RISC OS computer on top of another OS, like Windows or Linux, but that’s not at all the same for me.

I want RISC OS to run natively, and as a first step, potentially, we could create an emulation layer on top of a 64-bit ARM system that provides a 32-bit RISC OS computer environment, where we could run RISC OS and its applications.

This would be different than what we have today, where we need a host OS such as Windows or Linux to run the emulator.

A potential next step would be to create a native 64-bit RISC OS, which would be a huge project, involving basically creating a new API, and translating existing applications where possible.

I think it would be useful to keep the API as much as possible as today, but there needs to be changes, such as passing 64-bit register values to system calls.

My 2p worth is that at least initially almost everything will need to run via emulation, with just the kernel (or maybe even just a part of that) being 64 bit. The interfaces will need to be carefully designed and thought out – how will 64-bit RISC OS look? How will 64 and 32-bit parts interact, what are the limits etc. It sounds a bit like what Aemulor does now.

From that starting position, things can converted to the 64-bit side over time. I would imagine 32-bit would need to stay for a long time. An interesting aside would be could RISC OS 64 also have a way to run old 26-bit stuff itself, rather than running Aemulor on the emulated 32-bit CPU ..

From a “future of the OS” point of view, I think it needs to be heading AArch64 (and maybe RISC-V). Having something that will only run on an emulated CPU just feels like it’s an historical OS.

I’m also well aware that do even the bare minimum I’ve suggested would take a lot of work. Best buy that lottery ticket..

My 2p worth is that at least initially almost everything will need to run via emulation, with just the kernel (or maybe even just a part of that) being 64 bit.

Genode… ‘work in progress’ as the saying goes