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

Anyway, with the current state of RISC OS, you’d first need to get an idea what will have to change to make RISC OS happy on 64bit ARM. Then, you’d need an automatic translation approach for the ASM stuff – rewriting everything in C is a nice idea, but I fear the lack of competent developers will make this unlikely to happen. The problem with the “auto translation” approach is that you need experts on both 32bit ARM and 64bit ARM, with a good understanding of RISC OS thrown in. A big task.

This is why my naive idea is that you could automatically translate the assembler into C and then recompile it with optimisations for 64 bit ARM. Arithmetic operations, SWIs and function calls should all translate easily to C but I suppose it’s hard to know what to do with memory addresses, to know whether they’re just jumps within the code or to external code, accessing storage that could safely be turned into an array, or actually addresses of hardware devices or a particular region of the OS’s memory. Is this idea unrealistic?

I’ve had a little experience in automatic translation (though not enough to make me an expert by any means). Visual Basic to VB .Net, and (a somewhat different thing) VHDL generated by a visual state machine design application.

One problem is that the resulting generated code can be difficult to maintain. It isn’t like code that human beings would write. So you may well find that it’s useful once, but considerably less useful in the long term.

One problem is that the resulting generated code can be difficult to maintain.

Similar experience for me, in the past with ARM ASM to x86 ASM automatic translation.

So, one possible way is Binary Translation (at installation OR runtime and just for runtime). This would mean translating AArch32 binaries into AArch64 as well as emulating the 32bit API (somehow and not in 32bit mode, in this case emulating means “preserve the form”). This is what is being done already for AArch32 to AArch64, so it’s proven to be working. (Of course on RISC OS it may be different, but as a principle it works).

The third option is to continue using Virtual Risc PC.

Erm, that should actually be option 2:

2. Create a 64bit emulator for a generic 32-bit platform and run the OS and applications in that emulator.

Unless you want to pay Aaron to rewrite VRPC as an ARM64 ↔ ARM32 build.¹
Or were you just thinking ditch the ARM and join the Intel crowd?

Do bear in mind that VRPC is just emulating a 25+ year old unit with what even niche fans² regard as historical niche status.

¹ The logical, future proof (to an extent) emulation of an RPC is actually RPCEmu – the source is freely available, unlike VRPC, so other emulations are possible if someone has time and talent.

Perhaps it would be better to rewite the simpler apps in BASIC rather than c to future proof them.

BASIC being easily portable to 64bit, of course, seeing as how it’s written in a nice, easy to maintain… oh.

BASIC being easily portable to 64bit,

I was not thinking it would be easy, just one of the essential steps if RISC OS was ported to 64 bit.

While I understand and appreciate much of what is being written here, and have a great deal of nostalgia for ARM and RISCOS – RISCOS without BBC BASIC, !Draw, and ideally !Zap, is completely pointless for me. Everything else I want to do I can do at least as well on another platform, and remain compatible with the rest of the world.

I’ve already lost the International Keyboard Handler Generator (IKHG) which was one of RISCOS’s great assets from my POV; and I no longer feel any need to write in assembler, because BASIC programs run so much faster than they used to.

I suspect a Pi4 (which I don’t even have yet) may be my last RISCOS machine; whether any future machine will be ARM based or not makes little difference to me, absent RISCOS.

BBC BASIC on another architecture? It’d be great for me, but for how many others? And obviously not a “porting” job; it’d need rewriting from a spec – really a reverse engineering job. That applies as much to 64-bit ARM as any other architecture. And then there’s all the WIMP stuff in any app written in BBC BASIC – that’s not going to work on anything but RISCOS.

RISCOS without BBC BASIC, !Draw, and ideally !Zap, is completely pointless for me

I agree completely, and would add Impression to the list.

And then there’s all the WIMP stuff in any app written in BBC BASIC – that’s not going to work on anything but RISCOS.

I did manage to convert

That’s the crunch. You can’t simply run the app without rewriting large chunks of it. You want the RISCOS WIMP…

You want the RISCOS WIMP…

I’m unclear why 64-bit means “no WIMP”, though? If you’re going to the trouble of porting the OS, you wouldn’t leave bits behind.

Sorry, perhaps I was a bit unclear what I was discussing: I was thinking about having BBC BASIC (and !Draw) but not the whole OS. The thing being that I can just about get my head around how BBC BASIC and !Draw could be reverse engineered*, but the whole OS is way beyond my imagination.

Of course I’d love to have BBC BASIC, !Draw, !Zap and the whole OS!

