[Info-vax] Creating an open source version of VMS, was: Re: OpenVMS Hobbyist Notification

[John Reagan]

On Wednesday, March 11, 2020 at 10:12:58 PM UTC-4, Simon Clubley wrote:

> 
> In VMS land, thanks to the need to support Macro-32, an address
> looks something like this:
> 
> 	uint32 ptr;
> 	ptr = (uint32) source_address;	/* YUCK YUCK YUCK ! :-) */
> 
> with total loss of any address attribute information.
> 
> If all these raw longwords were not user-visible in the way they are
> in VMS thanks to Macro-32, and you only needed to support higher level
> languages, then the move to 64-bit VMS might have been as simple as
> compiling and linking your code for 64-bit mode instead of 32-bit mode.
> 
> Without the need to support Macro-32, the RMS control blocks would
> have been written for higher level languages with proper pointer
> and other abstracted variable types which automatically change size
> during compilation and linking as required.
> 

While Macro-32 a small part of the reason why things staying mostly 32-bits on Alpha, it was more about descriptors (which have a 32-bit pointer in them), itemlists (which are FULL of 32-bit pointers), etc.  That was more responsible for forcing stacks and static data to be in 32-bit address space.

It also avoided having to push 64-bit operations into all the compilers at once.  For example, what should Fortran's %LOC return?  Would you need a %LOC64 also?

So even without a single-line of Macro-32, I think Alpha still would have ended up with 32-bit stack, 32-bit static data, etc. unless you would want to invalidate all existing descriptors and itemlists and force all code to be updated to use new wider descriptors and itemlists.  However, that would have made VEST a much harder operation to get binary translated VAX code to use native Alpha services.