OS_ClaimProcessorVector again

Probably best to regard the ARMv6 era stuff as useful stepping-stones to the present. 5.xx OS will still support them but there is a need to look forwards.

Mmm, while some systems such as Raspberry Pi OS (it’s not called Raspian any more, even though that’s a much catchier name than the descriptive but tediously boring “Raspberry Pi OS”), Lakka, and OSMC support all versions (except OSMC and Pi4+), others have never bothered to support the original Pi 1 or the Pi 0.
Windows IoT Core and Ubuntu Server for instance. Going even further, Ubuntu Desktop is 64 bit and only works on the Pi 400 or CM4. Ubuntu Mate supports only the Pi 2B onwards (so I’m guessing it’s ARMv8). Slackware (SARPi) supports all with v14.2 but 15.0 and the current have dropped support for the Pi 1.

Interestingly, the BMC64 bare metal C64 emulator (!) appears to support the 0, 2, and 3 and not the 1. The other emulators (C128, Vic20, Pet) are Pi 2 or 3 only.
Android supports either the 3 and/or the 4 (only) depending on where you get it from.

So there is precedence for not supporting the ARMv6 models.

Note 1: Looks like openSUSE supports all, but that’s the most horrible website I’ve looked at so far.

Note 2: Hmmm, looks like ArchLinux supports the Beagle xM – might give that a try in place of the perennially broken Angstrom.
Note 2½: Nope, scrap that. It’s a lot of instructions for how to set up the system using an OS and command line that I don’t have. :/

You’re aware that System is a privileged CPU mode, right? Those comments make me think that you think that it’s unprivileged. Apart from using the user mode register file (and having no SPSR), it behaves exactly like any other privileged CPU mode.

I’m aware it’s privileged. Are you aware it was added by ARM specifically for exception handling user code?

ARMv7 should be the earliest supported architecture

I’d be happy with ARMv7 onward.

The key point here is that older machines will continue to work with RO5, in the same way my A310 still works with RO3.11

RPCEmu (including RISC OS Direct on that)? Maybe not “main machine”, but it’s still essential here.

I believe your argument is that we need to maintain legacy support, so that people can run the latest RISCOS under an emulator? Although I agree that being able to run the latest OS build under emulation is useful for development testing, I don’t think it’s a strong argument to hold back the OS though.

Are you aware it was added by ARM specifically for exception handling user code?

Do you have a reference for that? The ARMv4 ARM (DDI0100B) describes it as being used for running “normal (non-exception) tasks that require a privileged processor mode”, and says that “Privileged operating system tasks are normally run in System mode to allow exceptions to occur within the operating system without state loss” (R14/SPSR corruption by exceptions).

Using System mode for exception handling definitely makes sense for a number of reasons, but nowhere am I seeing it being described as for running “user” code (i.e. untrusted application code), only for running privileged/trusted code (OS code, device drivers, etc.)

Do you have a reference for that?

Sure, but I didn’t say for running user code, I said to handle user code exceptions. It’s in the System mode documentation.

Certainly makes sense to me to use System for exception handlers. The thing that worries me is how you prevent a rogue process from self-registering a handler, which then gets elevated privilege when the app generates an abort – seems like a bit of a flaw in the ARM design to me. Admittedly this isn’t really an issue for RISCOS currently.

Looking at the Handling exception page, it looks like ARM are relying on the EL rings to prevent the OS/hypervisor from being hijacked?

which then gets elevated privilege when the app generates an abort

Not really. According to this: System mode cannot be entered by an exception.

So the OS’ abort handler gets the exception and chooses to drop down to System mode before passing the call on to the application. I would imagine the OS would be expecting something like a signed executable before even thinking about doing such a thing as that.

Yes, but only the Pi1 and 0 (Pi2v1 is ARMv7). With the slower processor and more restricted memory, they’re fine for RISC OS but might struggle a bit with software such as the new browsers.

Due to Andrew Rawnsley the new Iris browser requires ARMv7. So it will currently not work on RPCEmu which I also use most of the time. The speed of Iris is just OK now on a Raspberry Pi 4. Hopefully we will see a speed boost with the multi-threading when using 6 cores on a RockChip RK3399.

Due to Andrew Rawnsley

I suspect there are actual technical reasons!

I didn’t say for running user code, I said to handle user code exceptions.

OK, sorry for the misunderstanding!

It’s in the System mode documentation.

ARM’s explanation there is a bit strange. They’ve forgotten the third option, of switching from ABT/UND/IRQ into SVC mode. SWI instructions are the only direct way of entering SVC mode, and they’re 100% predictable, so it’s easy to write code which runs in SVC mode and uses subroutines without fear of recursive exceptions corrupting R14.

The thing that worries me is how you prevent a rogue process from self-registering a handler, which then gets elevated privilege when the app generates an abort – seems like a bit of a flaw in the ARM design to me. Admittedly this isn’t really an issue for RISCOS currently.

