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

the mental model and knowledge of the quirks of C is something else

Amen.

Come on C is just simplified assembler, it’s not something difficult like writing a good makefile.

Back to the topic at hand, although the interim ARM chips which support 32 bit user mode but only 64 bit provilidged modes are going to be short lived, it is an opportunity to move thigs forward. Work can start on the core of a new 64 bit RISC OS kernel while running 32 bit apps at native speed. The tricky part is moving current 32 bit RISC OS modules from svc32 to usr32, and a 32 bit to 64 bit API shim. The type of modules I’m talking about are application support modules rather than device drivers, which do not inhernetly need to be in SVC mode. Making that change is something which has been talked a for a long time, to make RISC OS more stable, so would not be a wasted effort even if RISC OS ended up being run under emulation on a 64 bit only chip.

It ran so slowly that the Android OS kept killing processes because it thought they weren’t responding.

It’s because Google’s code is fumier bovine and doesn’t bother to try to profile the system in use to adjust for differences.
I say this, as my little freebie tablet, randomly and all too frequently asks me if I want to kill the System UI because it’s too slow.

Today’s lesson kiddies – do not do this!

I’m visualising a giant propeller

Exactly. ;-)

if it completely breaks compatibility with existing applications, you aren’t going to take the user base with you.

Even if you take the user base with you (well, it’s mostly us these days isn’t it? the ROLtd holdouts are still with their 26 bit world), the primary problem falls into two categories:

1, No applications. Even those that can be adapted will take time to be adapted. And what is an OS without applications? Look at Windows Mobile…and that had a Megacorp behind it!

2, Who, how, where, when, why? I mean, the bounty for IPv6 (etc) has touched five digits and it’s still marked as unclaimed. So who is it that’s going to write a lovely new 21st Century Fox RISC OS in C? You know, the one that won’t have any apps… and maybe not so many users… and everybody will be saying “it’s weird, it’s not Linux”.

That’s not to say it isn’t worth trying to develop a 64 bit native RISC OS

I think it would be an interesting development, but I don’t see it happening in reality. Perhaps better to make a 64 bit native emulator to keep the OS running.

would running under emulation on a 64-bit ARM actually be faster than running natively on the fastest available 32-bit ARM boards?

Today? No.

Eventually, yes.

Consider what the Pi4 offers compared to the Pi1. Compare that to the Iyonix. Compare the Iyonix to the RiscPC. Etc.

Especially, if an emulator can spread the work of running RISC OS across multiple cores – one, for example, catering for screen updates, one dealing with other memory accesses, one running the CPU core, and one tying all the bits together? It’s very simplistic, but I think it will in time offer a reasonably fast machine.

Do we really need faster and faster machines? I am still using a Pi2. It’s plenty fast enough. I don’t see any pressing need to go for anything faster for what I need to do. Okay, it’s a little slow at running Windows 3.11 (!), but other stuff I use isn’t annoyingly slow. Of course, that’s me. I know the machine with RISC OS can’t use the GPU and can’t hack playing videos of any sort of quality. But it’s not a problem, I use my phone for that. My little ARM phone that doesn’t break a sweat at recording and playing back 4K HEVC video in realtime. My 2.8GHz PC wets itself if I give it anything more than 720p H.263 (DivX era), and only copes with H.264 if I turn off all the visual enhancements. As for HEVC, forget it. We’re down to a frame every few seconds. Sure, it’s a rubbish Intel chipset, but still, different things have different purposes, and RISC OS’ purpose is not watching videos.
Or today’s complex emails, or modern web use. Again, phone/tablet deal with all of that. ;-)

most of the elephant is somewhat decayed long before you’ve finished it, no matter how greedy you are, or how good your freezer(s).

;-)

Anyway, we’ll have better 32bit chips, and new boards for a few years.

I’m a little more cynical. Sure, we’ll have 32 bit hardware for a while yet, low end smartphones for markets such as India and China-internal will probably run simplified versions of Android or maybe some bespoke OS (given the whole “Trump hates China” thing) where the increased power of 64 bit isn’t really necessary; but will these chips end up on dev boards that RISC OS can make use of?

The problem is that 32 bit and 64 bit essentially provide the same thing, and when enough stuff have transitioned to 64 bit (as a lot of it has), there’s not really any use case in keeping the 32 bit side of things around. Particularly if little to nothing is actually going to make use of it.
After all, look how quickly the 26 bit stuff died off when the real world switched to 32 bit native.

