The long term future of RISC OS

If necessary in the future, perhaps we could come together and produce our own 32bit ARM processors specially designed & intended for use with RISC OS.

Please, let’s not talk about a diversion to prevent future development of RISC OS. It makes far more sense to me to put the effort into translating all the existing assembly language parts of RISC OS into C that can be compiled to any target with minimal or no changes. That way we could run RISC OS on 64-bit processors, so long as we can get enough information to be able to write the HAL.

produce our own 32bit ARM processors specially designed

I wouldn’t worry about that flight of fancy. There’s no such thing as an ARM processor these days. It’s a bit of silicon with the processor, some graphics stuff, memory handling, and a lot of other crap to join all the dots. Getting a custom one of those designed will be EXPENSIVE.
And then you’ll have the fun of being laughed out of every chip fab in the world when you ask for – remind me – how many hundreds of thousands of units?

Or to put it another way: don’t you think the easy simple upgrade solution is to get an existing SoC type device such as the ARM7500FE, whack a bug-fixed StrongARM core in there, and crank up the clock speed. A full 26 bit compatible solution (with 32 bit option) clocking maybe 600MHz and all something totally compatible with old school RISC OS. Stuff USB, we have a podule interface!
But it never happened. Because… Economies of scale. Cost way too much for the number of units ever likely to be sold.

So, sorry, as Dave says, RISC OS needs to adapt to the hardware, not the hardware to RISC OS.

Dave, Rick,
I meant that paragraph as a joke (note the part about getting Richard Branson to fund development) but still, it’s interesting to know why it wouldn’t be possible – I hadn’t put much thought into it, and I wasn’t aware of how expensive it would be to get custom hardware designed and built.

Being serious now, I do hope that RISC OS will continue to be developed and used for a long time to come.

Because… Economies of scale. Cost way too much for the number of units ever likely to be sold.

But, but, we can 3D print everything we need! The enthusiasts said so!

I was assuming the use of FPGAs, not custom silicon. I’ve done quite a few FPGA designs over the years. Anyway, good to know that no-one is serious about it!

Is there an FPGA capable of emulating the IOMD, ARM, IOMD, etc? That’s a LOT of logic, and not being a real processor, it’ll be slower too…

The MiST board can emulate (implement? simulate?) Arc-era hardware.

https://github.com/mist-devel/mist-board/wiki/CoreDocArchimedes

Newer hardware would presumably be possible on a more powerful FPGA (or a handful of FPGAs/CPLDs). But depending on what year it is when you attempt this, you might run into legal issues.

Dave, I agree. However it needs an addition. Documentation. While the bits of source are being rewritten, things need to be documented. Trying to dredge through the RO source tree is the worst.
Regarding the HAL which is almost completely freestanding, what is needed is a set of headers generated for GCC. I make that distinction, because CC doesn’t seem to have an equivalent of -fpic and -pie.
I managed to get CC to generate a “bare metal” binary, however setting a flag to make it relocatable added quite a lot of SWIs to the generated binary.

As far as I know, CC and ObjAsm don’t do aarch64. There may be many possible places to start, but the HAL could be as good as any.

As far as I know, CC and ObjAsm don’t do aarch64. There may be many possible places to start, but the HAL could be as good as any.

In a way, the HAL is the only place to start.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CHDIHCJE.html

RISC OS needs to run EL0 (i.e. USR mode) and EL1 (SVC, IRQ, ABT, etc.) in AArch32. RISC OS has no concept of the EL2 (HYP) or EL3 (MON) modes. The only way of getting out of AArch32 is to cause an exception (interrupt, abort, SWI, HVC, SMC) to a higher exception level which has already been configured to run in AArch64 – and that AArch64 configuration comes from the top down (pin on the CPU decides whether EL3 should be in AArch64, EL3 decides whether EL2 should be in AArch64, EL2 decides EL1, etc.)

