Porting OpenVMS from VAX to Alpha AXP (1992) [pdf]
hpl.hp.com
hpl.hp.com
I sat next to a guy who worked on something called Jacket & Tie. I don't remember which was which, but the essence of this was to compile VAX32->Alpha assembly, then run that on a big ass VAX (an 8000? It's been a while) that had loadable microcode(!) enabling it to emulate a very very slow Alpha. I think I recall hearing that the first successful boot to login prompt took ~24h on this hardware.
I ported the RAD50 6-bit character set library (so you could handle 6 characters in a 36 bit word file produced by ancient TOPS20 boxes from the Marlboro Computing Company), written in the even deeper past by my then boss when he had been a whippersnapper. It was in PL1 I think.
I ported (i.e. changed the build files to target Alpha rather than VAX32) the badblock utility, and tested it with an Alpha work station, a SCSI floppy drive, a box full of unused 3 1/2 disks, and a paperclip to scratch the surface of each one before initializing it.
I had some madly brilliant colleagues who ported millions of lines of hand-tuned VAX32 assembly, a boatload of BLISS32, and oddments of other languages.
I used to have a numbered super-secret copy of the project plan but I think it went in the dumpster decades ago.
I had a terrible time, and left with my self-confidence shattered having spent several years achieving not much, but watched some astoundingly competent colleagues do amazing things at a time when Intel's chips were topping out at 33MHz and Alphas were planned for 1GHz. I wish I had made more use of my time there, but boy, I'm glad I got to see some really top notch engineers at play.
Similar process was in use during transition to IA and probably to x86-64 now.
Pure magic, indeed!
This might be the ancient ancestor of the technology that Apple uses to run x86 binaries on their M1 ARM-based chips.
Surely such an ancestor would be based on Apple's 68k->PPC transition in the mid-90s or its PPC->x64 transition in the 00s.
Do you not think Apple looked at the prior art before writing that translator? Of course they did.
"Great artists steal" -- indeed they do.
https://en.m.wikipedia.org/wiki/Rosetta_(software)
https://en.m.wikipedia.org/wiki/Intel_Binary_Compatibility_S...
I really wish they had done PA-RISC. I still have some orphaned software on that platform.
It looks like Rosetta emerged from Quick Transit, and was eventually borged into IBM.
"ULTRIX MIPS Translation The translator that converts ULTRIX MIPS programs to DEC OSF/1 AXP programs is called mx. The mx project started after VEST was functional, and we took advantage of the VEST common code base for much of the analysis and Alpha AXP code assembly phases of the translator. In fact, about half of the code in mx is compiled from the same source files as those used for VEST, with some architectural specifics supplied by different include files. The C+ + language has proven quite valuable in this regard. "
What is notable about their Itanium efforts is that they chose to use ELF and DWARF and their object file and debugging formats. I think that this was actually quite important as it made it far easier for the x86 port: LLVM has robust support for ELF & DWARF.
I think another thing which helped is that they wrote more of OpenVMS in C which avoided the need for an x86 PL/I compiler, etc.
We ported Samba and implemented a lot of C runtime functions to make porting less intrusive. As part of porting Samba to VMS, I made the early port of CVS client and streamline merging upstream changes with our VMS specific changes.
Some of the most infamous 4 letter words we cussed all time was the missing 'fork' and 'fcntl' and all the work arounds we had to put in to get Samba working...
I did meet quite a few very competent engineers from DEC times as part of my work and also interacted with David Butenhof of POSIX threads fame when debugging a thread library he and their team had developed and was used by ASV.
We had one VAX machine left in the company and it was apparently the only thing that could talk to both the Unix machines and these "it'll-never-catch-on" Windows PCs. I don't remember "porting" anything but I do remember installing DECnet onto PCs and a 1.something version of samba on the alphas so we could switch that aging beast off. Next upgrade was to 10-base-2 networking so all the computers would be on the same network.
Also, it's amazing to see an HP URL that works!
The exciting news in this space is that the x86 port of OpenVMS is coming along nicely. While I’ve not used VMS in production (apart from a few days at an, ahem, large British telco, where we had to track down a retiree), I’ve always been fond of it and have an Alphastation at home. VSI are also providing the hobbyist license for OpenVMS for Itanium, Alpha and soon x86. After some concern last year that it would go away it’s nice to see them doing this [2].
[1] https://vmssoftware.com/ [2] https://vmssoftware.com/community/community-license/
[Edit: typo]
I've never missed a simple system so much. The impact on EVERY professional (not just tech / accounting / it / billing) of this switch was a monumental disaster.
The old system just worked. Even better, it was very focused on key data points (aka efficient).
The new system was so complicated - to login you needed to get through a weird web based VPN, then a second VPN thing for the platform, then login to the system. All on 30 day password rotation (three passwords to get in) and impossible to get hardware tokens. All on an old version of IE and Java (yes, constant java popups asking to update). We had to downgrade machines to allow for connections.
And the new system had been designed obviously by committee, so endless repetitive questions that were variants on each other. Literally 10's to 100's of additional fields to enter. Race, national origin, ethnicity (some staff and even participants don't know how these are all different!). I've never seen more money spent for more frustration (I ended up leaving the space entirely).
By the end of the implementation I absolutely missed our green screen system - all keyboard driven (so FAST even on older machines), a single VPN and then a login to connect (we ran latest Windows but had a terminal emulator connection to the green screen - think Putty style).
The authors are not attributed at the beginning of the article, but they are all named at the end.
The OpenVMS porting article is indeed part of the Alpha AXP Architecture and Systems Special Edition, DTJ Volume 4 No.4 (1992).