I’d class that as a flaw in the OS design, not in the CPU design. The OS shouldn’t allow untrusted code to register privileged abort handlers.

If you want untrusted user mode code to register and run untrusted abort handlers, then the solution would be to run the abort handler in user mode.

Looking at the Handling exception page, it looks like ARM are relying on the EL rings to prevent the OS/hypervisor from being hijacked?

Yep.

You can also see that the idea of System mode has been carried through to AArch64 – code running at EL1 has the choice between two stack pointers (SP_EL1 and SP_EL0). Switching between SP_EL1 and SP_EL0 is essentially equivalent to switching between IRQ/ABT/UND/SVC and SYS.

They’ve forgotten the third option, of switching from ABT/UND/IRQ into SVC mode

I expect switching into SVC is frowned upon these days, although it’s obviously our current preferred route under RO as we”re saddled with ARMv3.

I’d class that as a flaw in the OS design, not in the CPU design.

Yes, I suppose you’re correct there. It’s going to need some changes to C’s exception handler and deprecation of several Environment handlers when claimed from User code to implement unelevated User based abort handlers. Doable though.

The OS would need to track each handler’s privilege level and enter accordingly in User or System.

So, to sum up…the Abort handler model needs a ground up rewrite, C exception handling needs modifying and we drop all support pre-ARMv7 from the OS.

Tongue in cheek…once that’s all done, we can look at deprecating OS_EnterOS and other forms of code elevation like soft vectors. Then we’ll need code signing, a trusted driver model and we might then start looking a bit like a modern OS!

Joking aside, we need to seriously consider some of this in the near, not far future.

I believe your argument is that we need to maintain legacy support, so that people can run the latest RISCOS under an emulator?

Not especially. Just that I feel it would be unhelpful to those of us who use RO5 on RPCEmu as a significant part of our day-to-day RISC OS usage to basically be told “Oh, just use an old, unsupported OS and stop whining”.

Whether that’s done by getting a reliable emulator in place before dropping IOMD support in the nightly builds, or whether we feel that losing those users (of which I’m one, when I’m not near a desktop ARMv7 machine) is a price worth paying for progress, is just another question which needs to be answered.

So, to sum up…the Abort handler model RISC OS needs a ground up rewrite

FTFY. ;)

Surely RPCEmu is nowhere near as mainstream as Virtual Risc PC (which uses RISC OS 4.03 or 4.39 anyway). There can only be a handful of users in comparison. After all there was no alternative hardware when VRPC was developed. Now that there is, RPCEmu is really just a curiousity of minority interest.

I think dropping support for Iyonix is well overdue.

…RPCEmu is nowhere near as mainstream as Virtual Risc PC

Not sure what your point is here, or that I agree with you. Bearing in mind that RISC OS 5 is 19 years old, and for the majority of that time there has been no practicable RO portable computer, the only way to carry RISC OS 5 around with you was to use RPCEmu on a Wintel or Mac laptop. I’m on holiday at present, don’t have access to my RO Pi and therefore, you guessed it, I’m typing this on a Wintel laptop using RPCEmu. From passing comments on posts here it’s clear that many of us are doing the same. The RPCEmu section of the Forum has 163 topics, the same number as Porting RISC OS, though to be fair, the number of posts is much smaller. No disrespect to VRPC; I just don’t want to be obliged to use an obsolete OS version. Besides, RPCEmu is free. It is also a great way for someone new to RISC OS to dip a toe in the water without committing to actual hardware. You may well be right that there are many more VRPC than RPCEmu users, but that does not mean that the latter does not have its place. As to the Iyonix, I agree entirely, not least because RPCEmu on a reasonable laptop offers equivalent performance.

I just don’t want to be obliged to use an obsolete OS version.

The problem is that all of the emulators provide emulations of ancient hardware much lacking in technical capabilities. Which one is better or more used is irrelevant, it’s what it is that’s the issue.
As things move forward, continuing support for these classes of hardware will prove to be more and more problematic, not to mention restrictive to newer machines.

As it is, we’re still faking an ancient maths chip rather than using the infinitely faster hardware on everything post-Iyonix. This is ridiculous.

It’s like there’s a motorway and we’re trying to think of how to get onto the motorway, and there’s this one guy with a Reliant Robin… ;-)

As to the Iyonix, I agree entirely, not least because RPCEmu on a reasonable laptop offers equivalent performance.

Sounds a bit close to “I don’t use it so it doesn’t bother me”.

With this logic, we can ditch the RPC entirely as the laptop angle is surely catered for by either the PiTop (for basic needs) or the Pinebook (for a little more sophistication).

I would broadly agree with setting ARMv7 to be a baseline for continuing support, and note that all of my Pi machines (except the “daily driver”) and the emulator are both lesser processors. If those machines rest with a fixed-in-time OS version, well, they had a good run. One could argue that the RISC OS world today is more varied and creative than it ever was in Acorn’s time.

Draw a line in the sand there, then it’ll be less of a shock should RISC OS ever actually make it to 64 bit. Which will wipe out pretty much everything except the few ARMv8 devices.