So the only way to introduce AArch64 would be to have the HAL implement an AArch64 hypervisor which then drops down into EL1 to boot RISC OS. Potentially 90% of the HAL could be implemented in AArch64 (make all the HAL calls use HVC to call into the hypervisor).

With some shenanigans you might be able to implement a HVC call which allows ‘seamless’ switching between 32bit and 64bit modes, similar to the way OS_EnterOS can get you from EL0 to EL1 without interrupting the flow of your program. Or perhaps more relevant, the way that OS_EnterUSR26 / OS_EnterUSR32 allow switching between 26 and 32bit user modes. But ultimately this would depend on our ability to run our own hypervisor on the target hardware – something that might not be possible (e.g. the CPU might not feature the capability, or we might want to run RISC OS under an off-the-shelf hypervisor like Linux’s KVM, using virtualised IO devices to avoid needing hundreds/thousands of device-specific drivers)

So long-term, an AArch64 EL1 HAL+kernel, capable of running AArch32 EL0 apps, and containing a CPU emulator for running AArch32 EL1 modules, might be the way to go.

So long-term, an AArch64 EL1 HAL+kernel, capable of running AArch32 EL0 apps, and containing a CPU emulator for running AArch32 EL1 modules, might be the way to go.

Probably not long term, there are already ARMv8 implementations that have dropped AArch32 as not needed ¹, over the next decade or so I’d expect there to be considerably less SoCs available capable of running any AArch32 code at all.

As such, maybe?

An AArch64 EL1 HAL+kernel, containing a CPU emulator for running AArch32 modules and apps, might be the way to go.

But at that point, why restrict yourself to AArch64 ‘hosting’.

¹ Though not first party ARM cores yet (Cortex-A etc), watch for deprecation message about 32bit at some point, then wait 5+ years for that to filter through the chip supply chain.

Cortex-A76: AArch64 + AArch32 for EL0, AArch64-only for privileged modes.

https://www.theregister.co.uk/2018/05/31/arm_cortex_a76/

Looking further ahead, next August Google will require all new/updated Play Store apps to support AArch64. Apple have already had this requirement for a couple of years. So once 64-bit only designs start coming out of ARM, the complete disappearance of AArch32 from new designs will mostly be governed by how quickly hardware manufacturers start dropping their older designs. Which could be pretty quick, since ARM don’t really want to keep 32bit around for longer than necessary (i.e. most dev effort will be focused on shiny new 64bit-only chips rather than 32bit-capable chips).

Hmm – are there any examples of what ARM 64 code looks like?

Is anything the same as 32bit?