* Not, I hasten to add, that I could do it myself, since the only languages I’m really competent in are BBC BASIC and ARM Assembler – and a few ancient ones, now very rusty, like PDP8 assembler, 3790 assembler, COBOL & Fortran IV.

Unless you want to pay Aaron to rewrite VRPC as an ARM64 ↔ ARM32 build

I suppose I really should have added “with a 26-bit add-on at the side” so that all the (current) legacy applications work for another 20 years or so.
On that thought – how many regularly used 26-bit applications are currently kept alive by Aemulor?

Maybe, if the source is available, a machine translation could do 99% of the work.

I’ll believe it when I see it. Certainly, no such automatic translation is helping with Impression. It’s taking long time because it’s being done by hand.
Oh, and the moment anybody does anything ‘clever’, automatic translation would implode. Again, observe Impression. ;-)

the 64bit ARM should be a lot faster,

Which is why it’s most likely that our future reality is likely to be a 32 bit emulation. Especially if the emulator stops trying to be something (like an A310 or a RiscPC) and concentrates on being a 32 bit world emulation and passing a lot of the other stuff up to the host (video, for example, can be “what the host has” rather than “a VIDC2”).

you’d first need to get an idea what will have to change to make RISC OS happy on 64bit ARM

Everything.

No, seriously. Registers aren’t Rx, there’s more of them (though we could ignore those in the beginning) and they’re 64 bit (obviously!), there’s no conditional execution as we’re used to it, and I think there is a lot less “stuff that sets processor flags” because of this. No STM/LDM, you can only load/store pairs of registers at most. PC is not directly accessible like it is in ARM32 – so your ADDCC PC, PC, Rx, LSL #2 jump table is not going to look like that.

I saw it written somewhere: ARM64 is much more similar to ARM 32-bit than it is to x86.
That somebody even made such a comparison should tell you how different it is to ARM32.

The ARM64 whitepaper gives this as an example:

  if (x == 0)
    y = y + 1;
  else
    y = y - 1;

Which in the ARM we all know, is easily:

  CMP   R0, #0
  ADDEQ R1, R1, #1
  SUBNE R1, R1, #1

In ARM64, it would be:

  CMP   W0, #0
  SUB   W2, W1, #1
  CSINC W1, W2, W1, NE

On the topic of automatic conversion, note that such a simple thing now uses an additional register.

AAPCS defines X0-X7 as parameters to functions, and X9-X15 being the corruptible ones. LR is X30. It’s not directly compatible with the ARM32 APCS. I’ve already mentioned PC isn’t directly accessible. Neither is SP.

Luckily there’s a platform specific register (PR or X18) which could be used as an environment pointer for C (because, let’s face it, it’s likely that a rewrite to C is more viable than trying to convert assembly to assembly).

I’ll leave somebody like Jeffrey (who knows what he’s talking about) to fill in blanks if he feels like it. I’m just reading forum posts and various ARM PDFs and thinking that converting an operating system isn’t going to be a case of search-and-replace register names, it’s going to be a ground-up rewrite.

The third option is to continue using Virtual Risc PC.

An emulation of a quarter century old machine…?
Even in our messed up timescale where 2012 is “yesterday”, that can hardly be called progress.
[I’m not insulting the emulator itself, I’m insulting the fact that it’s a RiscPC]

It isn’t like code that human beings would write.

Sort of like what CFront does to C++ in order that the compiler can build it? ;-)

Be honest, we’re niche computer fans.

English is amusing. There are several ways to interpret “niche computer fans”.

Everything else I want to do I can do at least as well on another platform, and remain compatible with the rest of the world.

This. Losing what makes RISC OS special is losing RISC OS.

I’ve already lost the International Keyboard Handler Generator (IKHG) which was one of RISCOS’s great assets from my POV;

Is this because it’s 26 bit, or because the underlying system has changed?

and I no longer feel any need to write in assembler, because BASIC programs run so much faster than they used to.

This too. As the guy who wrote assembler tutorials, I’d advise NOT using assembler.

Of course, in hindsight, one can also point out that a higher level language can be recompiled, while assembler is extremely sensitive to changes in ARM behaviour.
ARM is not x86, it doesn’t carry any torch for backwards compatibility.

BBC BASIC on another architecture? It’d be great for me, but for how many others?

