64 bit nonsense

From https://www.riscosopen.org/forum/forums/5/topics/19380

Asides from “will run on newer boards”, I fail to see any particular upside to going 64 bit that would invalidate the many downsides – lack of compatibility, loss of applications, will need a new API (that will bring with it new bugs), and so on.

Just waving those “let’s go 64 bit” pompoms is pretty much like saying “Get Brexit done”, it’s appealing to some hypothetical goodness while totally ignoring the reasons why it hasn’t already been “done”.

To keep running the current selection of applications on a 64 bit OS, you’ll need some sort of emulator to bash the 32 bit code into something that’ll work on 64 bit. And by doing that, you’ll lose whatever speed advantage that shiny new gives you.

Might as well work with 32 bit and see about pressing those three other cores into doing something. I mean, bringing those online (hand-wavey all the reentrancy issues or the cooperative nature of the Wimp and the other dozen problems that make RISC OS essentially a single process OS) would give a big immediate speed boost. So as you can see, there’s plenty still to do with existing hardware!

Now, let me nail my flag to the wall. If RISC OS goes 64 bit, it’ll be an adventure that I will not be participating in.

Many years ago I pretty much stopped using Windows except for a couple of specific things which is why I still keep an XP box around. My Windows software is no longer maintained.

Likewise, while I’ve had ideas for apps, I have made a conscious choice to not get involved in Android programming at all. It’s simply a browser/camera/media portal. I don’t delve too deeply into Android (as time progresses, Google is making it harder to do anyway).

I never got on with Linux. It seemed like a system that was “so close” but ultimately had too many bugs and quirks. Too many things “almost work” but ultimately fail (special nod to Brasero for completely ignoring a specified write speed and going ahead at the maximum possible speed which the hardware just can’t manage, leading to shiny tea coasters).
Let me qualify this: the underlying system is solid (systemd issues aside). That it is used for servers is a testament to that. However in the user land, especially on the desktop, it seems there are some great apps and an awful lot of half-arsed rubbish that barely works.

I write code, sometimes, for the ESP32 for amusement mostly.

But the system I do most with (that doesn’t involve Netflix or Bored Panda) is RISC OS. I know DeskLib very well (having made a custom fork and all), I know how the OS fits together, and I’m perfectly at home with BASIC, assembler, and C. I know the OS’ quirks, I know most of the API, and have StrongHelp for the bits I forget. And I have a set of applications that mostly work for me. Okay, Zap has bugs and the OS itself is rather fragile, but a reboot is only about 12 seconds away (say about 45 if including connecting to WiFi). My Livebox is an embedded system (based on Linux) and it STILL takes 3-4 minutes to start up.

I was okay with the ESP32 because it is a weird form of C that the Arduino IDE compiles (very slowly!). I don’t have any intention or interest in learning Lua, Python, Perl, or whatever else.

And I don’t have any intention or interest in learning a new processer architecture or OS architecture, API, system calls, blah blah. Plus sorting out a new toolchain to build software and then figuring out if anything of mine could even be sanely ported…

So, sorry, peak RISC OS for me is right here and right now. It’s where I’m going to stay.

I can add my tuppence – and it really is only tuppence – to that.

I’m 74 years old. My Pi4 will probably outlast me, and I’ve got a spare in case it doesn’t. I was, many moons ago, pretty hot (though I say it myself) at 26-bit ARM assembly language. I literally wrote the book on the 32-bit ARM/Thumb2 architecture and UAL assembly language – but haven’t really used it in anger. My Pi4 runs BBC BASIC plenty fast enough for anything I want to write. On one core. Yes, really.

My workhorses now are an M1 Mac Mini, a 2013 (Intel) MacBook Pro our son gave me when he upgraded, and the Pi4. I ditched the last Windoze machine years ago, when the last bit of software I used it for became available on the Mac.

Strangely, or perhaps not so strangely, that doesn’t work on the M1 Mac Mini (it used to on the old Intel Mac Mini, but that died). On the Windoze machine I had SquirlzMorph; on the old Mac Mini I got MorphX. There’s a new version of that which does work on the M1, but it costs, and it looks as though it’s different in ways I don’t really like so I’ve not splashed out on it. I might give it a whirl sometime, or I might write a morphing program to my own ideal spec to run on the Pi. BASIC would be plenty fast enough, I know exactly how to do it – but will I bother? Other things will probably take priority…