And, understand, you live in a unique bubble where we’re even discussing active support for twenty seven year old hardware. My iPad Mini (first generation) from 2012 stopped having OS updates with iOS 9.something in 2016. Ubuntu and Windows 10 specify a minimum of a 2GHz processor (which knowing them is rather optimistic). That’s around 2002 or so onwards. So that 486DX66, roughly time equivalent to the RiscPC, is landfill. Acorn themselves forgot about Arthur the moment RISC OS 2 became, and by the time of the RiscPC, I don’t think their updates even supported RISC OS 2 any more…

I would broadly agree with setting ARMv7 to be a baseline for continuing support

And do note that should a decision be made to cease support for everything prior to ARMv7, you’re free to fork the codebase and maintain your own builds for the older machines. :-)

That said, I think in reality this won’t happen. It’s more likely that certain features will be added along the way that simply won’t be included in incompatible OS builds.
As for the exception handling that started the discussion, I can see a new source being added, with a name like “newvectors” or something, and the older machines (IOMD and Iyonix) simply remaining linked to the current code, and more capable machines using the newer code. Not a perfect solution, more a way of kicking the can down the road awhiles.

If we go for ARMv7 minimum we can get the FP sorted out standardising on VFP3 and Neon. That will enviably cause incompatibility for ARMv6 and earlier, but then no one uses FP on RISC OS do they? :)

There are millions of Pi 0,1,2 out there, none of which is great for running Linux with a GUI. One of the ways to get people to try RISC OS is to suggest they put it on one of these old Pi’s that is now sitting in a drawer and see how it flies along compared to Linux on the single core using only 20MB of RAM :-)

Cutting off this avenue seems foolish.

Those are the very oldest, slowest and most memory limited Pi’s, and anybody trying any desktop OS on them is going to come away severely disappointed. We would be doing ourselves a favour by not exposing RISC OS on anything before a 5 year old Pi 3B.

It wouldn’t be so much of an issue if were still only running decades old software that was fine on a RISC PC, but with the new browsers coming out, (which will be one of the first things any user will want to try), the older Pi’s just wont cut it.

Cutting off this avenue seems foolish

Just because it doesn’t run the latest OS build, does not mean it’s “cut off”. It also doesn’t mean it stops being updated, ROOL still provide !System updates back to RO3.x – that won’t change. They’ll still continue to run all the software they run today, you can still use them to play games and develop under VM’s etc.

By continuing to actively support older ARM revisions, we’re severely handicapping the kernel. Take the OP as an example, Jeffrey’s proposal to resolve an issue that’s going to impact a future SMP capable OS has had to take into account that it needs to retain compatibility with ARMv3.

I on the other hand have raised the point that to maintain that compatibility, we’re perpetuating a legacy model that is both flawed and insecure. Although I agree with Jeffrey that the underlying issue is there and needs to be resolved, I feel that if we’re essentially implementing a new API, lets not implement something that’s going to need replacing again in a few years.

My point is that we should consider leaving what’s there as-is but deprecate it and replace it with a new model that meets modern OS/ARM ARM standards. To do that it can’t support legacy CPU.

Yes, it’s going to inconvenience some people because they can’t run the latest build under RCPEmu or on a Pi1, but that is not really a strong argument to hold back the OS as both are now over 10 years old.

If we want an OS that runs modern browsers, supports SMP and has any level of security, we have no choice but to drop legacy CPU support. I personally feel it’s about time we made that decision.

There are millions of Pi 0,1,2 out there

Pi 2 is Armv7 (or v8 for the “Pi 2A”) so wouldn’t be cut off under this proposal. The 0 and 1 would be though.

So in summary, we should stop supporting & updating older CPUs, while still continuing to support & update older CPUs. Got it! ;-)

@Jeffrey: If it takes you 1 hour of your precious time to fix it for older CPU’s I guess it’s okay…if it takes 20 hours…I’d say skip it…but I guess you have your own threshold here ;-) I’m totally with David J. Ruck…nowdays for a general user the OS is more or less irrelevant, the user at first needs/wants a modern browser that works, and from my experience with Linux on RPi’s I’d say anything except RPi4 I would never touch…

…for a general user the OS is more or less irrelevant, the user at first needs/wants a modern browser that works

Amen to that. But I wonder how much 32-bit safe software would carry on working on the putative RISC OS 7? If I couldn’t run Artworks, Easiwriter, Ovation Pro or RiscOSM, say, on a new OS version, it would be of little interest to me no matter how fast it ran Iris. I’m all for progress, but the familiarity and ease of use of RO software is, I suspect, no less important to most of us than the appealing features of the OS itself. Of course I could carry on using all the above on RPCEmu/RO5 or a Pi, but then I wonder how much use I’d make of ‘7’.

I personally feel it’s about time we made that decision.

It’s a no brainer, but how does that work?
I mean, who are “we”? and how do “we” make such a decision?