[Info-vax] VMS internals design, was: Re: BASIC and AST routines

[Arne Vajhøj]

On 11/25/2021 1:25 PM, Simon Clubley wrote:
> On 2021-11-25, Dave Froble <davef at tsoft-inc.com> wrote:
>> On 11/25/2021 9:01 AM, Simon Clubley wrote:
>>> VMS has given us great things such as world-leading clustering,
>>> but that doesn't change the ugly nature of its internal design.
>>>
>>> This has caused major problems going forward as people tried to
>>> enhance VMS. One such example is the need for a combined 32-bit/64-bit
>>> address space.
>>
>> Solving a "need" is a problem?
>>
> 
> In the way the underlying VMS design forced it do be done, yes, big time.
> 
> In other 64-bit operating systems, you have a mixture of pure 32-bit
> ABI processes and pure 64-bit ABI processes running in the same
> operating system. Far more cleaner and elegant.

I do not see that design as so clean.

Just look at Windows where the 64 bit stuff is in C:\Windows\System32
and the 32 bit stuff is in C:\Windows\SysWOW64 and in registry
HKEY_CLASSES_ROOT vs HKEY_CLASSES_ROOT\Wow6432Node and the fun with
ODBC drivers.

But even if we consider it a clean design, then it really does
not matter. It is all facilitated by the fact that the x86-64
CPU have a 32 bit mode and a 64 bit mode. Alpha did not have
two modes. So it was not an option for VMS.

For a handful of reasons it was decided to support
both 32 bit pointers and 64 bit pointers on VMS.

>>> Another such example is playing out right now as we speak.
>>>
>>> The engineers at VSI are talented, experienced and generally skilled
>>> overall. However, due to how VMS was designed, it has taken even these
>>> skilled people over 7 years so far to port VMS to x86-64 and they will
>>> not be finished until the middle of next year at the earliest.
>>
>> VMS was designed and implemented for VAX, not generic computers.
> 
> And that, along with the Macro-32 implementation language, is one of
> the reasons why we still don't have a production-ready port for x86-64
> after 7 years of porting effort, even though VMS has already been through
> ports to 2 different architectures.

I am not so sure that the Macro-32 is a major reason. When the
Macro-32 compiler is done and no changes are needed then
it is just compile. It is only when the code need to be modified
that it takes longer to understand and change Macro-32 than a HLL.

And regarding the 7 years, then I would consider it very interesting
to know how many people worked on the VAX->Alpha migration and how
many people work on the Itanium->x86-64 migration. I have a strong
suspicion that the latest migration has spent a lot less man years.

>>> How many people would have stayed with VMS if they knew in 2014 that
>>> it would take another 8 years before they had VMS on x86-64
>>
>> Me!  Me me me me me me ....
> 
> I doubt many would have joined you.

I think most would.

Those running VMS today are mostly those without an easy way off
VMS.

Continuing with VMS is what they want.

They are very interested in that VMS has a future. If not then
migration becomes necessary at some point in time.

So the confidence in VSI completing the port is very important.
But the timeline is less important.

Sure a x86-64 box is way more powerful and way cheaper than
Itanium and old Alpha's. But the Itanium's and Alpha's can
still do the job those VMS users need.

The drop dead time is when IslandCo can no longer deliver
Itanium's and Alpha's.

Arne