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

[Arne Vajhøj]

On 3/11/2020 10:12 PM, Simon Clubley wrote:
> On 2020-03-11, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 3/11/2020 3:25 PM, Simon Clubley wrote:
>>> On 2020-03-11, Dave Froble <davef at tsoft-inc.com> wrote:
>>>> On 3/11/2020 9:22 AM, Simon Clubley wrote:
>>>>> On 2020-03-10, Dave Froble <davef at tsoft-inc.com> wrote:
>>>>>>
>>>>>> Really off the wall, since Macro-32 is not part of the OS.
>>>>>
>>>>> Oh yes it most certainly is.
>>>>>
>>>>> The need to support Macro-32 as an application programming language is
>>>>> the reason why the various VMS APIs look the way they do.
>>>>>
>>>>> It's also one of the reasons why VMS needs mixed mode 32-bit/64-bit APIs
>>>>> in the same process instead of just having a flag that says the current
>>>>> process uses either 32-bit or 64-bit pointers and addressing by default.
>>>>
>>>> Supporting what allows use of Macro-32 does not mean that the language
>>>> is part of the OS.
>>>>
>>>
>>> But the point is that it's not about supporting Macro-32, but limiting
>>> what the OS can do in its various APIs if it has to provide support for
>>> applications written in assembly language.
>>
>> I find it very difficult to believe that any possible new
>> API's could not be implemented in Macro-32.
> 
> That isn't what I said. What I said is that the various VMS APIs are
> more ugly than they need to be because of the need to support applications
> written in assembly language.

Isn't that the same?

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

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

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

Arne