Hacker News new | past | comments | ask | show | jobs | submit login
Porting OpenVMS from VAX to Alpha AXP (1992) [pdf] (hp.com)
45 points by todsacerdoti 21 days ago | hide | past | favorite | 15 comments

Hah. I have memories of being a grad hire working on this project - mostly to fetch tea and follow the directions of my betters - but still, it was an impressive thing to see.

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.

For the end-users the transition from VAX to Alpha rhymed with VEST, which was a command-line utility to produce an Alpha native binary from its VAX original binary. When successful, such image was considererd VESTed. In some (lucky) mismanaged cases this would be the only way forward in absence of the original source code.

Similar process was in use during transition to IA and probably to x86-64 now.

Pure magic, indeed!

I thought it was called mx. Turns out that there was one called 'mx' and it was based on the VEST codebase and was for Ultrix binaries.

"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. "

I think an awful lot of the user-space utilities were VESTed, I'm thinking about EDT and TPU and who knows what else?

This might be the ancient ancestor of the technology that Apple uses to run x86 binaries on their M1 ARM-based chips.

> 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.

Apple used Rosetta. I remember a version of Rosetta that was advertised to run SPARC/Solaris binaries on x86 under some sort of iBCS.



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.


Please don't call me Shirley!

Do you not think Apple looked at the prior art before writing that translator? Of course they did.

"Great artists steal" -- indeed they do.

There is this great document (http://www.decus.de/events/alphamigration/vortraege/porting_...) which details the efforts to go from Alpha to Itanium.

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.

I lead a team to implement CIFS server in VMS on Itanium after deciding not to port ASV (Advanced Server - CIFS server for Alpha since it had a lot of hand tuned assembly for a specific architecture).

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.

My first work computer was a £20,0000 alphastation but the employer was a (10yo) "startup" so the desk was a cheap door on two sawhorses in a converted stables. The desk/door gave me wrist splinters. A good PC might have 16mb and be a 486DX.

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.

It's always interesting to see how they solved problems in the '90s that people still don't seem to get today.

Also, it's amazing to see an HP URL that works!

VMS Software Inc. [1] are the custodian of (own, I suppose) VMS these days.

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]

Side note. I worked on a systems implementation for medical billing that moved from OpenVMS to a Java/IE only monstrosity.

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).

I have sadly lost my copy of the Digital Technical Journal that had this article, it was a All-Alpha issue, if I remember correctly.

The authors are not attributed at the beginning of the article, but they are all named at the end.

The DTJ issues are available for download as PDF from https://vmssoftware.com/resources/digital-technical-journal/

The OpenVMS porting article is indeed part of the Alpha AXP Architecture and Systems Special Edition, DTJ Volume 4 No.4 (1992).

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact