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

@ Druck

@Pablo

(simulate an Italian-American Brooklyn accent) Are you talking to me? Are you talking to me? :D

If so please remember b != o , it’s a single letter that makes all the difference between Italian and Spanish ;)

That’s the one. We need a new HLL, multi-core, multi-thread OS anyway, when we have the kernel, device drivers and a Wimp, we could then run most of the rest of classic RISC OS in a container (possibly also fixing the lack of 32 privileged modes at the same time).

I am with you on this one, but that does means rewrite most of the Classic RISC OS, in a Docker-like fashion the containers doesn’t actually run a kernel (at all). Docker for example relies on the Linux Kernel capability of using LXC (especially on the namespaces and control groups), and this capability is completely missing in RISC OS.

I think the closest one to this type of approach is what Michael G. is working on with Genode as a host operating system and run RISC OS on top of it. However to achieve what you want we need a bit more because you want a WIMP that “reconcile” all the different containers and so that WIMP has to run on the host OS and provide an API for the guest to use.

There may be better Architectural approaches to make this easier, I am trying to think of something…

Sorry about getting your name wrong.

I’m suggesting keeping most of classic RISC OS as is, and rewriting Docker! Or rather something that’s the same concept but not actually Docker.

Pablo

We could always stick with Paul :)

I think the closest one to this type of approach is what Michael G. is working on with Genode as a host operating system and run RISC OS on top of it.

I believe Michael was also using RPCEmu (or QEMU) to generate a half familiar “hardware” for the OS. That was essentially to provide an alternate to scrabbling around for compatible hardware to run a 32bit OS, but as you noted it could provide a more secure loader and hardware abstraction than currently used.

No, I would suggest that the applications sit in a read only location

Yep

Thank god we don’t have good video playback…

:)

So, how goes the chain of trust if you don’t know and can’t audit what your computer is actually running?

Easy: there is no chain of trust without complete audit. Or you need to accept a part of risk.

So are you suggesting ROOL to sign every existing Application as well?
bq + override mechanism

Yes, that’s the idea.

@ Steve

Pablo

We could always stick with Paul :)

Lol as long as it just one and not all of them lol

I believe Michael was also using RPCEmu (or QEMU) to generate a half familiar “hardware” for the OS.

Michael is using Genode as the host OS and yes run RPCEmu on top as an emulation layer (but this just initially).

I am thinking of using Genode as the Secure OS to run in TrustZone and add support to RISC OS to talk to Genode. But this doesn’t collide with Michael work, another Genode can run in TrustZone to provide secure Keys and validation in a way that no application can compromise.

But again just an idea.

May I point you to what was shown yesterday at the meeting of the RISC OS User Group Of London (online)? See slides and more information here: https://pyromaniac.riscos.online/

From the website:

RISC OS Pyromaniac is an alternative implementation of RISC OS for non-ARM systems. It provides a semi-hosting system within which RISC OS binaries (utility, absolute, and modules) may be loaded and run, within an operating system environment which matches RISC OS Classic very closely. RISC OS Pyromaniac is:

Lol as long as it just one and not all of them lol

“Meaning: “Humble”; “scarce”; “rare”; "small"" – we’ll put you down as a rare find :)

Michael is using Genode as the host OS and yes run RPCEmu on top as an emulation layer (but this just initially).

“half familiar ‘hardware’” – I chose the words carefully.

I am thinking of using Genode as the Secure OS to run in TrustZone and add support to RISC OS to talk to Genode. But this doesn’t collide with Michael work, another Genode can run in TrustZone to provide secure Keys and validation in a way that no application can compromise.

Not a collision as you say, perhaps a collaboration? He may have in mind to work on the security aspects later, so being able to swap notes with each other would be good.
I mentioned the security in Genode in the little forum thread a week or so ago.
Extremely happy to see you looking at making that work.

But again just an idea.

Go for it.

Confirmation – tablets 😀👍 big desktop boxes ☹️👎.

https://www.theregister.com/2020/11/17/canalys_q3_pc/

Tablets 👎 big desktop boxes 👎 big monitors 😀👍 proper keyboards and trackpads 😀👍 …

Tablets 👎 big desktop boxes 👎 big monitors 😀👍 proper keyboards 😀👍

+1

and trackpads

