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

[VAXman- at SendSpamHere.ORG]

In article <r4e02s$pk$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>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.

Why are you so hate filled?  The reason they were 32 bits is because the
VAX, where VMS initially was designed to run, was 32 bits.  Addresses on
VAX were 32 bits; thus, the data structures to house those addresses are
32 bits.  No different in your unix/C world or did the Eunuchs geniuses
devise some way to stuff 64 bits into a byte... er, excuse me, char?



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

BS

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.