[Info-vax] A portable VMS, was: Re: OS Ancestry

[Simon Clubley]

On 2021-05-17, Dave Froble <davef at tsoft-inc.com> wrote:
> On 5/17/2021 8:18 AM, Simon Clubley wrote:
>>
>> From that link:
>>
>> | Thus, our real oversight was not understanding that VMS should have been
>> | built on the C machine for portability across any architecture.
>>
>> This. 5 zillion times this. VMS could have become like Unix in dominance
>> if this had been the case.
>>
>> Want to move VMS to a new architecture in this setup ? It would have been
>> a comparable effort to what is involved in porting Linux to yet another
>> architecture, instead of the current effort that is involved.
>>
>> VMS was designed at too low of an abstraction level.
>>
>> Also, while he mentions BLISS, he skips over all the Macro-32 usage
>> and, based on discussions here, all the internal calling conventions
>> within the VMS kernel that requires those registers.
>>
>
> But is the implementation language the only issue?  I'd think not.  As 
> John and minions have demonstrated, perhaps with some effort, they can 
> handle the multiple languages.
>

It's a massive part of it but you also have to think about the 4-modes
versus 2-modes issue. If you were looking at a C machine model, that
would also mean a design where you were not tied to any architecture
specific modes, so VMS would have been designed around a 2-mode model
in that case.

That means either supervisor mode disappears and DCL runs in a different
process or DCL never sees privileges from the programs it activates.

RMS is the more interesting case. Either that gets folded into the
kernel, or some other mechanism would have to be developed to isolate
it from the user mode code in the same way that executive mode does.

The reason any implementation language (and the functionality in the
lowest supported application language) matters is because of the level
of abstractions you can rely on when writing your operating system and
when implementing the APIs the user's application programs are going to use.

For example, if your lowest level is C, you can define a pointer variable
like this:

	unsigned char *ptr;

The size of that pointer is abstracted away from you and you simply
don't care about that pointer size unless you are working with some
hardware where it matters.

You can compile that line of source code (and anything that uses it)
in either 32-bit or 64-bit mode and it simply doesn't matter to the
source code. A portable VMS would just need to know whether it is
dealing with a 32-bit or 64-bit image and that information would be
provided by the image activator.

In the current VMS design, your lowest level is Macro-32 so you don't
have that level of abstraction and the size of the pointers are _very_
visible to you and your source code.

That means your APIs have to be designed around that lack of abstraction
and you can't move from 32-bit to 64-bit by simply (mostly!) recompiling
your application source code.

Imagine if, for example, RMS had been designed in a world where C was
the lowest level instead of Macro-32. You would not need any of the
32-bit versus 64-bit RMS APIs (it would be just one API at source code
level) and your program would either be a pure 32-bit application or a
pure 64-bit application.

Likewise with the kernel. That would be written in C using internal
function calls with clean interfaces. There would be none of this
Macro-32 call and jump instructions jumping around in a chain of kernel
functions stuff with specific registers reserved for specific parameters.

Any such details would be implemented by the compiler as part of
the ABI for the architecture (and would be different for every
architecture) and this would be hidden from most of the kernel
source code, just as with application code written in C and above.

You would still have everything that makes VMS what it is (DLM,
clusters, and everything else) but that code would be vastly more
easy to port than it currently is.

> Rather, perhaps it is the concepts that are different enough that it's 
> apples and oranges, not two different types of apples?
>

Operating system concepts mostly have nothing to do with portability.

> For an example, FORK doesn't seem too easy to implement on VMS, 
> regardless of the language.  Though, I'll admit that this example has 
> little to do with your claim of ease of porting.
>

A missing fork() is a question of functionality, not a question of
portability between architectures.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.