Much prefer to carry a wireless mouse around with the laptop and similar use on a fixed installation.

¹ I had one session configuring a switch in decidedly-NOT-aircon² location and trackpad interaction was more useless than it normally is on a warm humid day.
In the extreme instance above I ended up working with the laptop tilted and my elbows down so the sweat dripped off my elbows instead of running into the keyboard and onto the trackpad.

Wireless mouse obviously better than a long tail mouse; but I don’t like mice at all. There never seems to be enough desk space for them, and when there isn’t a desk at all…well…

Trackballs – Marconi ones, I’ve not found any other that’s any good – are the ideal, but the Mac trackpad is okay. Perhaps I don’t live in such a hot and humid world as you do! 8~)

Better still – a trackball with three buttons and a scrollwheel/ring, wired or wireless doesn’t matter – but try finding one! ☹️

I’m late to this thread, having been away for a long time, the Cloverleaf project has rekindled my interest and hope in RISC OS, and I came across this thread on the subject of ARM having decided to stop supporting 32-bit architecture.

@Gulli

I’m an ex RISC OS user with a hard case of nostalgia

Likewise.

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!

It’s nice to be remembered… :)

I’m still passionate about RISC OS, and I’d love to use it in my daily life, but lack of support for things we may take for granted in other systems, like a modern, fast browser, has largely prevented me from doing so.

This is something that has made me excited about Cloverleaf, and I’ve made my pledge. I understand the skepticism that many may feel, and for one, I didn’t get my crowdsourced “A potted history of Acorn Computers”, either, which never materialised.

However, I’m happy when someone takes the lead and tries to rise interest like this, including hiring developers, developing new computers, and so on.

Anyway, back to the issue at hand. I’m still far from having completed reading this thread, it’s an interesting one, and I think Peter Howkins said it well in his posting (https://www.riscosopen.org/forum/forums/5/topics/15704?page=3#posts-107849), where he among other things said:

The amount of work in a simple ‘port’ from arm32 to C or arm64 suggested here is orders of magnitude more than all the effort that has been expended on RISC OS in the last 20 years.

I’m just going to throw out some ideas that have already been mentioned in this thread: I agree with what some have said that the most plausible way forward is likely an emulator where the whole OS and applications are run as 32-bit code, converted on the fly to 64-bit code by the emulator.

Yes, it would be great if we could rewrite all of RISC OS to run 64-bit code, either through some translation process, or through rewriting in a higher-level language like C.

However, realistically, that would be a huge project, and what about all the applications, games, etc. where we may not even have the source code anymore and/or are written either fully or with major parts written in assembly code?

I know these things have been mentioned before, just wanted to throw in my two cents, for what it’s worth.

With regard to the earlier project of rewriting the SpriteExtend module as a proof-of-concept. It actually wasn’t any criticism that did it in – I received plenty of encouragement as well. It was more that the scale of the whole task – rewriting RISC OS in a high-level language – started to dawn on me.

Furthermore, in order to get performance reasonably close to the existing sprite functionality, I ended up having to use inline assembly code several places in the inner loops, which became rather messy.

With more modern compilers and faster computers, this would likely not be much if any of an issue in practice.

I think it’s a great idea, rewriting RISC OS in a higher-level language, but I also realise it’s a huge task, and realistically, how many developers do we have who could contribute to such a task?

If we managed to build some sort of emulator on top of a 64-bit ARM platform, where SWI calls and the like were translated to the underlying platform, this might buy us time.

Time to start such a humongous task – should we do so – of converting RISC OS over time to a higher-level languge, for as much as possible.

I notice mentionings in this thread that Julie Stamp is currently working on something like this, could someone provide a pointer to more info?

I’ve been working the last 17 years doing PHP development, so I’m not exactly spolit when it comes to things like type checking. Therefore, even though I pushed quite a bit for using C++ in the earlier thread – particularly more modern C++ – these days, I’d be happy with what Norcroft may handle.

@Rick Murray

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

@gulli

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.

I hadn’t heard about the pattern at the time, but, yes, that was the idea. Since RISC OS is composed of modules, we could rewrite module by module so that eventually, all are written more or less completely in a high-level language.

Furthermore, in order to get performance reasonably close to the existing sprite functionality, I ended up having to use inline assembly code several places in the inner loops, which became rather messy.

Rather defeats the point of a port to C :)

