[Info-vax] New CEO of VMS Software

[John Dallman]

In article <unae9c$bpv5$3 at dont-email.me>, ldo at nz.invalid (Lawrence
D'Oliveiro) wrote:

> > The project of getting the native X86_64 C++ compiler to straddle 
> > the 32- and 64-bit world of VMS and play nice with open source that 
> > expects fully 64-bitness everywhere would be much easier if we could 
> > abandon the 32-bit aspects of VMS, but we cannot, if we expect the
> > vast majority of our customers to remain on VMS.
> Such a long-winded way of saying _we could not make VMS fully 
> 64-bit, even on our own fully 64-bit hardware_.

It can't be made fully 64-bit without breaking source-level compatibility
with customer code. This is due to a series of past decisions that all
seemed reasonable at the time, but have combined in an unfortunate way in
today's situation. 

In about 1975, the VMS API was defined. Unlike [UL]inux with C, VMS is
not based on a particular programming language. It was considered vital
at the time to allow programs to be put together from a mix of
programming languages, including MACRO-32 assembler, BLISS, Pascal, Basic,
Cobol and Fortran. This meant that the calling convention and APIs were
defined in terms of bytes and words, using absolute sizes rather than
types that could change size with the memory model. 64-bit addressing was
not considered: a memory size of 1MB was considered large at the time. 

When Alpha came along, the API immediately became a problem. The first
versions of VMS on Alpha were 32-bit, in that they stored addresses in
memory as 32 bits and sign-extended them when they were loaded into
registers. VMS processes only used the bottom 2GB and the top 2GB of
their 64-bit address spaces. This was not a problem with OSF/1 Unix,
which was always fully 64-bit, because addresses were C pointer types and
changed with the memory model.

Obviously, DEC needed a 64-bit VMS. They also needed it /soon/, so they
added 64-bit versions of the APIs that most needed to deal with lots of
memory. Quite a lot of APIs that took pointers to user memory carried on
taking 32-bit pointers, and thus could only deal with data in the bottom
2GB of a process address space. 

They probably intended to add 64-bit versions of all the other APIs, but
this never happened, for reasons that probably included some of:

* Lack of budget: DEC was never as successful in the 1990s as it 
  had been in the 1980s. 
* Lack of concern about source portability: management still thought
  like a dominant company, although this was increasingly misleading. 
* Diffusion of effort over many projects and products. 
  
In C and C++, it's pretty easy to call alternate APIs according to the
memory model you're compiling for. You can do it with simple preprocessor
macros. Doing that for all the languages VMS supported, with supported
interoperability in the same process, is rather harder, and doesn't seem
to have been achieved. Customer source would have needed subtle, but
precise changes to call 64-bit APIs, and creating those APIs would have
been expensive. There was a VAX to Alpha binary translator  too, and
32-bit processes had to be retained for that. 

Then came Itanium. HP had to produce an Itanium version of VMS. Giving it
a complete 64-bit API at this point would have been the right thing to do,
but it would cost more than the basic job, and HP weren't that interested
in VMS. The 32-bit APIs would have had to be retained anyway for the
Alpha to Itanium translator, and to allow customer source compatibility. 

Now we get to x86-64. We don't have translators from any of the previous
architectures, because doing that for Itanium is Very Hard, but we still
have the customer source compatibility problem. VSI is a much smaller
company than DEC or HP, and getting VMS capable of compiling and running
customers' source is clearly the first priority, since there's no more
Itanium hardware. Once that is completely achieved, they could start to
develop towards a fully 64-bit system, with steps like:

First, complete the 64-bit API, after all these years. It's a fairly
well-defined task, but I don't know how big it is. 

Then, support the 64-bit APIs in the Clang headers, to allow building of
open-source programs that expect straight I32LP64. This should be fairly
straightforward. 

Finally, provide options, errors and warnings in the DEC-heritage
compilers to make it reasonably easy to adapt customer source to using
the 64-bit APIs. This is a large and unpleasant project that requires
delving into many codebases. It doesn't start to produce useful results
until most of the languages have been done, and the work is all debugged.
You still have to support the 32-bit APIs, for customers who are staying
on 32-bit for reasons varying from "impossible to change" to "we don't
feel like it." 

John