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.
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
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.
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)
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
> 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.
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.
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.
Not a single useful thing? A complete waste of time? Really not anything that you found intriguing or thought-provoking for its own sake? I did the same course nine years later and found it very stimulating, even if it wasn't always directly "applicable" so to speak. But perhaps the syllabus had changed a bit by then.
What I learned from these comments sharing their experiences from one time to another is that the curriculum evolved and no one had the same experience.
Not to mention how individuals perceive things - two students with similar aptitude in the same class can still have their own very different experiences.
Still a strong presence in 98-01 but also lots of functional programming, algorithms and complexity and the tail end of the parallel research boom. I loved it.
StrongARM was DEC originally then developed into XScale at Intel when they acquired that division from Digital as part of a lawsuit settlement I believe.
The funny thing about the ARM performance/watts thing is that it wasn't originally a design goal except for the need to use a plastic rather than ceramic package to save money. They were aiming for 1 watt but ended up at 0.1 watt!
pedantic comment but the screenshot of Elite on that site is of the original BBC Micro version, not the Spectrum version (which was a technical marvel in its own right)
reply