[jlarcombe]

Don't think Pi 5 can run 'supervisor code' (in old ARM language) in 32-bit mode, so RISC OS surely won't run. The bulk of it is written in assembler so reworking it to AArch64 would be an epic task. Probably take no longer to rewrite those bits in a higher-level language, for much of it.

[skissane]

DEC had a similar problem when porting VMS from VAX to Alpha - significant chunks of it were written in VAX assembly.

They came up with a rather ingenious solution - a compiler from VAX assembly to Alpha. And that was carried forward into the Itanium and now x86-64 ports, so even latest OpenVMS for x86-64 still contains some VAX assembly code, but it is compiled into LLVM IR and then the LLVM backend converts it to x86-64 ELF binaries.

No reason in principle why someone could not do the same thing with the 32-bit ARM assembly code in RISC OS. Likely would be easier than rewriting it all in a high-level language

[eftpotrm]

HP did the same when migrating away from the PA RISC architecture.

IIRC as part of their testing they set it up so it would ingest, recompile and output code for the same architecture, and found that it could produce speed improvements due to context awareness.

[sillywalk]

> recompile and output code for the same architecture, and found that it could produce speed improvements due to context awareness.

That sounds like HP's Dynamo.

https://dl.acm.org/doi/pdf/10.1145/358438.349303

[eftpotrm]

That's it! Thanks :-)

[panick21_]

Actually, there was just an amazing talk on the subject of Porting VMS, to Alpha, Itanium and x86:

https://www.youtube.com/watch?v=h674yxjrjSM

[chasil]

IIRC there was "macro32" which could compile VAX machine code to Alpha, and also VEST, which was a virtual machine.

I've used neither.

[skissane]

Yes “MACRO-32” [0] is what I’m talking about and is still around - from Alpha it was ported to Itanium and now x86-64. Although to clarify, my understanding is it doesn’t take machine code as input, rather macro assembler source code - although I suppose you could use a disassembler to turn your VAX binary into assembler source and then try compiling it with MACRO-32.

VEST wasn’t actually a VM per se, it was a static binary translator - read in an OpenVMS VAX executable, write out an OpenVMS Alpha executable. VEST was only ever available for Alpha, but HP then created AEST which could do the same thing to translate Alpha executables to Itanium-and you could use VEST then AEST in sequence to port a VAX executable to Itanium.

However, VSI have said they have no plans to create an “IEST” to port Itanium executables to x86-64. I believe they face two big difficulties: (a) Itanium is a very complex and non-traditional architecture which makes binary translating it more of a challenge than it would be for a more mainstream architecture (b) legal risk due to aspects of it being covered by Intel patents (and unclear if Intel would license those patents on terms which would make an “IEST” commercially viable)

[0] https://en.m.wikipedia.org/wiki/VAX_MACRO

[sillywalk]

Tandem used something similar called The Accelerator to translate binaries from their proprietary CISC chips to MIPS, including parts of the NonStop operating system.

See Tandem Systems Review, Volume 8 Number 1 - Spring 1992

[lproven]

> Don't think Pi 5 can run 'supervisor code' (in old ARM language) in 32-bit mode, so RISC OS surely won't run.

The RISC OS folks are well aware of the issue.

There are discussions about what to do underway.

One idea that I sort of like is a tiny sort of hypervisor in Arm64 code, that runs an Arm32 "VM". Then RISC OS executes in the VM.

It's not fully native, no, but with the speeds involved, it would be usable.

There is a lot of prior art for this approach:

1. RISC OS already faced a 24-bit to 32-bit migration, and one bit of the legacy of that is an emulator for running 24-bit RISC OS apps on 32-bit RISC OS, called Aemulor.

https://en.wikipedia.org/wiki/Aemulor

2. There is of course a whole industry running x86 PC emulators on x86 PCs. The one that started it is called VMware and it did quite well.

But others copied it: e.g. Connectix ported VirtualPC from Classic PowerPC MacOS to Windows. I interviewed the company's founder and chief scientist Jonathan Garber.

https://en.wikipedia.org/wiki/Webcam#Early_development_(earl...

At that time, x86 didn't do hardware virtualisation. So, VMware just used a software emulation for ring 0 code. Garber told me that once he saw how VMware did it, he realised Connectix could do that, too. He then told that it was much easier than running x86 code on PowerPC. With a grin he said that it was not only easier, the performance was excellent: the instruction sets were a _really_ close match. ;-) So the emulator was very nearly achieving 1:1 code density: one instruction for one emulated operation.

3. When Apple moved Classic MacOS from 680x0 to PowerPC, it did it using a tiny "nanokernel" containing a 68K-to-POWER ISA emulator.

https://en.wikipedia.org/wiki/Mac_OS_nanokernel

[jlarcombe]

yes, surely a good approach, and as you say the performance is likely to be fine given the vast increase in raw speed since the old days...