[Info-vax] VMS documentation, was: Re: Special deals on Tape Drives

[Arne Vajhøj]

On 3/14/2022 4:06 PM, Simon Clubley wrote:
> On 2022-03-14, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 3/14/2022 2:48 PM, Simon Clubley wrote:
>>> Also, in Unix (thanks to C being the lowest supported language), pointers
>>> are an abstraction that the compiler deals with behind the scenes for you
>>> when it comes time to store them away and pass them around. In VMS,
>>> traditional pointers are an unabstracted and direcly exposed longword
>>> field that cannot just be automatically resized by passing "-m64" or
>>> similar on the compiler command line.
>>
>> That is a not really a block problem.
> 
> It is when you can't compile your RMS program (for example) to fully
> use a 64-bit address space by simply using a compiler switch when you
> recompile the programs without needing to make any user source code changes.

If DEC had gone clean 64 bit pointers then there would not even
be a compiler switch. VAX would be 32 bit pointers and Alpha & Itanium
would be 64 bit. And it would work fine with RMS blocks. RMS blocks
would not have the same size on VAX as on Alpha & Itanium, but not
a problem.

>> If DEC had decided to go only 64 bit pointers on Alpha 30 years ago,
>> then the block definitions could have had 64 bit address fields
>> in blocks on Alpha and Itanium.
>>
>> But they did not. For many reasons.
> 
> Yes, because when VMS was designed it had to work with a certain language
> which does not have an abstracted pointer size concept where the
> implementation details are mostly hidden from the user's source code.

If Macro-32 had been the only issue with going 64 bit pointers, then I
think DEC would have gone that route. But plenty of other reasons.

Arne