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

[Arne Vajhøj]

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

????

As far as I am aware C old or new only got one type of pointers,
those you declare like:

type *var;

The C header files for RMS definition on VMS contains:

struct xxx {
    ...
    struct yyy *xxx$l_yyy;
    ...
}

How does your "the abstracted pointers you see in a modern environment"
do that?

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

VMS engineers made a design decision 30 years ago.

But that is not much related to Macro-32.

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

Correct. They chose a mixed address setup.

That has some benefits regarding easier initial migration and
some drawbacks regarding long term maintenance cost.

Such decisions are sometimes made.

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

But the Macro-32 style in this regard is no different from
Fortran, Pascal, Basic, Cobol, C.

In C terms you have struct, you put some values into fields, you
make a call and you get some values from fields.

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

I don't think he will rewrite RMS to support it.

But I am pretty sure that he could write the macros that
could expand a .pointer to .blkl or .blkq depending on
context, which is all what the C pointer does declarations do.

Arne