MorphX runs on the MacBookPro okay – but the screen’s too small (2880×1800, but only 15.4") for comfort doing things like morphs. I could hook it up to the 43" 4K screen upstairs, but it’s not straightforward (no HDMI connector), and I usually use the MacBook downstairs…

64-bit ARM? Well, the MacMini has it, but if RISCOS would run on it under emulation it would be slower than the Pi4 and have less RAM available. Pfffft.

If anyone’s really interested in what I use each machine for, here’s a list: https://clive.semmens.org.uk/RISCOS/AppsQ.html

Mr. Murray, I’d like to know what’s idiotic about RISC OS taking full advantage of the ARM architecture it was created for. Nearly a quarter of a century has passed with constant development of the ARM architecture, going from 32-bit single-core to 64-bit multi-core being the most significant, a development RISC OS hasn’t followed.

Of course a sand-boxed emulation environment would be totally necessary to enable legacy software as would a new SDK, this is the only way to go since so much time has passed in the meantime. Look and feel can be kept as-is with few changes.

My motivation for harping on this is that RISC OS still is my favorite operating system, and I’d like to think it could survive, attract more users, when going 64-bit. If you think that’s idiotic, you don’t have the survival of RISC OS at heart.

Mr WT

RISC OS was created for a completely different architecture from ARM v8. End of story.

There’s NOTHING about the v8 instruction set that’s the same as the v7 and earlier ARM instruction sets (other than what’s the same as every other CPU instruction set on the planet). The architecture was designed by the same company, and like earlier ARM architectures it’s power efficient – but the instruction sets are COMPLETELY DIFFERENT. Get that into your head, please.

you don’t have the survival of RISC OS at heart

True. I don’t. I like it (albeit for a very limited range of uses), and it’ll almost certainly last my lifetime. My offspring grew up with it, but they’ve lost interest in it. They’re 38 and 36. They both use Macs.

I know the instruction sets have changed. Which makes it necessary to rewrite RISC OS from scratch taking the changes into account, which sounds very complicated with few RISC OS programmers capable of juggling the variables so that look & feel is maintained intact, never mind finding time to do so outside a company setting.

I do begin to feel like Don Quixote here..

Which makes it necessary to rewrite RISC OS from scratch

Why for ARM v8 rather than any other modern architecture? (Well – actually I can think of a reason: that power efficiency issue.) But if you’ve got to rewrite it from scratch it would be better to do it in a high level language, then it’s platform independent (and future-proofed).

I do begin to feel like Don Quixote here..

Precisely so. Don Quixote didn’t have an army either.

I was, many moons ago, pretty hot

Fwoar!
<cough>
Okay, carry on…

I literally wrote the book

A pretty badass boast right there.

On one core. Yes, really.

This. While more speed is always an improvement, it needs to be weighed against the downsides of achieving it.

Mr. Murray, I’d like to know

Clearly you didn’t actually read my message.

taking full advantage of the ARM architecture

And clearly you didn’t learn from the mistakes of the past.

If you think that’s idiotic, you don’t have the survival of RISC OS at heart.

Anna clearly you don’t understand that anything created for another architecture (as was pointed out above, pretty much the only thing ARM32 and ARM64 share is the first three letters of the name) will be a completely different beast to the RISC OS that we know.
Sure, it may look and feel like RISC OS but underneath, by necessity, it will be quite different. And if look and feel is what you are after, it’ll be much simpler to write yet another window manager for Linux and you’ll get the benefit of a much more solid system underpinning it.

the survival of RISC OS at heart.

I’m ambivalent. I’m surprised and pleased that RISC OS became an open source OS, and that it got ported to contemporary hardware in order to offer things that we couldn’t even dream of in Acorn’s tenure. A second chance at life, as it were.
However it is absolutely not anything other than a home computer OS written with the sorts of methodologies and requirements of a mid 80s system. This took Acorn into the RiscPC era, but the cracks were starting to show with Phoebe – what’s the point of multiple processors with an OS that can’t deal with them?

That being said, RISC OS is the Plan B, the quiet little sister sitting in the corner that got on with things while all those flights of fancy (ARX, Galileo ultimately failed).

I suggest that you read https://en.m.wikipedia.org/wiki/Galileo_(operating_system) and note what it says about RISC OS.
Yes, even your beloved Acorn had given up on RISC OS by this stage, for all of the points that we keep trying to hammer into your head.

So the fact that we’re still here talking about the future of RISC OS is a miracle dosed with more than a dash of irony. It’s one of the last of its generation that has remained mostly the same as it was, and honestly it’s had a bloody good run. But don’t write the epitaph just yet. A new 64-bit-only Pi doesn’t mean all the older ones cease to exist. And there’s still so much more that can be done with existing hardware. Look, we’ve just ended up with two WiFi stacks…

but they’ve lost interest in it.

Yes, there are a number of modern experience expectations that are missing from RISC OS that might dissuade new users.
Perhaps better to think about that than waste time with “64 bit yay”?

A pretty badass boast right there.

But literally true, whereas the previous one is open to question.

so that look & feel is maintained intact

So, in fact, you ask for a new OS, written from scratch in C, that will be completely incompatible with current RISC OS applications, with a different API, but a desktop that will keep the legacy of the Wimp, the same approach for software distribution, BBC Basic, etc.

Good news for you: it’s already done. The kernel is Linux (preemptive, multicore, small, rock solid). The Wimp is ROX Desktop. The Basic is the excellent BBC Basic for SDL 2.0. And the emulator for 26/32bit software is RPCEmu.

All if this is available. Call it RISCOS64 if you want, but – for me – such an OS will not be RISC OS. To be RISC OS, I think we need to keep more legacy.

Other problem you seem to ignore: even if written in Basic or C, applications will not magically recompile for a modern system. You can’t go from 32 to 64 like this. You can’t go from CMT to PMT like this and you can’t go to no memory protection to memory protection like this. Most applications will simply break, as Lliam said in his article.

ASM is really not the only problem here. and probably not even the biggest one.

As Rick said, we have a lot to do before, while not ignoring this very long term target. Some kind of SMP support (I would prefer AMP, with tube like interfaces and C/Basic support), some kind of PMT system (a new WIMP2?, with tasks that could be interruptable (PMT) and other that could not (CMT) in the same scheduler?), and some efforts around graphics support (dual screen, graphics acceleration…).

My motivation for harping on this is that RISC OS still is my favorite operating system, and I’d like to think it could survive, attract more users, when going 64-bit.

Good news, ROOL also has plan for this.
So be happy… and wait.

I do begin to feel like Don Quixote here..

Precisely so. Don Quixote didn’t have an army either.

He was a touch short on correctly functioning braincells, too.

He was a touch short on correctly functioning braincells, too.

Shhh! I wasn’t going to mention that… 8~)