While the C code may be less performant on the same 32 bit system, future 64 bit only chips which will be a lot quicker, so hopefully would have no need of any assembler.

Rather defeats the point of a port to C :)

Exactly, you’d have to rewrite the code, anyway. At least it was a relatively small part of the code, but still way too much.

As you said, faster processors and better compilers *cough*GCC*cough* should remove the need for such jumping through hoops.

Terje Slettebø wrote:

Therefore, even though I pushed quite a bit for using C++ in the earlier thread – particularly more modern C++ – these days, I’d be happy with what Norcroft may handle.

That leads us to another issue with any of the approaches that involve rewriting the OS in 64-bit ARM assembly language or C: what about the toolchain? Has Norcroft been extended to produce 64-bit code?

@DavidS AArch64 is here and is successful, every smartphone and tablet, every high end chip is 64 bit and has been for over 5 years. The 32 bit only chips are lower end, or real time specific. While you still might be able to source these chips in future years, you aren’t going to find them in affordable board such as the Raspberry Pi or set top boxes which some of the other ARM machines are based on. It will be a tray of a 1000 chips at a time, and design your own board, at vastly higher cost.

I assume you were joking when you mentioned XScale chips? Intel’s pathetic attempt to take the StrongARM forward is an ancient ARMv5 core with the lowest instructions per clock and largest errata of any ARM design, and thoroughly outclassed by the ARM11 Pi 1B you are using!

I think you are dreaming if you think people are going to go back to paying more than decent PC laptops for RISC OS machines. I’m only still here because I can run RISC OS on a £30 Pi or Cubox i4 Pro from ebay (otherwise known as the Mini.m). If the only choice was a Titanium of IGEPv5 machine for north of £500, I wouldn’t be able to justify it, and my old Iyonix would still be under the desk gathering dust apart from an occasional use.

If there is any future for RISC OS running on real hardware (as opposed to the dead end of emulation), it has to be available sub £100 general purpose boards, not only very expensive dedicated hardware.

> I think 32-bit ARM, as well as 64-bit that supports AARCH32
> will be around a lot longer than you think, in useful manners

This is unlikely. If you check e.g. NXP roadmap, you will see that replacement for Cortex-A with non-ELO AArch32 is Cortex-M which has no MMU. So only RTOS will stay on 32-bit Cortex-M but other OS will move to 64-bit Cortex-A with ELO-only AArch32 – so RISC OS can no longer run:

https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors:IMX_HOME

In any case, what is wrong with slowly moving RISC OS one module after another to GCC? It would even be possible to initially keep some AArch32 as inline assembler, by switching to user mode, for Cortex-A ELO-only AArch32. With this RISC OS would have as many context switches as Acorn ARX – but with today computing power, this should not matter :-)

Eventually we will hit the point of again needing custom HW for RISC OS

No.
While there is a market for a Raspberry Pi, presumably 64 bit in due course, there is at least one low end set of hardware.
Whether RO development has reacted in time to use that hardware is a different question.

and that will bring the price back up.

Inserting things into the market at a low price, diving out the competition, and then putting up the price is a large corporation habit. I’d say usually large American corporation but most of the large ones are American so the addition is redundant and slightly xenophobic.

Here I thought that Samsung was Japan, and ARM British, those are the two really large corps.

Samsung is South Korean,

As to ARM, I’ve rather lost track of the precise ownership right now but, subject to the usual legal bit’s and bobs the new owners are supposed to be NVidia (USA)
That arises from the previous owners not making the money they thought they would because the ARM licensing model is based on large numbers of units at a low price. Volume, volume, volume – there’s not materials cost so the more the better.

Welcome back, Terje.

@DavidS Although Raspberry Pi is by far the most popular, there are dozens of other sub £100 ARM boards still going strong.

Should the worst happen and nVidia kill the ARM market through excessive licencing, then the RISC V open source processor is ready and waiting to take over this segment. There are lots of rumours that the next Pi may be RISC V.

RISC V is just as incompatible with 32 bit ARM as 64 bit ARM is, but porting RISC OS to C would mean we could move to RISC V if necessary.

Are there any good tools for helping with porting ASM to C?