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

and 2050 if you make your own safe stock

I’ll be a hundred years old if I’m still around in 2050, so perhaps I’ll stop worrying.

Oh.

I’d have to start worrying first, perhaps I won’t bother…

Really a lot.

I assumed so. I’ve not bothered, very happy with my Pi3b.

…with budget £NaN, shirley? 8~)

With Nan you get what you pay for, but fresh would be best.

The bounty for Ipv6 is still open and IPv6 is at least as important as 64 bit.

Not really. You could sit an IPv4 machine behind a IPv4 to IPv6 gateway for years and certainly longer than the ready supply of new 32-bit ARM core hardware.

I can run RO 3.1 on my Wintel laptop thanks to emulation.

You can run RO4.02 on that laptop too – RPCEmu.
Emulation, somewhere in the mix, is likely to be an answer.

Nota: RISC OS can (with some changes, or with RISC OS on Linux) can work on the Cortex-X1, A78 and A78C (just announced) cores. Cores that you will not find in high end products before at least one year (new high end SBC are still coming with Cortex-A72 cores today). A78C: up to 8 cores, more than 3 GHz. I’m not really sure that the 64bit only cores from ARM will do much more in term of IPC (the number of cores in the future processors is another story).

The efficient way to do this is simply to adopt Linux a boot kernel and RPCEmu.

Fixed that for you.

Having said that, I suspect that RPCEmu is just a very first step on the way to a micro-kernel¹ and ‘emulation’ layer. Why should any new virtual machine mimic a machine from the last century?
Why not a generic ARM accompanied by devices that are part of the underlying hardware which might x86 style, or ARM, or …

¹ One such setup is being experimented on right now as you may have noticed.

Cortex A78 looks like a very interesting beast. Of course it would be nice to get multicore RISCOS on it, but I’m interested to see what
“The AArch32 Execution state is a 32-bit Execution state that preserves backwards compatibility with the Armv7-A architecture and enhances that profile so that it can support some features included in the AArch64 state”
means exactly…not that I expect to be doing any assembly language programming any longer, without which that’s an academic interest only…

It means that you can’t boot directly in a 32bit OS.
But with RISC OS on Linux (64bit Linux of course), it should work!

I think, the problem is the same with the Amazon Neoverse instances.
https://www.riscosopen.org/forum/forums/9/topics/15359
2.5 GHz, 64 cores, excellent IPC.

@Pablo, I’m not necessarily talking about a ground up re-write, but ground up support for certain concepts. RISC OS is essentially a single context OS, there is only one state, and while the wimp pages in different programs, the OS retains the same state throughout e.g. all the file handles are visible to all programs, doing a multi-part calls such as reading a directory contents can be broken by doing it over a wimp poll if another program also tries to do it.

To try to retain maximum compatibility, you essentially need to containerise that single RISC OS context, and instead have a layer below which can run many such containers pre-emptively switched, running across multiple cores, and supporting blocking IO. To the application it will feel like it has the whole OS to itself, and wont be interfered with by other programs running in different containers. The big challenge as ever is the Wimp message passing behaviour, but that has to be overcome whatever we do. Other things that would trip this up, would be attempts to share any resources between applications, such as passing file handles between programs. Obviously anything that’s entire purpose is inter-program co-operation would need to use a new API, which would be used by the Wimp for things such as the shared clipboard.

What exactly would you characterise as the defining aspect of a RO programme with no GUI interaction that differentiates it from an IoT programme?

It depends upon what the IoT device actually is, but I’d say there are two primary points.
The first is, the system can’t “fail” due to something stupid like Abort on instruction fetch at &00000002. The underlying kernel has to be able to keep on going, and if not, there should be some sort of periodic watchdog that will hit reboot if triggered.
The second has already been covered by Paolo, the lack of being able to sleep the processor. For some devices, it only needs to wake up and do stuff when stuff needs done. The rest of the time, it can basically just tick over and run minimally. RISC OS currently doesn’t.

But now the reality check.

The reality check is true. It’s nice to think of a potential 64 bit native RISC OS all written in C, however it’s extremely unlikely to ever happen.
(and if anybody is thinking about it behind the scenes, for the love of God to NOT ask the forum for opinions!)

Is RISC OS 5 useful as a server OS

Uh…. really?
You know the platform’s famous lack of protection against, well, everything up to and including Herpes and you ask that?!?!?

You’d probably use some other lightweight OS as the starting point.

The question is, what OS is not going to carry baggage of how it works in a way that is liable to be alien to everything RISC OS?
[example from Unix/Linux: case sensitive files and weird all-hangs-off-/ mounting]

Clearly the best and most appropriate lightweight OS is RISC OS… oh, wait… ;-)

Emulation, somewhere in the mix, is likely to be an answer.

In all honesty, some sort of emulation solution will be necessary, either for working with 64 bit hardware, or keeping 32 bit RISC OS alive on the same.

As such, discussions about what a 64 bit RISC OS could look like are interesting, but in all reality, we ought to be looking at ways to emulate an environment to keep 32 bit RISC OS going.

in all reality, we ought to be looking at ways to emulate an environment to keep 32 bit RISC OS going.

Genode / QEMU

…is simply not RISC OS.

Whether something “is” or “isn’t” RISC OS is ultimately a philosophical question. If the current RISC OS were ported to 64-bit ARM, the result would in one sense “be” RISC OS, but virtually no existing RISC OS software (or indeed anything else) would run on it. If, however, a ground-up rewrite made huge changes beneath the surface while proving a compatibility layer for existing RISC OS software, then in that same sense it wouldn’t actually “be” RISC OS. But in the sense of actually using the thing, it would.