Rick, your OS link is broken it should be this OS ref

Just wondering what happened to the source for Galileo

It’s one of the last of its generation that has remained mostly the same as it was, and honestly it’s had a bloody good run.

Exactly. For me, it’s BBC MOS adapted to a 32bit processor. A 8bit operating system with a desktop.

SWT, just imagine if Microsoft kept MS-DOS and Windows 3.11, and just tried to add modern things into that. RISC OS is EXACTLY this. To get modern software as Iris is really like trying to port Firefox under Windows 3.

just imagine if Microsoft kept MS-DOS and Windows 3.11, and just tried to add modern things into that.

They did! They called it Windows 95.

But equally relevant is that when 64bit Windows occurred, they finally dropped all support for 16bit.

They did! They called it Windows 95.

It’s a bit more complex. Windows 95 boots first a 16bit kernel (DOS), then MS-DOS boots a 32bit kernel (Windows).

The interesting point in using MS-DOS as the lowest layer, is that you can use 16bit MS-DOS drivers and Windows 32bit drivers. This is much more efficient than just relying on BIOS drivers.

RISC OS is really DOS (monotask kernel) + Windows 3 (graphical interface without its own kernel).

Nota: this approach is well known at Microsoft. Excel 5.0, for example, did integrate a lot of things that were not present in DOS or Windows 3. Almost a complete OS :)

They did! They called it Windows 95.

…and it was awful and fairly crashy. Finally culminating with the terrible Windows ME. (Ironically, Windows 98SE, the previous version, is about the best one).

But as referenced in that article MS also had Windows NT, which is a decent little OS. (That has since had windows bunged on top.. but still).

It’s a bit more complex. Windows 95 boots first a 16bit kernel (DOS), then MS-DOS boots a 32bit kernel (Windows).

It’s still reliant on DOS though, so you have this weird 2 kernel system. For example, if DOS runs out of conventional memory then you can no-longer start any new applications.

RISC OS is really DOS (monotask kernel) + Windows 3 (graphical interface without its own kernel).

Windows 3 was a bit more than that to be fair, it had it’s own kernel, and drivers, etc etc. The 32bit extensions were the genesis of Windows 95.

