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

[Simon Clubley]

On 2020-03-12, John Reagan <xyzzy1959 at gmail.com> wrote:
> 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.
>

Yes, but the reason why those descriptors and itemlists were designed
in the way they are, with raw longwords to hold addresses instead of
a pointer datatype, is because they needed to be usable from Macro-32
in the early days of VMS when writing applications in Macro-32 was
still considered a very viable and even normal thing to do.

> 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?
>

If VMS had implemented pure 64-bit processes without the combined 32/64-bit
processes that actually happened, then you could have got a 32-bit value
with a 32-bit process and a 64-bit value with a 64-bit process.

> 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. 

Given the legacy of Macro-32 in the design of VMS, and the lack of
abstraction in the VMS design around such things, you really didn't
have a choice at the time unfortunately because of the need to keep
existing code, especially Macro-32 code, running.

My comments above are about how much cleaner the move to a 64-bit
environment would have been if such details were not exposed within
the application source code because VMS had only ever used higher level
languages for application programming.

This discussion here is about what you could do better in an open source
version of VMS designed around more modern concepts and in that case
a number of possibilities open up once you decide to get rid of Macro-32
and go with languages, including C, that have a pointer datatype where the
implementation details are hidden from the user's source code.

In that case, there's no need for the combined 32-bit/64-bit process space
and your descriptors and itemlists contain 32-bit addresses when a program
is compiled in 32-bit mode and contain 64-bit addresses when it is compiled
in 64-bit mode.

The best bit is that this can all be done without needing to make source
code changes to support the different modes as the operating system knows
whether it is dealing with a image compiled and linked in 32-bit or 64-bit
mode when the image is loaded for execution.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.