Writing an Armv7 to native compiler

There’s one potential avenue for porting RISC OS to either AArch64 or other CPUs that I haven’t seen mentioned here that has been proven by one commercial vendor whose OS I’ve used for many years as a hobbyist, namely OpenVMS.

VMS (“the Open is silent”) was originally VAX/VMS, and DEC came up with a clever way to port an OS that, like RISC OS, was originally primarily written in macro assembler. Rather than binary emulation, the path Apple chose, DEC had for users a binary-to-binary translator called VEST, which did ahead-of-time translation with some runtime emulation of VAX features. But that wasn’t the preferred option, nor what DEC used to port the OS itself.

What DEC did was to write a compiler that translated the VAX MACRO code into native Alpha object files. They had to map the VAX registers to Alpha registers, as well as translate the function call interface from stack-based to register-based argument passing. As a side note, the VMS ABI allows callees to always know how many arguments were passed in the case of varargs calls, info that is almost never available to code that uses C-style varargs (a potential source of bugs and security holes if the format specifiers in your sprintf don’t line up with what’s on the stack).

For those interested in all the gory details of porting an application (not the OS), see: OpenVMS Notes: VAX to Alpha Porting Diaries

DEC had to port an entire suite of “layered products” (DECnet, high-level languages, a SQL server called Rdb that they sold to Oracle, etc.) to RISC, and I’ve always thought that they did an incredible job considering how difficult the task was to move to a totally new and different architecture. But they did it a second time, porting the OS from Alpha to the ill-fated Intel Itanium.

For the gory details of what that transition looked like to VMS devs, see: OpenVMS Notes: Alpha to Itanium Porting Diaries

I happen to have one working HP rx2620 Itanium2 (2 × 1.6 GHz) server (made out of 3 surplus servers I bought years ago for $150 each) that can run the latest OpenVMS quite well, but it’s powered off because of the power consumption and fan noise. It can also run Gentoo Linux and the last Itanium version of Windows Server. If I had the media and licenses, I could run HP-UX on it, but I have no interest in that. None of this matters now because OpenVMS has been ported a third time, to x86.

OpenVMS could easily have just died with the Itanium, with the Alpha version running in emulation on x86 servers for customers who couldn’t migrate their mission-critical apps away, but a group of engineers with DEC/HP/HPE experience acquired the rights from HPE and formed VMS Software Inc. with the goal of continuing to support OpenVMS customers on Itanium and Alpha (they’ve left VAX support to others) while porting the OS, using the same principles as the earlier ports, to run on 64-bit x86. Now the x86 version is finally here and I’ve been too preoccupied with RISC OS to try it out yet. The non-commercial x86 licenses are only just now becoming available, because they had to get native x86 versions of all the compilers so you wouldn’t need to also have an Itanium system like their early commercial adopters had to have.

What VSI did was port their high-level languages to target LLVM instead of their proprietary GEM intermediate language, and have spent the past however many years getting LLVM to understand VMS quirks, such as having 64-bit addresses but only 32-bit size_t, and other fun compatibility issues, such as the argument count I mentioned that the normal ELF x86-64 ABI doesn’t provide but VMS does. Decades ago, when the Itanium port was ongoing, I assumed VMS would never be portable to x86 in this way, because it has fewer registers than Alpha, but AMD’s 64-bit extensions to x86 partially solved that problem.

VSI didn’t have to map all the Itanium registers to x86 since there’s essentially no Itanium assembly-language code written by customers, and they only provided the original VAX MACRO to native code as part of the standard compilers. You could write inline asm for VAX or Alpha in the C/C++ compilers, but not for Itanium. The x86 port is designed primarily to run in virtualization, not on bare hardware. Compiled VAX MACRO code has to spill some of the registers to memory but that aspect probably wasn’t even especially difficult considering the VAX code is being converted into LLVM IR and then into native code.

I know the RISC OS community doesn’t have the financial resources of even the small VSI, much less DEC during their 1990s heyday, but if people are interested in porting the native OS to run on 64-bit ARM, I think the successful transition of an OS originally written largely in BLISS and VAX MACRO to run on a total of three unrelated hardware architectures, all of which are radically different from each other, and two of which had no VAX compatibility built in (e.g. they had to transition from VAX floating-point to IEEE FP plus a compiler flag for VAX FP emulation, which they can do mostly with clever bit shifting in compiler-generated code for Itanium and x86) has a lot of lessons for what’s possible with a lot of hard work.

All roads seem to lead to the importance of LLVM to the future of all RISC OS toolchains. The first step on that road would be to support the unique ABI of RISC OS and support Clang as a cross-compiler. Once that’s working, then someone has to write an ARM assembler front-end, and then you’d be able to recompile the s/ files instead of having to port them all.

I downloaded OpenVMS 9.2 the other day to give it a go, but couldn’t figure out how to get past “connect a serial console now” (I couldn’t find any instructions on how to do such a thing in the version of VMware I was using, despite it being listed as a supported version in the release notes). But this isn’t a VMS help thread so I digress :)

I had no idea that it was “ported” in such a strange way. I knew that it had hopped across architectures a few times, but I assumed that most of it had been C-ified over the years. It’s interesting to learn that that’s apparently not the case, and as you say there are likely to be some interesting lessons there. It’s all a bit over my head though!

Until 2002 my job was VMS support, so I experienced as a customer the VAX to Alpha transition – which was pretty seamless.

I’ve long thought that a similar approach could work for RISC OS, though until I read the above I hadn’t realised quite what had been involved.

I believe there were a few bits of VMS or its bundled applications that couldn’t be converted from source, but where the executable was converted. I can’t remember which they were though.