I’ve never seen it suggested, but I’ve often wondered if RISC OS’s legacy should be leaned on if you wanted to ‘modernise’ it. Lets be honest it’s MOS with some nice memory trickery to let multiple applications co-exist under the wimp.

But by modern standards it’s tiny.

So why not use RISC OS as a process environment? i.e. have an OS running RISC OS in a VM as the primary desktop. If you could then provide some kind of RISC OS based window server so ‘headless’ applications could talk to the Wimp you could slowly migrate the OS to be merely the presentation layer. I would call this the FRont End Desktop.

All your old stuff would run in this single environment, but new things could take advantage of the underlying OS, and a mechanism to communicate with the ‘primary’ instance could be developed. You could also spin up a cut down version in another VM to allow a single legacy application to run, if you provided enough of a shim to the wimp to allow the application to talk to the primary VM. This could be some kind of Secondary Hosting Environment for Installing Legacy Applications.

(Unfortunately, other than some silly names I’ve not got the skills to write any of this…)

It’s also basically what Apple did with the blue box.

Of course a sand-boxed emulation environment would be totally necessary to enable legacy software

Emulation is a non-starter. Refer to the ARM on ARM thread to understand the complexity required to achieve any kind of performance.

If you read that entire thread, you might start to understand some of the technical challenges involved and why it’s only been done in a limited fashion to date.

Discussing 64bit is somewhat pointless as it will vicariously happen, provided C migration factors it in.

If some kind people could spend a couple of hours finding out how much of an idiot I am by looking through how task states are saved and restored in https://github.com/Simon-Willcocks/SimpleAsPi I would really appreciate it.

There’s no FIQ consideration at the moment, and Undef simply ignores the instruction, so the IRQ, SVC, Data and Prefetch Aborts are the only ways into the kernel.

Prefetch panics, at the moment, so that can safely be ignored.

IRQ always stores the whole task state, with interrupt enabled SVC routines being a special case. Rather than building that into the C kernel, there’s a hook to deal with it, which is used by the Legacy subsystem to store SVC-specific details on the carefully protected legacy SVC stack, to be restored when the task resumes.

The problem is 99% in OSTask/ostask.c

The new family of ARM’s CPU’s, GPUS and DSP’s are so great that RISC OS, it’s WIMP system, could be a very productive platform for creating/editing audio, video and 2/3D grapics both emulated and especially in newly written 64-bit apps. That’s a fact. Which could spawn not too pricey Workstations, Desktops and Laptops.

Can I dream on now?

I’d love it if it were at least possible to deprecate some of the really crusty non-APCS compliant things and add new, compliant ones. I know it seems silly but I feel that oddly implemented SWI interfaces can be a bit of a barrier to porting, and potentially make automation of tools to handle differences between architectures on a source level a hassle with lots of edge cases.

I know it’s also only sort of related but RO is the only way I can easily play with hardware both internal and interfaced with a computer this side of the 80’s. I don’t want to lose the ability to talk to the hardware behind the OS, which could be a risk if fully fledged memory management with memory protection is introduced. It’s an OS for people who love digging into the guts and splashing around.

What’s stopping a 64 bit OS and 32 bit programs running on it. Compliant applications should be doing things via SWIs anyway so it’s probably not that aspect that’s problematic. From the perspective of the simplest straight port from 32 to 64 bit, what are the things that break? And yes I am aware that 32 and 64 bit ARM are different. Assuming everything was rewritten / ported, what major issues would prevent the basic structure of the OS from functioning?

You don’t get to directly mess with PC any more. I’m certainly no expert on ARM64 but this would imply to me that all of the current SWI handler jump tables would fail. In fact, I think RISC OS is the only OS that still uses SWI, given its mixing of code (the SWI instruction) and data (the SWI number) is messy for the caching.
Plus plenty of inherent assumptions, such as BL updating R14… which is now x30.
Etc etc.

Plus, we need to ask ourselves the obvious question – if there’s a new version of the OS (which is a massive if), should it retain all of the historical artefacts (polite word for “mistakes”) or should it attempt to more in line with modern systems?

Yes, it’s cool that you can easily fiddle with stuff behind the OS’ back. But from a security and stability point of view, that’s a large part of the problem. That sort of unfettered access can be used for good…and bad. Likely the only reason no bad has happened is because we’re small fry in the grand scheme of things, and also because the market is so small we all kind of know each other to some degree.