It’s not just BASIC (if I really wanted something that could run BASIC, there’s Brandy). It’s the behaviour as a whole. The way the filer works (I hate how Windows/Linux does it). The ease of draggy-droppy directly between apps. Pop-up menus rather than stupid menu bars. Consistent copy-or-move behaviour. A filing system that isn’t so ass-backwards that MyDoc.txt and mydoc.txt are two different files. And, to be honest, as much as it’s a pain in the ass dealing with RISC OS filetype metadata on other platforms, I view this as a limitation of the other platforms that are only capable of giving files “types” by suffixing stuff to the filename.
There’s more, but you get the point. RISC OS is nice to use. Other systems range from “tolerable” to “I want to sink a mallet through this piece of….”.
Android, for example, does some stuff well. And it does other stuff so terribly you wonder why they bothered. Oh, and having used iOS6 and iOS7, I can say that the same applies there, only iOS feels a lot more anal about things, like obsessing over trivia to miss the big picture.

but the whole OS is way beyond my imagination.

Let me ask you a zen question: does RISC OS have to be RISC OS if it behaves like RISC OS?

If it starts up, enters a desktop that looks like the desktop, and has a friendly little command line when you press F12 (or ^F12 for a multitasking one), it could be written in Lua…. as long as it behaves the same way.

and a few ancient ones, now very rusty, like PDP8 assembler, 3790 assembler, COBOL & Fortran IV.

You speak COBOL and Fortran IV? Why aren’t you making megabucks keeping those ancient banking systems limping along on their crutches?

how many regularly used 26-bit applications are currently kept alive by Aemulor?

Honestly, for me it’s more a curiosity than something I depend upon. Adrian kindly made Aemulor available recently. I made the transition to the 32 bit world many years before that, so I just got used to having left some of the old things behind.

I have an old ArtWorks that runs, and I’d like to have 1stWord+ but tha crashes Aemulor. That said, my version has been messed with a lot back in time (I don’t remember doing any of that) so I don’t know if that could be a factor.
And… uh… FCFS stiffs the machine (I’d imagine it’s a bit too low level for Aemulor), and, that’s about it. I’ve tried ArmBBS (works) and ARCbbs (unstable) but not for serious use.

My important ones (OvationPro, Zap, and the crap I write) run natively.

you’d first need to get an idea what will have to change to make RISC OS happy on 64bit ARM

Everything.

Yes, related to the basics of the ASM code, that’s clear. It operates completely different, philosophically and physically.

What I was referring to is more the “basics” of a 64bit RISC OS. How does a typical memory map of a 64bit OS look like? How big would an application memory slot look like? Do we want to have something similar to an RMA? And modules? Will we still have something like SWIs? I read that Linux uses SWIs in a completely different way than RISC OS on AArch32. What does Linux use on AArch64?

You see, I am completely clueless. As a Java person, I leave all such details to the JVM :-)

On that thought – how many regularly used 26-bit applications are currently kept alive by Aemulor?

Many users have their few indispensible apps that they need Aemulor for, but I guess in the grand scheme of things, it’s only Impression and Eureka.

@Rick

Which in the ARM we all know, is easily:

  if (x == 0)
    y = y + 1;
  else
    y = y - 1;

Sorry Rick… just my 0.5c, but my approach to that example in ARM64 would be:

        ldr w0, <source>; in case your Y was defined in C and as an int then replace <source> with something like [sp, 12] for example
        cmp w0, #0
        bne .YCASE2     ; jump to YCASE2 if y != 0
        add w0, w0, #1  ; y= y + 1 (or in C y++)
        str w0, <source>; <source> as defined at the top
        b   .DONE
.YCASE2
        sub w0, w0, #1  ; Now this is the y-- and just because it would be executed if y != 0 (aka no jump)
        str w0, <source>; just store it back in whatever is your <source>
.DONE
        ; whatever here...

Anyway not wanting to start an ASM war, as you pointed out very well, we should stop using ASM on RISC OS, full stop.

There’s more, but you get the point. RISC OS is nice to use. Other systems range from “tolerable” to “I want to sink a mallet through this piece of….”.

This, doubled and redoubled in No Trumps. Mac is tolerable – just about. That other alleged system…the less said the better. Linux et al are too much trouble for my way of thought.

Why aren’t you making megabucks keeping those ancient banking systems limping along on their crutches?

Because mental health matters more to me than mere megabucks.

“Now very rusty” may also be relevant. I used to speak COBOL and Fortran IV, forty-odd years ago…

Is this because it’s 26 bit, or because the underlying system has changed?

