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

[Simon Clubley]

On 2020-03-12, Arne Vajhøj <arne at vajhoej.dk> wrote:
> On 3/11/2020 10:12 PM, Simon Clubley wrote:
>> A really good example is RMS and the control blocks and what happened
>> during the move to 64-bit processes.
>> 
>> In Unix land, an address variable looks like this:
>> 
>> 	{some data type or struct} *ptr;
>> 	ptr = data_structure->flink;
>> 
>> The Unix land compiler, regardless of language, handles all the conversions
>> from 32-bit pointers to 64-bit pointers when you rebuild this code for
>> 64-bit mode without you having to change this code.
>> 
>> 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.
>
> ????
>
> When I search after $l_fab, $l_rab, $l_nam, $l_kbf, $l_rbf, $l_ubf
> etc. I see pointer and pointers.
>
> You don't?
>

They may be called "pointers" but they are nothing like the abstracted
pointers you see in a modern environment, including in C and Unix.

They are nothing more than raw longwords that have had an address
forced into them. On VMS, there's no way to compile all your code
with a /mode=64_bit and turn all your RMS control blocks into 64-bit
versions automatically without making major source code changes.

And BTW, large amounts of RMS are restricted to 32-bit pointers
even in a 64-bit environment.

> But yes they keep separate structures with different pointer
> size in the same header files.
>
> So you can actually have the same program use both 32 and 64
> bit versions.
>
> Was that a wise decision almost 30 years ago? I don't know.
>
> But they do use pointers and I really don't see much
> relation to Macro-32
>

Because when VMS was designed, writing applications in Macro-32 was
considered a viable and normal thing to do and VMS needed to support
programming styles suitable to that environment.

>> 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.
>
>> This is one area in which Unix style code is _way_ cleaner than
>> VMS style code due to C being the lowest supported level of language
>> in the Unix world, instead of assembly language as in the VMS world.
>
> Hmmm.
>
> I am pretty sure that Brian can produce a Macro-32 macro that can
> produce an address size data element controlled by platform
> and compilation switches.
>
> I do not see a big difference between C and Macro-32 in this
> regard.
>

Good. I'd like to see how he can use it to turn RMS into a fully
64-bit environment usable from within Macro-32 code in the current
VMS environment with nothing more than a /mode=64 qualifier. :-)

$ set response/mode=good_natured

I'm sure VSI would be very interested in talking to him if he can
do that. :-)

Simon.

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