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

[VAXman- at SendSpamHere.ORG]

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

ROTFLMFAO!



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

LOL.  All those unix data structures miraculously store arbitrary lenght
addresses without knowledge?


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

I don't see that they're all that suitable to Macro-32.  Most of what
you loathe about VMS, RMS, and its API have been simplified in Macro-32
by the fact that it has a macro capability.  



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

Nobody has asked or tasked me to do it.



>$ set response/mode=good_natured
>
>I'm sure VSI would be very interested in talking to him if he can
>do that. :-)

I've spent more time in the bowels of RMS than most, even some of
VMS engineering.  You, on the otherhand, haven't done enough VMS
Macro-32 programming to write a "Hello World" demo.

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

I speak to machines with the voice of humanity.