Dunno. Probably the former, but could be something to do with the move to USB keyboard. Worked on RiscPC, doesn’t work on Pi. I’ve never used Aemulor, dunno whether it works there.

all future Cortex-A “big” cores will only support 64-bit”

You could actually consider this good news as it means we have a known base of CPU to support. One of ARM’s biggest flaws is the constantly moving instruction set and “implementation defined” instructions. Just look at all the modifications we’ve had to make across the Pi range due to the changing instruction set.

Of course this does not mean 32bit is going to be unavailable, just that ARM themselves are deprecating the instruction set; in the same way you can still get 8bit CPU’s, 32bit CPU’s will still be around for many, many years to come.

Although the ARM instruction started essentially as something targeted at programmers, the IT industry moved to high level languages long ago and ARM64 is targeted exclusively at compilers and the direction ARM need to focus on, so a sensible move.

The downside obviously is where Pi foundation moves; if they move to a 64bit only CPU and drop all 32bit models, we no longer have cheap readily available SoC to run RISCOS on that can be purchased new. That said, there are millions of Pi’s out there, so I don’t think the eBay supply will run out within my lifetime.

it means we have a known base of CPU to support

But it’s so different from earlier ARMs that RISCOS would need to be completely rewritten for it; while you’re doing that why not rewrite it in C and compile it – then it doesn’t matter a hoot what CPU it runs on. If the Pi foundation gives us a cheap ARM, fine, but whatever we can get would be equally fine.

I don’t underestimate the task of rewriting RISCOS in C – but I doubt it’s any worse than trying to rewrite it in 64-bit ARM assembler.

Dunno. Probably the former

I seem to recall looking at IKHG just to see what it did (never having looked any time in previous years/decades)
As I recall it crashed because of 26bit items.
I did have a poke around but life distracted me.

Hey Rick, I know you love the keyboard handling stuff. I wonder if a modernised re-write could be done. :)

Especially if the emulator stops trying to be something (like an A310 or a RiscPC) and concentrates on being a 32 bit world emulation and passing a lot of the other stuff up to the host (video, for example, can be “what the host has” rather than “a VIDC2”).

As I said “generic 32 bit”

English is amusing.

Oh, definitely. That’s why I like it. It also happens to be my native (and almost only) language.

There are several ways to interpret “niche computer fans”.

I know, and I meant both the obvious fans of niche computers and especially the niche fans of computers or in this case niche fans of niche computers :)

Here’s a question… I wonder how many RISC OS folks care about it running bare-metal? Doing so brings a lot of driver and porting hassles, and I don’t see an enormous gain from it. It benefits from a certain amount of simplicity (RISC OS Pico), but not that simple because you still need to drag in big driver stacks for things like USB.

So I might suggest slipping a lightweight virtualisation layer underneath. That would preserve most of the user-facing things people like about RISC OS, and most of the system-level things too.

My roadmap for doing so would be to use QEMU/KVM, because it has quite good cross-architecture support. So it would need a port to a generic platform supported by QEMU – plenty to choose from so pick whatever’s simple, best-supported and with decent performance (eg VirtIO hardware rather than complicated emulated devices). That’s of a similar amount of work as the other ports (ie not insignificant, but not to the scale of rewriting everything in C).

On aarch32 hardware you can run this on top of KVM so you get near-native performance. On aarch64 you have to use QEMU’s instruction set recompiling, which has an overhead but at least you can still run things. The advantage is you can then run RISC OS on any board that has a Linux kernel, so you don’t need to worry about porting details (documentation, etc). While you have a Linux kernel on the metal, you don’t necessarily need a userland Linux distro – it can be as slimmed down as you like.

You can also run on x86 as well, of course. The difference compared with VRPC and RPCEmu is that you’re running a model of a modern machine, not one constrained by 1990s limits (256MiB RAM, etc), and one which somebody else maintains. So all the stuff like networking, storage, I/O, management GUIs, etc already works.

Since the QEMU backend would be just another RISC OS port, other ports are free to run on suitable aarch32 metal as long as that exists.

QEMU/KVM won’t keep us bare-metal hackers happy, but I suspect we’re in the minority…

Could FPGAs help us? Something like: https://hackaday.com/2018/10/02/free-arm-cores-for-xilinx-fpgas/ ? Or is the performance drop to large even if you are using a high end FPGA?

I seem to remember talk of FPGAs with early ARM cores on them…I wonder if anyone’s still doing them? I don’t think later ARM cores lend themselves to this application so well, perhaps there are even still 26-bit cores on production FPGAs?

No, probably not 8~(