[edit] Looks to be a totally different processor :-(

http://shervinemami.info/arm64bit.html

no

1. 32bit ARM cores will be available for a very long time. They may well be limited to talking birthday cards, but they’ll exist.

2. The future of RISC OS is emulation.

3. As a dyed-in-the-wool 32bit ARM assembly programmer, I am a dinosaur and my views can be safely ignored.

AArch64 may as well be i7. The fact it comes from the same stable is as important as that depressing claim you sometimes get on films:

From the Producers of <Insert Popular Film Here>

The future of RISC OS is emulation.

This.
Look at Aemulor and ADFFS – it’s going to be easier to write some sort of JIT than to write an entire OS (which would need, yet again, entirely new software).

AArch64 may as well be i7.

This too.
Conditional execution? BOOM! Headshot.
The flexibility of LDM/STM? Double tapped.
RSB? Slaughtered at the altar of optimisation.

In short, everything that made ARM an awesome processor to work with has been thrown out. Leaving something that more resembles a bastardised (more readable) incarnation of x86.

AArch64 may as well be i7.

And this.
Nobody sane writes assembler any more. It’s all compilers. And the compiler and programmer both don’t give a …. what the code looks like, so long as it’s fast. I’m guessing ARM have realised that if they intend to encroach upon x86’s dominance, they’re going to need to pick up the pace.

I’m sure I read that the latest 64 bit incarnation has like a 100 entry pipeline.

I think a misquote of a famous phrase says it all: It’s ARM Jim, but not as we know it.

Does Linux-RISCOS work with x86 processors?
(anyone tried it)

In short, everything that made ARM an awesome processor to work with has been thrown out. Leaving something that more resembles a bastardised (more readable) incarnation of x86.

I think you need to be reminded of exactly how terrible x86 really is!

MIPS would be a better comparison for AArch64.

I’m guessing ARM have realised that if they intend to encroach upon x86’s dominance, they’re going to need to pick up the pace.

I think ARM server chips are dead (again). Maybe they’ll come back (again), but for the near/mid future most of the high-end chips are going to be going into mobile/consumer devices (which Intel have consistently failed to encroach upon). But to maintain that hold on the marketplace, they do need to keep pushing the envelope, which is why they’re so keen on ditching 32bit.

It would be relatively straightforward to write a tool which performs static translation of (sane) AArch32 assembler source to AArch64. It could help us get a leg-up into the AArch64 world, although it would ultimately just be a sticky plaster prior to rewriting all the assembler components in a higher-level language.

64bit modules which can handle SWIs from both 32bit and 64bit code would be a bit of a nuisance. Since SWI parameters are so unstructured, there’s no way for the kernel to know whether a parameter is meant to be sign-extended or zero-extended. Plus of course there’s return values to deal with – it’s no good returning a 64bit pointer to 32bit code. So I’d imagine that modules would need to contain two SWI entry points, one for calls from 32bit and one for calls from 64bit. A bit ugly to have to write manually, but maybe an improved version of CMHG, or some clever C macros, could help take the pain away.

Oh god Jeff just don’t even…

I think you need to be reminded of exactly how terrible x86 really is!

It wasn’t intended as a compliment. I was “exposed” to x86 at college. Luckily “only 286”, but it was pretty naff back then, plus all the memory models and the __near and __far rubbish that was commonplace, not to mention the hoops that needed jumping through to access anything over the 640K barrier (okay, that was an OS issue, but still).
I can only imagine modern x86 is a nightmare gone someplace to happen.

MIPS would be a better comparison for AArch64.

And that’s exactly it. ARM code is what we both see in front of us daily. AArch64 is… yet another sort of RISC processor. Like, as you say, MIPS.

I think ARM server chips are dead (again).

ARM just doesn’t seem to be able to harness the brute force that x86 can. Of course, I could show you the heatsink on my oldish Pentium 4…
…oh, actually, I can. Here’s the crap-resolution “mobile” version from my blog:

Anyway, that’s an oldish 2.8GHz machine, with a heatsink consisting of a big metal radiator with liquid transfer pipes, a big-ass fan (attached to the case) pushing air into a plastic guide through the heatsink, plus another fan on the other side of the heatsink. The heatsink itself being larger than all of my Pis stacked on top of each other. All of that to cool a processor that was cutting edge when XP was a thing.
ARM, on the other hand, churns out designs that get made into entire SoCs smaller than the fan control chip in x86 boxes.

Uh… there was a point in there somewhere. I just don’t remember it any more. ;-)

It would be relatively straightforward to write a tool which performs static translation of (sane) AArch32 assembler source to AArch64.

I’m not convinced. Don’t get me wrong, I know you’re WAY smarter than me with respect to these things, but I can’t help but see the restrictions on the ability to load and save registers (no lovely LDM/STM) mean it’s going to get messy with LDP/STP groups; but probably no uglier than the many hoops that will need to be jumped through in order to work around the lack of conditional execution.

And assuming we arrive at something that actually builds (even though it’ll undoubtably be an unreadable mess), will it actually be any use? So many of the existant APIs work in units of 32 bit words, expect word width addresses and pointers…

