[Info-vax] The Road to V9.0

[johnwallace4 at yahoo.co.uk]

On Monday, 14 October 2019 13:50:40 UTC+1, Simon Clubley  wrote:
> On 2019-10-13, Dave Froble <davef at tsoft-inc.com> wrote:
> >
> > Question for you John ...
> >
> > Are these problems you're correcting actual poor / bad coding?  I'm 
> > getting the impression that for most it's just in the conversion to LLVM.
> >
> 
> This is not poor coding as I understand it.
> 
> This appears to be about different abstraction levels in VMS interfaces
> versus (for example) Linux interfaces.
> 
> From what I can see, things which are an hidden implementation detail
> in the ABI on Linux (and hence are invisible to the Linux code being
> compiled) are visible at source code level in VMS and hence need to be
> implemented in a way which does not break existing code.
> 
> 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.
> 
> This is not fully automatic (for example, if you are using some external
> interface which is only 32-bit aware), but within your code it's a _lot_
> easier to handle these kinds of problems at source code level on Linux
> than it has traditionally been on VMS.
> 
> 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.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

The (Open)VMS calling standard covers a lot of these 
sharp edges, as do various flavours of descriptor, but 
things like EDT and DIFF (and BLISS) do go back quite 
a long time. 


This isn't exclusively, or even primarily, an (Open)VMS 
issue. E.g. just ask the many folks who were around when 
the Sun community moved from 32bit to 64bit. Then there
was DEC OSF/1 aka Tru64; compatibility with 32bit UNIX 
code forced DEC OSF/1's 64bit compiler+linker to 
introduce -taso ("truncated address space option")
so that software that unwisely assumed that pointers 
would fit in 32bits might stand a chance of working on
Tr64. 

Eeven RATFOR had pointer types, back in the 1970s. But 
how many people took the trouble to thimk ahead?