[Info-vax] The Road to V9.0

[Arne Vajhøj]

On 10/14/2019 8:50 AM, Simon Clubley wrote:
> An example I have used previously might make this clear, although this
> is not directly related to the current example John posted:
> 
> In traditional VMS control blocks, the address of a memory location is
> a raw 32-bit longword. It is _NOT_ an abstracted language level pointer
> to a memory location.
> 
> You can't move the traditional VMS control blocks to a fully 64-bit
> address space without implementing a new VMS control block with addresses
> that are 64-bit wide. This is something which is very visible at source
> code level.
> 
> OTOH, on Linux, when you move between 32-bit and 64-bit the work involved
> is a lot easier and, within the application, quite a lot of this can be
> handled transparently by the compiler which knows that the width of a
> pointer is now 64-bits instead of 32-bit and generates the correct code
> for you automatically.

Traditional VMS control blocks are Macro-32 centric
not HLL centric. So ...

The model with a HLL and a pointer type works great if pointers
on a given platform always have the same size.

If pointers on the platform can have different sizes, then
that model becomes very complicated.

> This is the basic difference between an API designed to support assembly
> language applications (VMS) versus APIs designed to support languages
> which have additional levels of abstractions (C on Unix).
> 
> This memory pointer issue is one example of how the VMS data structures
> and APIs simply tend to have a lower level of abstraction at source code
> level.

Yep.

Arne