It would surely be smarter to write a “virtual machine” emulator (akin to RPCEmu, but not specifically restricted to the peculiarities of the RiscPC) which boots and that then runs RISC OS (in our known and loved ARM incarnation). This emulator, written in a high level language, can be adjusted for whatever the current cool ARM chip is, and RISC OS will just “see” a Pi or an OMAP or whatever the emulator is passing itself off as. Surely long-term easier than trying to retarget the entire OS to every specific device, especially following yet another breaking-change (the 64 bit issue)?

And assuming we arrive at something that actually builds (even though it’ll undoubtably be an unreadable mess), will it actually be any use? So many of the existant APIs work in units of 32 bit words, expect word width addresses and pointers…

Most AArch64 instructions come in 32bit and 64bit flavours – so if the initial AArch64 version of RISC OS only used a 32bit memory map (which is perfectly fine as far as the hardware is concerned) then that would make things a lot easier to deal with.

Surely long-term easier than trying to retarget the entire OS to every specific device, especially following yet another breaking-change (the 64 bit issue)?

Easy? Yes. Rewarding? No.

Maybe we could start rine (Rine Is Not an Emulator) xD

Still, I’d prefer to keep it bare-metal.

You don’t need “near” and “far” with anything newer than a 286. 64-bit X86 processors even have extra registers compared to earlier ones, which still had just four “main” registers.

I often think that it’s Acorn’s failure that ensured RISC OS’s survival… had Acorn survived, if RISC OS still existed at all it would have been emulated, probably on top of a BSD system, similar to what Apple once did with OS X (now macOS) to run “classic” applications (from Mac OS…) Had Acorn been successful the “big” applications would all have been ported to the new OS…

It is my belief, that if RISC OS is to ever be taken seriously by people today (around the world, not just in the UK and nearby), it needs to take a stand as a modern OS. From what I can tell, it’s being “patched” (modules?) to function on more modern systems, but that doesn’t make the OS, itself, more modern. Is RISC OS destined to remain an antiquated OS that only a few select people still use, because they can? Do they not see a brighter future than that?

Is backwards compatibility the absolute (sole) bottom line for using it? Where are the devs willing to recode their programs to a modernized version of RISC OS? Where are the people who think that using RISC OS, itself, supercedes it’s nostalgic past? If a 64-bit version of a RISC OS program existed for a moderized (64-bit) version of RISC OS, are we to believe no one would use it or want to use it, because it doen’t run on the “original version” of RISC OS?

Creating a new path does not negate the old path. If there are programs that only run on the older type of RISC OS (development is ceased or the programmer has abandoned the platform), continue using it. But, where possible, unchain from the old and forge forth with the new!

But core changes to RISC OS are necessary to do that. It won’t be easy, but it needn’t be dismissed as “impossible” or “not worth the effort”. A new future (vs. a revived past) is entirely possible, with motivation and determination.

Provided such exists…

I’m hoping that the shift in licensing will be more aarch64 friendly. I don’t know. Can someone answer that? I know there’s some clump of pedantry over what constitutes and ARM architecture with the Castle license.

There is a point to RISC OS. It fills a niche. Possibly singularly. It is an educational OS. It allows people to use it, write programs on it, and explore the software and hardware on a deeper level. One reason I like using it is it doesn’t get in the way of me talking to the hardware. In fact it actively helps me. This is at odds with other OSes which have layers of abstraction both for security and usability. Many people don’t know and don’t want to know what hardware they are using.
Some people do like to know, and want to learn about it. It’s one of the main things I like about RO.

But core changes to RISC OS are necessary to do that.

SMP was implemented in ROS3/4, and could be again. Wifi was implemented in ROS6 and could be again. Multicore support is now working, even if not yet used.

A bunch of new things are in ROS5 (compared to ROS4): USB support, 32bit support, 4K support, etc. It’s not moving fast, but making everything again from the ground would take decades (see Haiku or ReactOS). The problem is not RISC OS, but the fact that we have only one Jeffrey :)