[Info-vax] A portable VMS, was: Re: OS Ancestry

[Arne Vajhøj]

On 5/18/2021 2:33 PM, Simon Clubley wrote:
> On 2021-05-17, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> The CPU on Alpha, Itanium and x86-64 is always in 64 bit mode. Effective
>> addresses are always 64 bit.
>>
>> Pointers in memory can just contain all 64 bits or just 32 bits with an
>> assumption about the high bits.
> 
> But in a portable implementation, then this detail (mostly) would not
> matter as it would be mostly hidden from the source code within the ABI.
> 
>> But it is a per pointer characteristic not a per program
>> characteristic - it is possible to have both 64 bit and 32
>> bit pointers in the same program.
> 
> But in a portable implementation, you would have either a 32-bit
> process or a 64-bit process. There would be no need for the hybrid
> mode and all the extra APIs that go with it.
> 
>> If all code on VMS had been nice standard ANSI C, then a lot of
>> things would have been easy.
>>
>> The reality was different. Not just Macro-32 .blkl but
>> also Fortran INTEGER*4 and possible other languages
>> as well.
> 
> But this is about a portable version of VMS, not the non-portable
> version that was created. In a portable version of VMS, you would
> not have Macro-32 as a supported application language and the only
> place you would see it is in little bits of architecture-specific
> code on VAX that couldn't be written in C or a higher-level language..

If DEC in 1976-1977 had prioritized making VMS portable and
if applications from that time and forward had done the same, then
a lot of things would have been easier today.

But I believe that line of thinking is a rather futile mental
exercise. If I could see out in the future then I could become
rich from either the stock market or playing the lottery.
But I can't. DEC could not see out in the future back then either.

> BTW, how is INTEGER*4 handled on Unix or was Fortran code never
> written that way on Unix ? (It's been a very long time since I
> wrote any Fortran code.)

INTEGER*4 is not a problem if used to store a 32 bit
integer data. It only becomes a problem if it is used to store
an address.

Like:

       STRUCTURE /ITEMLIST/
         INTEGER*2 BUFLEN,CODE
         INTEGER*4 BUFADR,RETLENADR
       ENDSTRUCTURE

Point is that non-portable data types used for addresses is
not a Macro-32 only problem.

Another problem with going only 64 bit pointers in Alpha
would have been VEST. When the tool saw a MOVL should it guess
on whether it was moving data or moving an address?

Arne