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

[Dave Froble]

On 3/12/2020 2:46 PM, Simon Clubley wrote:
> 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.

No Simon, it is because the VAX is a 32 bit architecture.  It was also 
rather leading edge at the time, and people were just moving up from 16 
bit.  Perhaps you expected them to already be thinking about 64 bit? 
128 bit?

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

Initial VAX 11/780 memory capabilities had nothing to do with it?

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

Ya know Simon, when FTL Starships are running all around, we can sit and 
take cheap shots at today's people.  You know, us.


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486