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

[Arne Vajhøj]

On 5/17/2021 3:12 PM, Simon Clubley wrote:
> 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.

The 4 modes would of course be a complication, but VSI has solved it
(mapping 4 logical modes to 2 hardware modes) for the x86-64 port.

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

Note that there is no such thing as 32 bit and 64 bit mode on VMS.

The CPU on Alpha, Itanium and x86-64 is always in 64 bit mode. Effective
addresses are always 64 bit.

Pointers in memory can just contain all 64 bits or just 32 bits with an 
assumption about the high bits.

But it is a per pointer characteristic not a per program
characteristic - it is possible to have both 64 bit and 32
bit pointers in the same program.

If all code on VMS had been nice standard ANSI C, then a lot of
things would have been easy.

The reality was different. Not just Macro-32 .blkl but
also Fortran INTEGER*4 and possible other languages
as well.

Arne