I do not poses the gift of brevity :(

Oh no! Dueling verbosity!

Everybody else can chime in with # What have I, what have I, what have I done to deserve this…

Rick (who is unable to make a point in one sentence when three paragraphs would allow for more clarity, waffle, and general thought meandering, oh look kitten… 🐈)

Whether something “is” or “isn’t” RISC OS is ultimately a philosophical question.

In interesting approach. I’ve already mentioned somebody who felt that RISC OS became less pure when C was added in version 3.
Some people consider the 32 bit incarnation to be some sort of illegitimate lovechild.
Whether or not it is “RISC OS” is more down to the users than anything else. After all, look at the many different incarnations of Windows or MacOS over the years.

BTW, as for purity, history has already spoken on the topic of long term maintainability of tens of hundreds of kilobytes of hand crafted assembler.

If the current RISC OS were ported to 64-bit ARM, the result would in one sense “be” RISC OS, but virtually no existing RISC OS software (or indeed anything else)

Not exactly the first time we’ve been here. Some carefully written things ¹, and a lot of stuff written in BASIC worked on RISC OS 5. Pretty much everything written in C and anything that tried to be clever failed. In the case of C, it was pretty much a matter of recompiling, but still, until then…

(then the unaligned loads, then SWP, then zero page, then ARMv7+ fatally rejecting garbage instructions…)

¹ Recently on my blog I developed, on my Pi, a little program that works on older MEMC based machines right back to the very first release on an ARM processor, Arthur 0.30.

It means that you can’t boot directly in a 32bit OS.

No, you need a little shell to switch the CPU into 32bit mode*, but that done, RISC OS will be able to run natively. Whoopee! “A little shell” can be an awful lot less than a whole Linux.

*Unless of course there’s an external connection you can tie (up or down) to select the start up mode of the chip. Not having seen the hardware spec, I don’t know.

Clive, you mean a shim. On a chip with no 32 bit privileged modes, a shim would be needed on 64 bit privileged mode entry points to switch back to 32 user bit mode to attempt to run RISC OS code, and handle the fall out from code expecting to be in a 32 bit privileged mode.

It might just work for a lot of SWI calls, most of which don’t actually need to be in privileged to work. For those that do, attempts to do things which are illegal in user mode would have to be trapped and the action emulated by 64 bit code (a sort of Aemulor64).

You know the platform’s famous lack of protection against, well, everything up to and including Herpes and you ask that?!?!?

I said: The idea of a desktop OS will be probably forgotten (or legacy) in 2030. Is RISC OS 5 useful as a server OS, or as a workstation OS?

Anyway, I could say the same today for Windows. Most Windows owners are not Windows users, but Chrome – and only Chrome – users.

Whether something “is” or “isn’t” RISC OS is ultimately a philosophical question.

Sorry, but no… I do not use RISC OS for RISC OS. I mainly use it for its applications. And a bit too because I know it. Give me something knew, without applications, but the ‘philosophical spirit’ of RISC OS, and for me it will be like RISCOSE: good idea; no use; no users.

no 32 bit privileged modes

Ah. I’d missed that rather important detail!

I’m an ex RISC OS user with a hard case of nostalgia, so I come here every few months to keep at least somewhat in touch with things. I stumbled on this reply in this thread and I think Paolo’s question is really interesting:

> We desperately need investors, because ideas don’t get stuff done.
Investing on WHAT exactly? Apologies, not trying to be mean or something, I am simply struggling to understand.
Investors traditionally wants their money back + interests produced by a product/idea/solution built using their investments and that has sold/created a market/produced more money…
So, my question to you is: Did you mean we need someone to pay for all the work that has to be done regardless the outcome (for example charity donations) or did you really mean investors in the traditional sense?

Paolo’s question, “Investing in WHAT exactly?” cuts much deeper than just for investors. A while ago I looked into ways to help with RISC OS development without contacting anyone or making any kind of commitment because I wanted to first see how it looks from the outside, without getting insider information about anything.

What really stood out to me was the fact that I couldn’t see any plan or any kind of path forward so I had no idea what I would be investing my time in. There were also several indicators of really hard gatekeeping and any suggestions of rewriting parts of the OS in a higher level language were more or less killed with apathy. There always seemed to be reasons to not change anything. The thing that ended my interest was when Terje Slettebø’s proof-of-concept rewriting a module in GCC C++ basically ended with people asking him to write it in Norcroft C++ or even in C, some seemed to not want GCC added to the build process and some seemed to have even more puritan C/ASM reasons. At the end there were even questions raised why anyone would even need or want the 64 bit processors for RISC OS!

The thread can be found here

I participated in discussions about a possible pre-emptive, multi-threading (and possibly multi-core) RISC OS sometime around 2002. Those suggestions were completely dismissed at the time by people that only saw the problems and not the possibilities in doing these changes and discussions about them are still more or less in the same spot they were back then.

The point is, as long as there is neither a common idea of where RISC OS should be heading or willingness to let go of how things used to be done, it’s going to be near impossible to build any kind of a team that can move it forward. The only developers that will be willing to spend time on it are those that do it for their personal technical challenges or just curiosity. While it’s fantastic to have those they are never going to be enough to make the big changes that are needed.

Getting investors is probably even further off than getting developers when this is missing.

any suggestions of rewriting parts of the OS in a higher level language were more or less killed with apathy

More attributable to a lack of ability or a long number of years using BBC BASIC for everything (with a drop or two of assembler) so C is basically a foreign language.

I participated in discussions about a possible pre-emptive, multi-threading (and possibly multi-core) RISC OS sometime around 2002

2002 was the start of the Iyonix using RO5 and pre-dates Castle/ROOL making the source visible so that would have been a discussion on newsnet about flying blind to alter either RO4.x(ROL) or the new RO5 (Castle/Tematic)
Or did you mean 2012, your forum user number suggests a point in time after I signed up so 2012 is more likely especially round here.

The point is, as long as there is neither a common idea of where RISC OS should be heading or willingness to let go of how things used to be done, it’s going to be near impossible to build any kind of a team that can move it forward.

Did you have an outline plan you wanted to lay down?
I for one am not going to attack any sensible outline or even more detailed ideas.

BTW. Having read the page of the thread you referenced the main replies came from Jeffrey who has done a large part of the development of RO5 over the past few years so his comments amount to constructive criticism or just questions.

Whether something “is” or “isn’t” RISC OS is ultimately a philosophical question.

Sorry, but no… I do not use RISC OS for RISC OS. I mainly use it for its applications. And a bit too because I know it. Give me something knew, without applications, but the ‘philosophical spirit’ of RISC OS, and for me it will be like RISCOSE: good idea; no use; no users.

That’s the very point I’m trying to make. The “spirit” of RISC OS is carried by an operating system that allows the ecosystem of existing RISC OS applications to run in much the same way as they did on older versions (even if this is an illusion provided by a compatibility layer).

2002 was the start of the Iyonix using RO5 and pre-dates Castle/ROOL making the source visible so that would have been a discussion on newsnet about flying blind to alter either RO4.x(ROL) or the new RO5 (Castle/Tematic)
Or did you mean 2012, your forum user number suggests a point in time after I signed up so 2012 is more likely especially round here.

No, I do mean 2002, I may remember the year slightly wrong, possibly earlier, possibly as late as 2005. There were discussions like this on other sites, Iconbar being one, long before the code was released or this site opened, even before Black Thursday, and they all seemed to go a similar way then as they did later on. At the time the discussions were about what was needed for RISC OS to be future proofed and even though the code wasn’t released it was hardly a secret that it was mostly assembler, C and BASIC.
There were lots of discussions, especially after ROL got distribution rights to RO in 1999, about the pros and cons of 26/32 bit, pre-emptive vs cooperative multitasking, multi-threading and even occasional mentions of multi-core operating systems back then – this is not a new discussion at all and that’s the whole point. These things have been discussed over and over on a technical level but rarely, it seems, on a “system scale” and much less on a more product concept level and things barely move forward.

BTW. Having read the page of the thread you referenced the main replies came from Jeffrey who has done a large part of the development of RO5 over the past few years so his comments amount to constructive criticism or just questions.

I’m pretty sure that there was no one commenter or comment that convinced Terje that the whole thing wasn’t worth pursuing, in one of his comments he says “if I wouldn’t be able to use the higher-level abstractions available in C++, I’m afraid that doing this work just wouldn’t hold any attraction to me”, he seemed to feel there was enough resistance to that for him to abandon this.

Did you have an outline plan you wanted to lay down?
I for one am not going to attack any sensible outline or even more detailed ideas.

No. At the time I had mostly been focusing on seeing what plans were already in place but found little. I had collected some ideas others had come up with through the years that I felt could be put together in a long-term, system scale plan that could be discussed but seeing how each of those died off in discussions that often seemed to be rooted in nostalgia and resistance to change, I had a hard time seeing that collection get any support. Then when Terje’s attempt faded out I didn’t see a point in writing up a suggestion that would almost certainly need big changes to the technical stack.

I have no grand delusions that me posting this collection of ideas would have changed the future of RISC OS, it might have helped target the discussions somewhat to a long-term plan or it might have disappeared into oblivion. My judgement at the time was that, with me being a complete unknown in the community, it almost certainly would be the latter and that my time would be better spent elsewhere.

some seemed to not want GCC added to the build process

This does make a weird sort of sense. The entire build process revolves around the DDE and various additional fiddles to build the parts of RISC OS and assemble them into a ROM.
It doesn’t make a lot of sense to add the dependency of an entirely different toolchain in order to create one thing. Not to mention that it’s a dependency that relies upon a third party. I believe the version of GCC from then crashes on ARMv7 machines, and the latest version is a little different in layout, and while there exists a tool to make GCC compiled things be AIF instead of the now-native ELF, can today’s GCC cope with AOF for interworking with the rest of the build process?

From time to time people talk of having a free GCC based toolchain to build the OS. It hasn’t happened…yet. As such, things expected to be added to the current system really ought to be able to be built using either the DDE or BASIC. Anything else would be a complication nobody fancies tackling.

As for the rest of your post, the dwindling market compared to the Acorn days means we can ill afford to render useless the software that we do have, so there is a certain amount of backwards compatibility inherent that does restrict (or even prevent) future development.
Also, aware of the 26/32 schism, a lot of developers have to restrict themselves to an API that works across some thirty years of RISC OS. People such as myself can elect to say “this is the baseline and anything older is unsupported”, but those hoping to make some money from their products can ill afford to be picky.

This is why a potential 64 bit version is such an interesting topic. The processor is so very different that the API would need to change, and all existing software will pretty much not work without modification. In essence, it is a watershed moment. A time to toss away the shackles of the past ¹ and think about what RISC OS ought to be in the 21st century. A difficult discussion, as its hackability is famed about as much as it’s utter lack of anything resembling protection. It’ll sure be interesting getting those two viewpoints to coalesce!

Oh, and David, you’re missing the point I’m making. For every bit of “security” that a desktop computer should have, a server needs that raised to the power of a large number. For a start, while the GDPR does not require encryption of personal data, article 32 recommends it and that it meets current standards. In other words, some sort of user specific key, password, or other biometric for logging in and an encrypted filesystem. Hell, smartphones can manage that these days. RISC OS doesn’t even support logging in…

Back to Gulli to end with. A 64 bit RISC OS may or may not happen. But if it does, it’s a good opportunity to rethink what RISC OS actually is and how it works, and provide some sort of emulation environment for the older (current) software. For certain a lot of the API will likely resemble that which we have now, while at the same time a lot can be torn up and thrown away (please please please can I shoot the keyboard handling?). With a lack of direct support for existing software, there’s less worry of being constrained by historical ghosts. All the things that don’t work can be discarded. And, I hope, this would be a lesson that a C runtime should not be bolted on to an OS written in assembler, but it should be an intrinsic part of the OS which will, itself, be written in C… this time.

¹ Only a few tweaks were needed to get the Arthur desktop thingy working under RISC OS 5. Need I say more?

The “spirit” of RISC OS is carried by an operating system that allows the ecosystem of existing RISC OS applications to run in much the same way as they did on older versions (even if this is an illusion provided by a compatibility layer).

I think one should also mention the salience of the GUI and of the relocatable module system. I sympathize strongly with Gulli’s frustration. In my own case I always wanted a broadening of the range of programming languages available to RISC OS. The trouble is that my own skills are too superficial to do anything useful. Parallel programming and writing code to exploit multiple cores is not something I have learned, and I fear that even ten years ago (I will be 82 next March) it would have been too late to make the attempt. Dreams I have in plenty but then they are cheap, and useless if there are no younger and more capable hands to realize them.

It doesn’t make a lot of sense to add the dependency of an entirely different toolchain in order to create one thing.

On the contrary this is probably the best way migrate development from one toolchain to another, wholesale migrations on the other hand rarely make any sense. You mention some people attempting to use GCC to build the entire toolchain, this is probably impossible to do in one sweep but very much possible to do one module at a time, I present to you the Strangler pattern:

“Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services. As features from the legacy system are replaced, the new system eventually replaces all of the old system’s features, strangling the old system and allowing you to decommission it.”

This was the core of Terje’s suggestion, whether or not he had even heard of the pattern.

As for the 64bitting, that’s way to big a task do even discuss at this point unless (and this was one of the points I had collected) a new OS is designed and built from scratch with built in seamless emulation for the older applications – which is what Microsoft did for DOS/Windows 3.x applications in Windows 95 onwards and Apple did in the first OS X versions (I think they’ve scrapped that emulation now).

discussions that often seemed to be rooted in nostalgia and resistance to change

Ah, I remember the war¹. [said in Uncle Albert voice]

The main thing I recall from that era was the number of people who saw no reason to move to 32 bit despite there being absolutely zero new CPU’s with a 26 bit mode (that was the reason for RO5 on the Iyonix)

At the time I had mostly been focusing on seeing what plans were already in place but found little.

The roadmap here may be to your liking. Updated earlier today.

¹ “Nostalgic” look back to the “entertaining” days of ROL vs. Castle
Thanks, I think pass on that.