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

[Arne Vajhøj]

On 3/12/2020 5:25 PM, Simon Clubley wrote:
> On 2020-03-12, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 3/12/2020 3:20 PM, Simon Clubley wrote:
>>> On 2020-03-12, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>>>
>>>> ????
>>>>
>>>> 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?
> 
> You are either being deliberately obtuse or you simply do not
> understand what I am saying.
> 
> To answer your question: the abstraction comes from how addresses
> are referenced in C source code versus how they are referenced
> in Macro-32.

Since you showed two pieces of C code, then I was obvious searching
in the C code on VMS.

It did not occur to me that you were describing Macro-32 with C examples.

I think you will find that if you want to make a point about a problem
you see in language X then it may facilitate better communication if
your code example actually is in language X.

> In a C/Unix environment (and in other higher level languages) how the
> pointer to an address is implemented is a compiler/ABI implementation
> detail that is hidden (ie: abstracted away) from the higher level
> language source code. The source code generally doesn't care how
> the pointer is implemented or even in most cases what size it is.
> 
> The same source code can be easily moved between a 32-bit and 64-bit
> environment and across a range of environments.
> 
> In a Macro-32 environment, this is a very source code visible detail
> that strongly affects how the program is written.

It is hardly surprising that an assembler language often are
much closer to the hardware than a HLL.

But I am still not sure why you consider Macro-32 a reason for
the VMS API's not being modernized.

If VSI add a new lib$superduper function with a very fancy API, then
it can still be called from Macro-32.

If VSI decided to backport it to VMS VAX then the Macro-32 code
may likely need to be rewritten (unless we got a few smart macros from
Brian).

But since that will not happen, then it is not really a point.

> This is why in a modern Unix environment, you have to do little more
> than tell the compiler whether you want the program built in 32-bit
> or 64-bit mode unless you have deliberately coded the program in a
> _very_ bad way.
> 
> In a modern VMS environment, you end up with a mixed 32-bit/64-bit
> address space because compiling all your source code in a pure 64-bit
> mode simply was not a viable option when 64-bit support was added
> to VMS due to how visible this stuff is to the source code in VMS.

Very old and brand new VMS HLL code usually compiles fine with
no problems due to mix of 32 and 64 bit.

I suspect that it is a maintenance problem for VMS engineering
team.

But DEC created some technical debt for them 30 years ago.

Arne