we’ll still have Cortex-R and Cortex-M 32bits offers, with probably MMU on them and much better performances.

I can’t speak for Cortex-R as I don’t know about them; but for the Cortex-M, no. Just no.
The Cortex-M series is aimed at taking on the sorts of roles typically handled by PIC and 8051 devices. Expect a flat memory map, maybe 8K SRAM and 64K Flash, no MMU, and nothing that even remotely resembles a display device. But a ton of sexy GPIO and ADCs and such.

Drones, breadmakers, washing machines, DECT telephones, central heating timers, all those sorts of embedded devices don’t need the sorts of complications that anything resembling a full OS would require. They probably run a compiled bit of software baked into a minimal firmware image, all of which gets dumped on the internal Flash, and that’s ALL it runs.

For this last idea, we could rely on the work made on RISC OS 3 ROM.

Or keep asking around – somebody ought to have the RISC OS 3 sources around. I mean, hell, parts of RISC OS 2 have turned up!

RISC OS currently does not make use of multi cores so on any system it still has lots of potential for speed increases.
In addition it does not always have the required functionality i.e. WiFi so there is still potential improvements there.

Indeed. There’s plenty to do with the hardware we have, without worrying about what to do regarding 64 bit.

Come on C is just simplified assembler, it’s not something difficult like writing a good makefile.

<fx: ejects tea across the room>

which do not inhernetly need to be in SVC mode.

Frankly, I’d say that 99% of user modules do not need to be running in SVC mode.

I’m trying to think of any of mine that have to be running with kernel level rights, and I’m struggling to see how any of it would suffer if that changed.

Sure, some stuff would probably need that level of access if fiddling around directly with hardware, but, well, let’s take a few examples: LineEditor or ZapRedraw or AcornHTTP or my OLED driver (communicates via IIC) or the entire Toolbox… does any of that need to run as SVC?

My 2p’s worth..

1. Although it’s not going to be fun, perhaps it’s time to rewrite the Kernel in C.
2. We need some form of emulation. Hell we’ve only just got things working on 32-bit.
3. What’s the minimum amount of the OS that would need to go 64-bit to allow the rest of the OS to be run via emulation?

I am not sure about sticking it all atop a linux kernel, either from a technical or a license point of view.

However I don’t think “just not supporting 64 bit” is an option either. Nothing says “dead OS” than you can’t run it on any actual new hardware.

Related to 3 above – would that let us run on RISC-V? I think it has been mentioned.

We have RISC OS today.
We have apps today.
And we still have time.

When Cortex-X1 (X2?) boards will be out for 5 years, it will be time to think of the next step.
That does not mean that new developments should not be made with portability in mind.
Good news: it is.

For now, the only problem are the new chips, with only support of 32 bit user mode.

Two solutions here:
- Write a new bootstrap kernel
- Finish RISC OS on Linux (and use Linux as a type 0 hypervisor)

A 64bit complete rewrite will be a huge project.
And if you remember the time it took for the Linux community to support UEFI, I can even say that’s almost an impossible project.

As FreeDOS, perhaps RISC OS, while not dead, will be soon limited to a specific and known set of hardware.
If it a Xeon class processor with 3.3 GHz frequency (Neoverse 2 or Cortex X-next) that won’t be so bad…

Anyway, these processors will be made in 5 nm. So don’t expect too much on the CPU size for the next technologies.
It’s better to bet on MultiCore/GPU/NPU, that RISC OS will never really use…

I can’t speak for Cortex-R as I don’t know about them;

The current Cortex-R’s are a lot less powerful than the A series, but they are getting faster. We don’t need a lot of their capabilities such as tightly coupled memory and running multiple cores in lock step, and we aren’t currently too reliant on the things they lack such as GPU acceleration. They will keep getting more powerful, but eventually they will move from 32 to 64 bit, the R82 is the first 64 bit variant.

Some SOCs feature A and R cores, so it could be possible to run RISC OS on an R core, while a hypervisor and main OS run on the 64 bit only A cores. If you went for a Xilinx Ultrascale, you could use the FPGA to emulate all that old RISC OS hardware :)

Or keep asking around – somebody ought to have the RISC OS 3 sources around.

Isn’t Mr. Abbott busy creating RO3.20 – essentially 3.10 with various backported fixes etc

I suspect this is also true. My attachment to !Draw and !Zap is precisely that I’ve not found any better (or at least equally or nearly equally good) solutions for those particular applications on other platforms. It’s possible they exist, but if so I’m pretty sure they only exist the wrong side of a rather large financial barrier. My attachment to BBC BASIC is purely intellectual laziness, an unwillingness to learn a new language; all the other computer languages I know are either lost in the mists of time or HORRIBLE.

Most things on most other platforms have no financial barriers these days – the open source software movement has pretty much everything covered. Obviously you can cough up for Adobe Illustrator, but if you’re willing to put up with a small learning curve (same as you would with illustrator) you’ll find InkScape to be excellent. There are more editors out there than I care to think of – VSCode and Atom are superb. You can run Brandy Basic on pretty much anything and Richard Russell’s got SDL BBC BASIC all over the shop if you don’t want to delve pythonwards :)

you’ll find InkScape to be excellent […] VSCode and Atom are superb

I’ll try VSCode.

I’ve got InkScape and Atom. I use Atom on the Mac, but flip over to !Zap on the Pi a lot because it’s significantly better.* Likewise, !Draw is considerably better (for my purposes, at least) than InkScape, which I’ve largely given up using because while it’s okayish, !Draw is better, and InkScape can’t save in any (editable) format that I can load into !Draw – whereas of course !Zap and Atom swap files both ways perfectly happily.

BBC BASIC could indeed be replaced by other things, if I wasn’t mostly using it to write apps that work in the RISCOS desktop.

* Just by way of example, Atom has no equivalent of !Zap’s Byte or Word views. Or if it has, I’ve not found them, so they’re somewhere pretty obscure.

I should perhaps explain what it is about !Draw that I like so much: it’s the file format, which is sophisticated enough to cope with everything I want to do, but not so complicated that it’s impracticable for a one-man-band to write BASIC apps* to hack its files. .svg file format is extremely complicated – very powerful, of course, but too complicated for me to bother to hack. I’ve worked out a sufficient subset of it that I was able to write a BASIC app that converts Draw files to .svg; I could write a BASIC app that did the inverse conversion easily enough but only for that sufficient subset. Anything created by any program on the Mac would almost certainly use features of .svg format that I’d not allowed for. I could keep adding features, of course, but that would be a never-ending task.

* Or, back in the day, BASIC + Assembly language ones. Don’t bother with that any more, BASIC’s fast enough now.

it’s the file format,

One of the features of the drawfile format which strikes me, is that it does not permit iteration of any kind. This means that drawfiles can grow to huge size, because the loops occurring in a compact programmatic description have all to be unrolled. For figures best described recursively this is rather noticeable. I suppose there may be some subtle advantages; it certainly avoids infinite looping during interpretation. I imagine that it would be possible to extend the drawfile format by including some kind of iteration, thereby achieving greater compactness, but I suppose there could be some disadvantages that I have not thought through.

it does not permit iteration of any kind

I know exactly where you’re coming from with that! I too have written relatively simple BASIC apps that generate pretty patterns that are enormous Draw files*. But most of my serious use of !Draw isn’t for things like that – it’s for explanatory diagrams, architectural & engineering drawings, maps of fictional places…oh…all sorts of stuff, but rarely anything iterative.

Not sure whether .svg files allow for iteration; it’s not something I’ve ever investigated.

* A few here – not actually iterative in this case – and to be fair, the Draw files are less than half the size of the .svg files – http://clive.semmens.org.uk/RISCOS/RandPats.html

2) 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.

3) Deciding to also mix in a hit-list of all the big-ticket items missing from RISC OS is turning a impossibly large task into a comical one. E.g. Process aware, PMT, kernel threading, proper virtual memory, multi-core, multi-user, user/system privilege splitting, dynamic libraries in user-space.

How many orders of magnitude are we talking about here? If (hypothetically speaking) an Acorn Shall Rise Again fanatic were to win the lottery, and sink their winnings into hiring a team of full time programmers, how big would the win need to be? 7 figures? 8 figures?

How many orders of magnitude are we talking about here?

How plausible would any answer to that question be?