Plus, of course, any potential new version ought to consider the ability to port to other (non-ARM) systems, where the existence of SWI and specific registers won’t be guaranteed. Plus, these days, it would make a lot of sense to take the idea of the shared libraries and bake that sort of thing into the OS. Stuff ported from elsewhere is going to increasingly rely on generic library code. This may indeed be an answer for the new OS for how to replace modules and SWIs… Make the code available as a shared library, perhaps, and clients can just call it in as needed.

.. any new version ought to consider the ability to port to other (non-ARM) systems

Which pretty much forces Paolo Zaino’s proposal for using a virtual machine .

Ho!

I kind of agree with Rick and others. But I still want RISC OS to live on ,especially as a fun system to code for. If someone ever cared I have done a lot with AMP and RISC OS. Running paralell systems , with RISC OS as base and the other way.

My most recent project based on the Genode OS Framework gives a lot of fun and useful possibilities. There is nothing that stops it from running Genode apps in RISC OS and RISC OS apps on Genode.. The apps will simpply still run on respective cpu , but can be displayed and interacted with on the other.

Ofcourse this relies on a 32bit capable core. I have done bare metal emulation and it isn’t impossible to do that in other contexts.

As I stated I agree with Rick. But , I can think of a future system that explores new ways of RISC OS computing. I think that it will not be RISC OS exactly but will still be something like it.

Both RISC OS classic ( the current system ) and the next generation system can live side by side. Maybe the new system can act a bit like Genode does for me now or will in the future.

I also like Paolo’s UltimaVM. It will ease integration between running systems.

I welcome every new development , being my hacks , ROOL doing 64bit classic RISC OS, regular emulators, virtualisations on arm and others.

But! We need something to hold together. There aren’t that many devs around to allow splitting eveything. In the end it is all about giving RISC OS a good and reliable home. This means that we need to respect each other and share ideas and code. I think that Paolo’s GitHub initiative is great. I am not using his software but the fact that sourcecode is living in public is necesary for our mutual future. I have started to put as much as I can on my GitHub. I pushed the Genode part of my paralell system stuff a couple of days ago. It is really bad code in some ways and and smart at the same time. It is also strictly tied to the iMX8MQ SoC. I hope to find a way to get this to run on other SoCs like RK3588.

This part of the forums is for random stuff, so I will not excuse myself when ranting :)

https://genodians.org/mickenx/2024-08-15-genode-and-riscos-demo

( I need to remove the “company” reference. I am not part of ROD , and only OWB has some connections with ROD )

“You don’t get to directly mess with PC any more. I’m certainly no expert on ARM64 but this would imply to me that all of the current SWI handler jump tables would fail”

ARM64 has surprised me around how much they did keep of ARM32, albeit ‘hidden’ in some ways, or distributed amongst other instructions (CMP technically doesn’t exist anymore, but it just does a SUBS, and dumps the result to the zero register, so CMP is now an ‘assembler alias officially specified in the ARM ARM’.

Another is PC – we actually can mess around with it as much as we could in ARM32 (adding an extra instruction/ cycle though)

BL does, as you noted, use X30;

The ‘RET’ command copies X30 back into the PC, so performs the same function as MOV PC,R14. There is also an ERET instruction that can be used for exception return (similar to MOVS PC,R14);

RET can be typed as just ‘RET’, or a register can be specified. I always type RET X30 for normal returns, but you can specify any register there, so you can set the PC to an arbitrary value! (but … the CPU would prefer you keep ret for ‘subroutine return’ only) (because RET also supplies a CPU ‘hint’ that this is a subroutine return)

There is also BR – and you can specify any register with an arbitrary value. And also BLR, which does a branch-link to a register address, setting X30 to return.

Overall, you can’t LDR directly into PC, and can’t add / subtract from PC, but you can still set the PC to anything you like, at any time. So for jump tables, an example would be

ADR X4,AJ ; jump table
LDR W28,[X4,X10,LSL#2] ; load offset from (32-bit) jump table to save memory!
ADD X28,X4,W28,SXTW ; X28 is where we want to go
BR X28 ; go there!
AJ:
.long functionlabel01 – AJ
.long functionlabel02 – AJ

There is a dedicated ADR instruction in ARM64, and as it is dedicated, it has many more bits available, so you can now ADR something with a +/-1MB range, so the Bad Address Offset has been banished for the most part!

(I of course prefer ARM32)

Michael – that looks very interesting! :)