Rick's b.log - 2022/11/23
It is the 21st of November 2024 You are 18.116.52.43, pleased to meet you!

64 bit RISC OS?

This, as you can imagine, gets a rather lukewarm response as, well, myriad reasons but here are the main ones:

• RISC OS itself is mostly written in ARM assembler, so porting it to AArch64 is somewhere between "impossible" and "GTFO".
• Nobody in their right mind would attempt to create an entire modern operating system from scratch. Even Apple's iOS was based upon an existing kernel (I forget which) and Android is a very messed about Linux kernel. Sorry, but it doesn't make sense to reinvent the wheel when Linux exists, other than for the nerd satisfaction of "because I can" (but you'll note that the typical bare-metal OS is way simpler than Linux because there are only so many hours in the day).
• Anybody who thinks of rewriting RISC OS for anything needs to be taken out back and shot in the head. RISC OS is very much an ARM version of an operating system for an early '80s home computer. Memory protection is minimal. Interprocess protection is non-existant. One simple unvetted system call will happily give you complete kernel level access. There's even a simple command that can be entered from user mode BASIC to turn off interrupts (upon which case the painfully obvious will happen).
• Because of this, anything that might be written would need to entirely rethink how things work.
• Couple this with the fact that it's likely the widely used SWI mechanism would need to be discarded (the underlying API of RISC OS is extremely tied to the behaviour of the (original) ARM processor), it's pretty clear that whatever might result would not be RISC OS.
• So really it shouldn't carry the name RISC OS. Like, at all.
• Who is going to be doing this work? There are very few people actually developing anything for RISC OS for money. It's largely a mixture of volunteer efforts, doing it for the love of doing it, and wanting to catch a bounty (which, generally, is little recompense for the amount of time invested).
• Writing operating systems needs developers. Competent ones, the understand the sorts of issues involved in creating operating systems. Where are they? How do they get paid?
• Who's bankrolling this?

There are, of course, no viable answers to any of this. Just a lot of how we're all being negative and implicating that if we close our eyes and wish really really hard, it'll come to be.
Tell you what. Wishing is useless. Mom wished for her cancer not to spread. I wished for her to recover and be able to eat at the palative care unit and, you know, not die. Nobody was listening. No fairy granted wishes.
If you close your eyes and squeeze really hard, you might shit yourself. But you won't make a 64 bit RISC OS become. That takes cold hard cash. An absolute load of it.

With this in mind, let's tear apart the most recent topic starter.

NB: This thread is started in the earnest hope that those who work on porting RISC OS to C will contribute to it, see what can be done and who can do what, and those who wish to aid in realizing this project. The cherry is what hardware one may expect RO64 can use to the max and beyond if the work is done right.

The italics are my formatting to make it easier to tell which pile of bollocks is mine and which isn't. The bold was how it was in the posting.

RISC OS isn't being ported to C. Some parts are being rewritten in C for ease of maintenance, because it's far simpler to work out what a C program is doing than a wodge of assembler.
We don't have a runtime capable of being used at kernel level, because the C environment has certain expectations (such as stack frames and APCS register use) whereas the kernel does whatever the hell it wants.
I understand there is some low level C (in the HAL?) but this is done with a great number of restrictions (no library functions, no stack checking, no... other stuff) so it's more like expressing some code in C rather than actually writing anything in C.

If one were to consider the possibility of a successor to RISC OS, it will be necessary to discard the entire current API and think about how to make an API that is processor agnostic. To put this into context, Linux runs on x86, and on ARM, and on MIPS, and on pretty much anything with a decent processor and MMU. This is what a new OS ought to be looking at. Not something that runs on AArch64, but something that can run on "mumble", for whatever that might be.

Now that it's established that RISC OS is being ported to C, the only question validating or negating realization of the topic (plus - will it sell like hotcakes?) is 1) Will it support multicore CPUs, 2) Will it support multithreading, 3) how about preemptive multitasking, ideally also 4) multi-CPU/SoC systems. If it's four out of four here it's a go, provided the port can use libraries like Mesa, OpenGL, OpenMAX and Vulkan and so on to fully utilize Arm GPUs like the awesome Immortalis G715 (which has support for Vulkan v.1-3).

As mentioned above, no, RISC OS isn't being rewritten in C. Any new OS might be, but that's not going to be a port of RISC OS.
In answer to the questions... 1, RISC OS pretty much will not ever fully support multicore processors. There are far too many parts that are predicated on single user context, and the Wimp system has parts that expect tasks to run round-robin (and not asynchronously). The context issue could perhaps be fixed (given lots of programmer time and money) but the Wimp issue risks being a breaking change compared to existing behaviour.
My personal feeling here is that additional cores should be available to RISC OS in a manner similar to how the Tube worked on the BBC Micro. They'll run a cut-down OS that will basically trap system calls and video output (etc) and pass them to the host. Then certain programs can choose to push code to another core in order to have it executing asynchornously to the main OS, and to pass messages/data to and from the other cores. In this way, RISC OS pretty much continues to function as it always has, but it's also possible to access the benefits of having additional processing units.
2, Multiple threads on RISC OS is a bit of a hack. But then, the entire Wimp is a bit of a hack given that the OS's view of the world is a single user single context single process system. It may be that RISC OS gains some ability to handle threads, but I don't see much changing really. I think Unixlib can support them using callbacks and such, so it will likely be a similar method and mostly a convenience to programmers (OS support, rather than having others try to recreate the same wheel over and over).
3, Unlikely. Again, it comes down to working within the constraints of the existing system and understanding that it's single process and single context. Or to put it another way, the TaskWindow module jumps through hoops to ensure it doesn't yank control away from something that is being preempted whilst it is outputting a control sequence to the VDU driver. Because doing that will cause things to blow up. Actually, what TaskWindow gets up to is quite nasty and largely because pre-empting something on a system with no concept of pre-emption needs great care.
4, I don't think he's aware that behind Mesa, OpenGL, etc is often a closed source binary blob that acts as the glue between the standardised view of graphics (such as is provided by OpenGL) and whatever is actually used by the GPU. Because video support is a hot topic, very few GPUs are openly documented and those on ARM boards are pretty much black boxes where all that gets described, if you're lucky, is the framebuffer mode of operation.
This is why RISC OS does it's video decoding in software. We simply don't know specifics of the various GPUs for making use of hardware acceleration, and we don't have the ability to load - say - Linux kernel modules in order to paste in support.

If, however, we're talking about this mythical shiny new OS, then it's pretty much a yes to all of the above (except perhaps the GPU stuff, for the same reason). It would be utterly illogical to create an OS in 2022/2023 that doesn't support threads, multiple processors, etc.

This will obviously no longer be RISC OS as we know it save for the GUI/WIMP system which should stay unchanged - drag & drop everything, middle-click to bring up menu, F12 to give command line and so on. Hence no to little change from a desktop user's perspective except for the massively increased performance, of course.

Not RISC OS as we know it? Ya think?

Sorry, F12 for the command line must go. That freezes the entire multitasking system which is absolutely no good in the 21^st century.

Can't help but think it mightn't be simpler to just create a window manager for Linux that sort of behaves like RISC OS...
...didn't somebody already do this?

So why "da Vinci"? Acorn used Archimedes as the name for their most innovative computer to date (why they chose the rather dull "Risc PC" as a follow-up is beyond me). To continue the "Great European Technological Thinkers" naming convention Leonardo pops up as a natural, and "da Vinci" has a certain ring to it plus it connotes a multidisciplinary mode.

As was pointed out on the forum, the name actually translates as "Leonardo from Vinci", Vinci is a place, not a family name.
There may be issues regarding the name, I'm thinking Texas Instruments, who already have a set of DSP/ARM system-on-chip devices in the "DaVinci" family. There's also the OS of a surgical robot called "da Vinci".
Really, one cannot pick the name of the second most popular painter in the world and expect that name not to have already been used several times over.
(it's subjective of course, but Google ranks them as van Gogh, da Vinci, Picasso, Monet, and Rembrandt for the top five)

And, for my point of view, it's an extremely pretentious name. Showing exactly how seriously I was taking the discussion, I suggested that the new OS be called Steve.

This will be fitting since it'll be a workstation which will be perfect for 2D/3D/animation/video visual arts creation and editing plus audio creation and editing. Much of this will probably require new software to be written because of massively expanded possibilities and options in multi-media creation.

These systems exist in ways we cannot even dream about. We don't have a hope in hell of ever competing with the likes of Avid or Final Cut. These things exist and are widely used to make actual movies. We... don't even have a port of Blender.

Oh, and just for the sake of it, how does a 64 bit ARM board (let's say something like the Chromebook promoted further on) stack up against real video editing systems? I mean, y'all understand the demands of UHD video right? We're looking at 16GB RAM as an absolute minimum, and an I/O subsystem that won't shit itself at coping with sustained data transfer speeds in the order of twenty five gigabits per second (raw 4K UHD at 60fps runs at just under 12Gbit/s, it'll need to be read, processed, and the edits written out). Remember, editors work with raw data.

It takes the two-CPU system used in the Risc PC a bit further, enabling 4 to 6 CPUs/SoCs to be installed which RISC OS 64 can use to the max (provided "4 out of 4", see above) and as such be able to compete favorably with high-end systems for other OS platforms when half populated.

Drivel and bollocks. Any competent OS will spread the workload across the available processors, potentially with certain processes able to lock off one or more for their own use, but really whether there's one, or four, or eight should not present any particular challenge. It's just a resource to be handled. Like multiple discs. Or two display units.

The last sentence... clearly he isn't aware of what other high-end systems are capable of achieving. Look at the requirements for Autodesk Maya, then get back to me on how well you think RISC OS "half populated" will stack up.

Oh, and I'll give you a hint. Maya costs €2,226/year (current pricing) or a slightly more economical €6,342 for 3 years. That ought to give an idea of the scale of heavyweight that high-end means. As for where Maya has been used? Extensively everywhere. Google it.

Us? A small group of enthusiasts, compete with that? Don't make me laugh.

The best SoC to use to date may be the https://i.mediatek.com/dimensity-9200 (1) from a standalone performance view, but it does not have provisions to be in a multi-CPU/SoC system.

Sorry, I think the Nvidia AGX Xavier might be an SoC that would crush that little MediaTek jobbie into dust. The CPU is a eight core ARM design with megabytes of cache (8MB L2, 4MB L3)... but the video... oh my god... how about sixty four Tensor cores and five hundred and twelve CUDA cores?
To put this into performance stakes, memcpy can run at 11,056 MB/sec (Pi 3B+ manages 1,292 MB/sec). The Pi 3B+ can run the TTSIOD 3D render at 16.83fps. This jobbie can do it at 98.51fps.

That's not to say the MediaTek isn't a solid bit of kit, but it's aimed at top-end smartphones. Xavier... is an entirely different beast.

This may pose a challenge to those who will design the motherboard and its multi-SoC row, enabling buses between the SoCs with a minimum of bottlenecks and retail price hike. Maybe do provisions for a two-SoC laptop version too? da Vinci Voyager?

Expansion slots for video/audio cards etc. should be PCIe (yeah, drivers..) and there should be two HDMI 2.1a ports and four USB4 ports to support external devices. Since the support for USB in RISC OS is said to be wobbly this can be a chance to get it right. The same goes for HDMI (multi-screen support).

I can't find any reference on USB capabilities for the Dimensity 9200. It's... pretty new.

With this rabid-performance workstation one may expect legacy software to run at more than adequate speed under emulation, but natively written software will do even better.

No shit, Sherlock.

This relies on the development of a brand new SDK including a compiler capable of 64-bi compiling - a given because it's running in a 64-bit system one should think.

So, not just a world class OS but also an SDK and a compiler...?

Microsoft - $1.804T, Google - $1.135T, Apple - $2.450T. That's T for trillion. The most up to date net worth valuations that I could find.
Those are the sorts of companies that could think about making an OS. And an SDK. And all the software to go with it.

Oh, I think Baidu actually did, because China doesn't much like having American corps watching everything citizens do, that's the Chinese government's job. So they made a home-grown OS. Baidu net worth? About $33.16B. Rather less, but we're still in the tens of billions here.

RISC OS Open, by comparison, has assets of about seventy five grand (most recent accounts filing at Companies House). Not billion, not even million. Nowhere near enough to be thinking of this sort of delusion.

If we get RISC OS 64 by and by, this is the sort of hardware we'd expect to see it running on in Q4 2023. Right?

Q4 2023? So... all this is supposed to happen in about eleven months? In comparison, Acorn wanted Arthur written and ready in five months. The initial versions were (17th June 1987), but it took a few more months for the final v1.20 (25th September 1987), and then a further year for RISC OS 2 (5th October 1988), and then three and a half years until RISC OS 3.10 (30th April 1992).
Just to, you know, give an idea of what's involved.

Or, you know, look at Linux. Linus announces his hobby kernel on 25th August 1991. By 1993, over 100 people are working on it. Which means Linus can consider the code mature enough for a 1.0 release in 1994.

Not... eleven months from nothing to shiny goodness. That's utterly ridiculous bordering on clinically insane.

Otherwise, the fastest consumer-level hardware RISC OS 64 could run on is sundry Arm-based RPis and Chromebooks which the fully populated da Vinci would beat hands down on raw performance.

I think the fastest machines it could run on would be using an AMD Ryzen Threadripper Pro. Or are we planning to shoot ourselves in the foot and only target ARM hardware? I mean, it's nearly 2023, surely we could make our imaginary OS be platform agnostic? It isn't impossible, Linux has done it.

Anyway, a separate platform must have custom-built hardware to earn the "platform" designation in full. The da Vinci can ensure this in an innovative way!

What?

Also, having both 64-bit RISC OS and the da Vinci workstation can as implied encourage the RISC OS developers to cooperate on developing a new complete and programmer friendly 64-bit capable SDK/E to take advantage of the new ArmnV9 architecture and its exciting new features. If this happens, it can occasion a true revival for RISC OS. Bring it where it should be, better late than never.

What RISC OS developers? I mean, isn't our marketplace measured in hundreds and active developers measured in tens?
And active developers with real world OS design experience? Probably countable on fingers. And in case anybody is wondering, my screwing around with some 6502 code decades ago does not in any way qualify me for knowing how to handle mutexes for event blocking in multiple threads or any of the other fun stuff that happens inside an OS.

Seriously, people, Andrew Tanenbaum wrote a very good book on the subject, and developed an operating system to demonstrate the principles. There's a PDF of the book on GitHub (probablly illegally), go grab it, read it, all thousand pages, and understand the sheer ridiculousness of what is being asked here.

Last, let's mention that this system a bit modified with a simplified GUI also can be used to build a very-high-performance mass market Gamer Console.

Nobody cares what processor or OS is in a game console. What counts is graphics performance. My old PS2 can handle 38 million polygons/second (lighting), or 16 million/second (bezier curved surface), real world performance 500-650K/frame (at 30fps), or 6.2GFLOPS. That's a 22 year old console.
The PS5 manages 10.3 TFLOPS peak, with a polygon count of about nine billion per second.

There's no benchmark available for the Mediatek chip, however Google suggests comparisons between it and the Snapdragon 888 which manages a mere 1720 GFLOPS. Even if the Mediatek managed to add another 25% to that figure, it would be around the level of the PS4 which is nine years old.

At least the idea of making RISC OS the next best phone OS has been ditched. Perhaps because I pointed out that Microsoft spaffed nine billion dollars up the wall and eventually walked away a failure.

Games consoles? A lot of custom hardware, both for blinding video performance, and also for DRM. This isn't a place we stand to get any traction whatsoever. Want to know the net value of Sony and Nintendo, or have I already pointed out the sheer craziness of this entire idea?

Me? Personally? I'd settle for a Bluetooth chip (already built in!) that actually worked. That I could use to shoot over photos from my phone without the complication of running an ftp server on my phone and using ftpc on RISC OS to access it. There are plenty of things that are possible with RISC OS as it is right now that don't involve ideas such as writing a brand new world class OS from scratch and the SDK to go with it in under a year for hardware that doesn't exist yet.

You know, two hours ago when I sat down to write this, I should have simply said to myself "Don't feed the troll" and just watched something on Netflix instead.
One of these days, I guess I'll learn...

Your comments:

J.G.Harston, 24th November 2022, 00:55

Amongst all that there's one small bit that has some value.  "the GUI/WIMP system, drag & drop everything, middle-click to bring up menu"    As I keep banging on in another realm, first decide what the actual *functionality* it is that you want before rolling up your sleeves and trying to implement cold fusion. Not the implementation, the functionality.    If the aim is "I want Filer windows, a task bar, drag-n-drop, proper three-button mouse actions", then *that* is the task. Not "write RISC OS in C". And "RISC OS Desktop Experience" already exists. I use ROX on Centos Linux. Hell, I even got a decent way into *writing* a "Proper Desktop" for Window 3. But "port RISC OS to another CPU" is a non-starter. Even Microsoft are struggling porting Windows to ARM64, and they have billions of dollars of paid programmers.

David Pilling, 24th November 2022, 03:15

So much negativity. Having watched Win 98 become Win XP I was taken in by the idea of 64 bit RISC OS. The big boys did move from operating systems akin to RISC OS to proper operating systems - by sticking the old OS on top of a proper one (NT or BSD).    It has been an interesting discussion, clearly not going to happen for all the reasons above.    Reminds me that in the final years of Acorn, they talked of a new OS - I can't recall the name - but no one shot them down on some of the above grounds. I wish they had done. Perhaps slightly more plausible in 1996 than 26 years later.

Zerosquare, 24th November 2022, 03:19

As a point of comparison, Windows 3.x was more or less where RISC OS is, i.e.: cooperative multitasking, no memory protection, single-user, single-CPU. When creating Windows 95 and Windows NT, Microsoft did a lot of work to ensure that 1) existing applications kept running, and 2) the source code changes required to turn them into "proper" applications (allowing access to all the new OS features) were minimal.    The amount of work they had to do to achieve this is pretty huge -- if you're interested in technical details, Raymond Chen's "The Old New Thing" blog has fascinating articles about this.    As you said, expecting a bunch of enthusiasts to do the same thing for RiscOS is a pipe dream.

Rick, 24th November 2022, 06:38

While a huge amount of work has gone into keeping 16 bit applications running on 32 bit Windows, they did have the benefit that it was possible to "thunk" the processor between modes, so the applications were binary compatible at hardware level.  We don't even have that luxury.  Which means without a full ARM 32 emulation (another thing to add to the list), *NO* existing software will run.    I don't see it as negativity, I see it as reality. There are very many useful things that could/need to be done with the current setup, and even if there are no more ARM32 devices ever made, we're not exactly stretching the capabilities of existing hardware...

Anon, 24th November 2022, 08:52

Simple answer is to run a *nix kernel (maybe Linux, maybe BSD - NetBSD has been ported to ARM26, ARM32 and I believe the new ARM64 systems) as the underlying OS. Then have a "shim" on top that emulates the RISC OS API, along the lines of ARMulator.    Couple that with a GUI that emulates the look and feel of RO (with emulations of the system calls) and it should be entirely possible to run 'legacy' RO applications on a hypothetical new system... with all the benefits of pre-emption, VM, memory protection, process isolation, multi-user environment etc etc that I can get on my £25 Raspberry Pi if I install Raspian rather than RISC OS.

C Ferris, 24th November 2022, 12:59

A squadron of Spitfire's waiting at the end of runway !

William Black, 6th August 2023, 14:15

As a user and not yet a programmer, all the technical talk of the inside of operating systems means nothing. How it works? Doesn't matter. A bit 1980s? Who cares.    I love the RISC OS GUI, and I love that it is small and quick. I love that it's fun, that evidently you can knock up little apps in BASIC quickly, that it has central apps/formats like !Draw.    I'd be happy to see it made 64bit as-is, then improvements and replacement modules etc produced as and when.    RISC OS ain't competing with Windows or Mac OS. It's competing to be a more widely-used OS on the Raspberry Pi. 'All' it needs to be is 64bit and for development tools to be improved to start attracting the capable and curious - budding programmers looking for something different. It's potential in actual industry is big.    There are some programmers beavering away releasing fantastic programs and updating the OS - they're just cracking on with it and doing what they can and that's brilliant. Others amuse themselves by being negative nancies or letting everyone know what they've developed, then keeping it to themselves. I think it's a British disease to get pleasure out of negativity.    But anyway, greta things can be achieved by few people. Look at what MW Software achieved with ArtWorks and EasiWriter, or what Cerilica achieved with Vantage, despite it's obvious issues. Both one-man shows in terms of programming. Gerph has a simulation of RISC OS in Python, written by himself. There are many more genius programmers coding for RISC OS even now.    RISC OS *can* be made 64bit, and the issues *can* be fixed.

Rick, 6th August 2023, 15:01

The problem is, if one doesn't know at least a little of how RISC OS works internally, and it's dependence on the behaviour of the 26/32 bit ARM processor, one might be led to the impression that making it 64 bit will be "a bit of work but doable" just like how it was brought into the 32 bit realm.    The big problem here is that while the 32 bit ARM looked a LOT like the 26 bit ARM, just with some extra modes and the PSR split off...  ...the 64 bit ARM does not resemble the 32 bit ARM. The available registers are completely different, the processor behaviour is quite different (no conditionals, for example, and no longer any LDM/STM, etc etc) and due to this the instruction encoding is different. In short, 64 bit ARM is nothing like 32 bit ARM.     So, not only will NONE of the OS code work as-is, NONE of the applications will either.    While lone wolves have been the backbone of RISC OS ever since the beginning (hic, you forgot David Pilling!), the sad truth is that the options are either some sort of emulation of a 32 bit world, or a complete ground-up rewrite.    I would *LOVE* to see RISC OS thrive in a 64 bit incarnation, but really, there's no third option.    And, yes, us Brits are born cynics. Negativity and pessimism are a way of life, as is the inequality that likely fuels a lot of it. But that's just how it is. Go put the kettle on, dear, you'll feel better after a nice cuppa... (etc)    [bonus points: look up The Four Yorkshiremen]