I don’t think that it is possible to provide any sort of answer without an in-depth analysis. This is because the entire convention (calling, module area, privileges, etc etc) is based heavily around the state of the ARM as it was in the late ’80s. Luckily for us, the 32 bit system was close enough in behaviour that some glue could keep everything working.

The 64 bit ARM is an entirely different beast. There’s, like, no chance of compatibility, the API is radically different.

So really some decent thought needs to be put in to how to design a more modern system that looks and feels like RISC OS, but isn’t necessarily hamstrung by the design decisions of the past. Indeed, if it is going to be reinvented in C, it might be possible to create an API that is largely agnostic of the underlying processor (like Linux) so the same thing could, in theory, run on ARM64 or ARM32 or even IA64…?

We can learn a lot from how other contemporary systems behave, to fold this into the new RISC OS (what will that be, SEVEN? ;-) ), as since the majority of existing software will not work, it is possible to make radical changes to the underlying system. But, you might think, why not just clone Linux and make a RISC OS like window manager? Because the nice bits of the UI aren’t the only good parts of RISC OS (and I, for one, detest the everything-mounts-into-/ paradigm and the case sensitive filenames).
Another thing, almost as important as the OS itself, is some sort of emulation service not unlike Aemulor that is capable of running older software within the Desktop as if it were a 64 bit app. This must be included with the first release of the OS, as an OS without software isn’t terribly useful.

So, as you can see, it’s not simply a matter of rewriting things in C. It would be nice if it were, but making a proper transition to 64 bit is akin to making a transition to an entirely different platform. So we really ought to work on a way to do it properly so we don’t end up with a dead llama the next time ARM change everything. ;-)

Additionally – I think the ‘figure’ sum might also depend upon how soon you wanted it. RISC OS itself went through three incarnations of Arthur (the first one being very rudimentary), then to RISC OS 2 (the first arguably usable one), and finally arrived at the better specified RISC OS 3 about five years later. I consider the transition from 2→3 to be the biggest development ever done to RISC OS in its history.

How possible (again, given a fantasy league of programmers) would seamless emulation for old applications be? Especially if the new OS went the whole hog with preemptive multitasking and other “missing” features? Presumably each old application would run in its own 26 or 32 bit virtual world, encased with something that translated between these virtualizations and the surrounding 64 bit OS. But how possible would this “something” be? Could it be meaningfully done, or would it be a never ending war against show-stopping special cases?

(Again, I realise that this is the kind of question where I can’t expect anything more than an informed guess.)

I’d be more inclined to work on making such a guess if I thought there was any realistic probability of a major lottery winner (or a Gates or Zuckerman) taking it into their heads to think this was a good idea…or do you know someone, Charlotte?

Just worth pointing out that preemptive Win32 and NT (or Windows 95/98/ME/XP…) were all capable of running cooperative Windows 3,x applications alongside regular apps.

Apple also has form here with Rosetta (and now Rosetta 2).

It’s a challenge, certainly, but not one that cannot be overcome. And, yes, the special cases are what will make it fun. ;-)

all capable of running cooperative Windows 3,x applications alongside regular apps

Sure, but how big was the team that built the system with that capability? How big was the market for it, that paid for that team?

…which I believe might be an answer to one of Charlotte’s questions. ;-)

Sure, but how big was the team that built the system with that capability?

Since what is being described is pretty much a ground up OS that feels like the current OS – pause and consider how many developers it took to produce the version we’re looking at today = x
How much were they paid per year = y¹
How long did they take to do the job? = z²

x * (y * inflation) * z = minimum cost

It’s hypothetical sugar-daddy payments being discussed so the market size is irrelevant.

¹ Since this is a “fantasy” and purely “hypothetical” it wouldn’t be minimum wage so you could consider the old Acorn salaries and inflate or pop in a current ‘typical’ cost.

Not sure that’s quite the right question though. Building the OS might be easier second time round for two reasons: better tools, and hindsight – we’ve got an (implicit) spec already, whereas the original team were developing the spec as the thing grew.

On the other side of the balance, there’s the need to provide the environment for the old 26-bit and 32-bit apps to live in.

…or do you know someone, Charlotte?

Alas, while there are plenty of Acorn Shall Rise Again fanatics, I don’t know of any who feel that a computer running RISC OS 7¹ is the only thing their 100 metre mega-yacht is missing.

¹ Would it be called RISC OS 7, or would you get people insisting that such a thing only justified a minor version number?