Dumping comments from several different threads here.
=
Why no OpenVMS VAX build? OpenVMS VAX was ~60,000 source modules and
the associated compilers and build tools and the rest, and a very large
and complex build environment, separate from that of OpenVMS Alpha and
OpenVMS I64 (and likely also from x86-64), and dependencies on cluster
setup and queues and other details, and the last full system rebuild
was performed ~2001, and that cluster and any follow-on cluster no
longer exist, and I'd wager that the migration has had tools and pieces
disappear. So... not something to knock together quickly. it took me a
couple of weeks to port the OpenVMS Alpha build environment to a test
cluster, and that was when all of the tooling was actively maintained
and directly available. After ~20 years and organizational churn,
effort involved will be higher. And new VAX chips date back ~25 years.
The market for VAX updates is smaller than the market for
OpenVMS—OpenVMS VAX support ended long ago, and there haven't been new
VAX patches for quite some time—and the need for and the market for a
working and performant VSI OpenVMS port on x86-64 is far more important
for the future of OpenVMS than is investing in preserving those folks
still using VAX hardware or VAX emulation.
=
Hobbyist OpenVMS? Hobbyist OpenVMS VAX?
If you're a hobbyist and want to use OpenVMS VAX and with legitimate
licenses, might want to ask the folks at HPE to generate folks a
farewell gift of permanent hobbyist PAKs for OpenVMS VAX.
If you're a hobbyist and want OpenVMS with legitimate licenses, that
path will be x86-64 and whatever hobbyist program VSI bakes. OpenVMS
VAX will not be a good starting point. OpenVMS VAX isn't a good
starting point now.
Handing an inexperienced-with-OpenVMS hobbyist an OpenVMS VAX system is
a Bad Idea, as OpenVMS is different enough and difficult enough to
learn, and ~25 year old networking and compilers and tools makes
learning about OpenVMS that much more difficult. And VAX adds a pile of
old hardware or hardware emulation into the effort a new hobbyist must
contend with.
For those hobbyists that knew or know OpenVMS and for those dedicated
computing retronauts, VAX and OpenVMS VAX, sure, have at.
I suspect one of the major reasons why OpenVMS VAX hobbyist is popular
right now is a working (free) hardware emulator. If there were a
similarly robust and free Alpha or Itanium emulator available for the
hardware-lacking folks, we'd likely be in an entirely different
discussion. And yes, there are and will be those folks that want VAX
for VAX because VAX.
=
Cross-builds, builds, translations...
VAX-11/VMS was cross-built using the integrated PDP-11 hardware support
in VAX and using hunks of RSX-11M. VAX/VMS itself was dependent on
PDP-11 hardware support for the first three major versions. VAX/VMS
only went fully VAX native at V4.0. SYE was one of the last pieces to
migrate native, though there were a few others.
OpenVMS Alpha was initially cross-built from VAX and that initially
targeting Alpha hardware emulators (the so-called ADU Alpha Development
Units), and then actual working Alpha hardware. All production Alpha
releases were native-built. There were a few translated components that
lingered, and TECO was among those.
OpenVMS I64 followed the same general path as Alpha, though did not
fork the build environments, and was initially cross-built from Alpha,
and all production releases were native built. Again, with some few
facilities using binary-translation tools.
AFAIK, no pieces of Alpha or Itanium were cross-built, once the native
build tools were available. Though there were a few hunks that were
binary-translated and a few that were re-coded, as the available tools
could not contend with older app designs or app assumptions or required
app tooling.
The OpenVMS x86-64 lowercase-a alpha release is by all accounts
cross-built from Itanium, and the production releases will reportedly
be native built and probably with some selected re-coded or using
binary translation tooling if and as that becomes available.
=
The OpenVMS Alpha port targeted bug-for-bug compatibility with OpenVMS
VAX, and deliberately did not fix a whole bunch of stuff that was
broken in OpenVMS VAX. And is still broken in OpenVMS Alpha and OpenVMS
I64. Probably going to be broken on OpenVMS x86-64, too, but that's not
available for inspection. The port did fix a whole bunch of
build-related issues, though the build-related tooling for the two
environments was made more consistent over time. The issue that arose
here was reworking and back-porting 64-bit code back to a 32-bit
environment. 64-bit integers were a common problem for C code, and the
choice was to use an array for 64-bit or larger values, or to fork the
code, or to use conditional builds and which made the source code that
much more involved.
The OpenVMS Alpha 64-bit transition could not be compatible with
OpenVMS VAX, and definitely diverged. That happened in the virtual
addressing, in the compilers and linker, and elsewhere. The design
choice at the time was to go native, flat 64-bit and which was viewed
as a better long-term solution, or to go with a more complex and hybrid
32- and 64-bit design that was going to be a problem longer-term. The
choice to use the 32- and 64-bit hybrid design—a quite interesting
design, and one that did succeed with its goals—was intended to
preserve those sites that had already had 32-bit apps and shareable
images and dependencies, and were not going to upgrade those, and the
hybrid design allowed retrofitting 64-bit addressing into those
existing environments. Without requiring the prerequisite apps to be
upgraded to 64-bit. Which was a very successful approach for piecemeal
64-bit projects. But the 32-/64-bit hybrid design stinks large for new
work, and has made existing apps adopting 64-bit addressing much more
complex, and made OpenVMS itself that much more complex with the
mumble64 APIs and ABIs, with forked code, and with the conditional
32-/64-bit code across the APIs and ABIs. And not starting anew with
64-bit lost an opportunity to fix latent 32-bit issues for end-users
and developers.
=
There was and is no right choice here, just various trade-offs and
wrong choices.
--
Pure Personal Opinion | HoffmanLabs LLC