[Info-vax] VAX VMS going forward

[John Reagan]

On Tuesday, July 28, 2020 at 1:36:24 PM UTC-4, Simon Clubley wrote:
> On 2020-07-28, Arne Vajhøj <arne at vajhoej.dk> wrote:
> > On 7/28/2020 8:51 AM, Simon Clubley wrote:
> >> 
> >> You tell the compiler whether you want a 32-bit or 64-bit executable
> >> and it, the linker, and OS support libraries takes care of most of
> >> the work for you (if not all the work).
> >> 
> >> I wish it was that simple on VMS.
> >
> > Other environments are not doing this at all.
> >
> > Many other environments has 32 bit mode and 64 bit mode. Different
> > instruction sets and address size in the CPU. Two sets of
> > libraries. Etc..
> >
> 
> They do solve the same problem in a different way.
> 
> And they give you tools which makes it easy to switch between both
> environments when compiling your code.
> 
> > But that is completely different from what VMS has.
> >
> 
> _Very_ true.
> 
> > VMS Alpha/Itanium only has 64 bit mode and 64 bit addresses in the
> > CPU, single instruction set and one set of libraries. That single set
> > of libraries just have a lot of API's only passing lower half of
> > addresses and a few passing full addresses.
> >
> > Totally apples and oranges.
> >
> 
> But if the lowest-level supported language on VMS was C, then you
> could still do this in the compilers and linker along with suitably
> modified system headers without having to make major changes to your
> code. You would tell the compiler what you wanted via qualifiers just
> like you do in other operating systems.
> 
> There's enough information available in C code, along with enough
> abstracted implementation details (such as pointer size) that the
> code doesn't care about unless you go looking for it, that it would
> be quite viable to do in software what other environments do in hardware.
> 
> The same is true for the other high-level languages which VMS supports.
> 

I'm not sure how I can do it for Fortran COMMON blocks or EQUIVALENCE
statements.  COBOL levels and their implicit "union" might be interesting too.

BTW, besides OpenVMS, NonStop is a dual-sized pointer environment.

Microsoft has been adding dual-sized pointer support into clang/LLVM at this
very moment (I've been reviewing their code to make sure we can leverage it
for OpenVMS).  

> Unfortunately, VMS supports assembly language as an application
> programming language. That made perfect sense 40 years ago, but
> in 2020, it's a major weakness in VMS.
> 
> It's also the reason why we have a hybrid 32-bit/64-bit API interface
> instead of a flat 64-bit mode in addition to the traditional 32-bit API
> interface mode.

Yes.  No argument that the vast amount of Macro-32 (and BLISS-32) in the OS
greatly influenced the choice that was made.  Lots of money and time was
spent looking for the magic converter for Macro-32 to anything.  Nothing was
going to do the trick.  The Macro compiler itself has some latent infrastructure
for converting Macro-32 to C.  I guess VEST too given that we allow a mixing
of native and translated code.