On 5/17/2021 8:18 AM, Simon Clubley wrote:
> On 2021-05-15, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
>>
>> Another pretty good link for those looking for VMS history:
>>
>> <http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
>> c1998.htm>
>>
>> "A Retrospective on What We Have Learned From the PDP-11:
>> What Else Did We Need to Know That Could Have Been Useful in the Design of
>> the VAX-11 to Make Alpha Easier?
>>
>> "VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
>>
>
> 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.
>
> Simon.
>

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.

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

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.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/17/2021 8:59 AM, Chris Townley wrote:
> On 17/05/2021 13:22, Arne Vajhøj wrote:
>> On 5/17/2021 8:18 AM, Simon Clubley wrote:
>>> On 2021-05-15, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com>
>>> wrote:
>>>> Another pretty good link for those looking for VMS history:
>>>>
>>>> <http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
>>>>
>>>> c1998.htm>
>>>>
>>>> "A Retrospective on What We Have Learned From the PDP-11:
>>>> What Else Did We Need to Know That Could Have Been Useful in the
>>>> Design of
>>>> the VAX-11 to Make Alpha Easier?
>>>>
>>>> "VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
>>>
>>>  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.
>>
>> But it is worth remembering that back then (second half 1970's) then
>> it was not common to write OS in C. Assembler and proprietary languages
>> was common. That changed in the next 10-15 years.
>>
>> But that one would be better off if one was able to predict the
>> future 10 years out is rather obvious.
>>
> Didn't Unix change that? Was it not built in C from day 1?

Unix was supposedly first written in assembler and a few year later
rewritten in C.

But it was in C when VMS was created.

The point is that at that time then Unix was not a big thing.

IBM, CDC, Sperry, Burroughs, HP etc. all had non-C OS.

Arne

On 5/17/2021 9:20 AM, Dave Froble wrote:
> On 5/17/2021 8:18 AM, Simon Clubley wrote:
>> On 2021-05-15, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
>>> Another pretty good link for those looking for VMS history:
>>>
>>> <http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
>>>
>>> c1998.htm>
>>>
>>> "A Retrospective on What We Have Learned From the PDP-11:
>>> What Else Did We Need to Know That Could Have Been Useful in the
>>> Design of
>>> the VAX-11 to Make Alpha Easier?
>>>
>>> "VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
>>>
>>
>> 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.
>
> Rather, perhaps it is the concepts that are different enough that it's
> apples and oranges, not two different types of apples?
>
> 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.

Given that it looks like the treading model has won over
traditional forking, then I don't think the missing fork
was the problem.

Arne

PS: Note that I used the term "traditional forking" not just
"forking" - I believe on Linux then threads are implemented
using fork mechanism under the hood.

On 2021-05-17, Dave Froble <davef@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@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 5/17/2021 3:12 PM, Simon Clubley wrote:
> On 2021-05-17, Dave Froble <davef@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

In article <s7uf6n$l2m$1@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

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

I don't think it's quite that clear. The VAX hardware was designed in
conjunction with VMS, I believe? And more than two modes was picked to
allow the kernel to be protected from bad drivers? There's nothing about
programming in C in itself that dictates a two-model model; UNIX always
works that way, but that's because it evolved to that model.

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

There are more cases than that when you care, notably when you're writing
memory management code, but you can easily find out the size with the
sizeof() function.

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

Indeed. If addressing other than 32-bit had been considered when the API
was designed, it should have been fairly easy to write a suite of macros
that allowed for instancing the API by address size. However, this was
not done, and it has not been retrofitted, which would be much harder
work. In 1976-78, addressing bigger than 32-bit must have seemed far away.

John

On 5/17/21 9:20 AM, Dave Froble wrote:
> On 5/17/2021 8:18 AM, Simon Clubley wrote:
>> On 2021-05-15, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
>>>
>>> Another pretty good link for those looking for VMS history:
>>>
>>> <http://gordonbell.azurewebsites.net/digital/Bell_Retrospective_PDP11_paper_
>>>
>>> c1998.htm>
>>>
>>> "A Retrospective on What We Have Learned From the PDP-11:
>>> What Else Did We Need to Know That Could Have Been Useful in the
>>> Design of
>>> the VAX-11 to Make Alpha Easier?
>>>
>>> "VMS is the Architecture That Mattered. not PDP-11, VAX, or Alpha"
>>>
>>
>> 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.
>>
>> Simon.
>>
>
> 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.
>
> Rather, perhaps it is the concepts that are different enough that it's
> apples and oranges, not two different types of apples?
>
> 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.
>

I think fork() could be implemented on VMS if there was a desire
to do it. But it has nothing to do with the language being used.
It's a system call and needs to be in the OS. Then it could be
called from any language. Maybe even DCL. :-)

bill

On 2021-05-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/17/2021 3:12 PM, Simon Clubley wrote:
>>
>> 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.
>

VAX. Which is where VMS started (and 32-bit processors are where Unix
and Linux started). It was a lot easier to get 32-bit Unix/Linux working
on 64-bit architectures than it was 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 in a portable implementation, then this detail (mostly) would not
matter as it would be mostly hidden from the source code within the ABI.

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

But in a portable implementation, you would have either a 32-bit
process or a 64-bit process. There would be no need for the hybrid
mode and all the extra APIs that go with it.

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

But this is about a portable version of VMS, not the non-portable
version that was created. In a portable version of VMS, you would
not have Macro-32 as a supported application language and the only
place you would see it is in little bits of architecture-specific
code on VAX that couldn't be written in C or a higher-level language..

BTW, how is INTEGER*4 handled on Unix or was Fortran code never
written that way on Unix ? (It's been a very long time since I
wrote any Fortran code.)

Simon.

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

On 2021-05-17, John Dallman <jgd@cix.co.uk> wrote:
> In article <s7uf6n$l2m$1@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> 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.
>
> I don't think it's quite that clear. The VAX hardware was designed in
> conjunction with VMS, I believe? And more than two modes was picked to
> allow the kernel to be protected from bad drivers? There's nothing about
> programming in C in itself that dictates a two-model model; UNIX always
> works that way, but that's because it evolved to that model.
>

Yes the hardware was designed in that way, but the point of the portable
VMS discussed in the linked article is that portable VMS would not use
any features that tied it to one specific architecture, such as 4 modes
when everyone else is using 2 modes.

BTW, the 4 modes in VMS was a missed opportunity. Unfortunately, the
drivers run in kernel mode along with the rest of the VMS kernel.

Executive mode is where RMS is located.

Supervisor mode is where DCL lives. (It cannot be in user mode because,
due to the design of VMS, DCL has access to the privileges of the
programs it runs).

User mode is where normal user applications run.

VMS as implemented only uses 3 inner modes to protect against
accidental damage. From a security point of view, there is only
one inner mode.

Unix works with only 2 modes because it was designed to be portable
and most of the architectures it runs on only have 2 modes.

Simon.

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

On 5/18/2021 2:33 PM, Simon Clubley wrote:
> On 2021-05-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> 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 in a portable implementation, then this detail (mostly) would not
> matter as it would be mostly hidden from the source code within the ABI.
>
>> 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.
>
> But in a portable implementation, you would have either a 32-bit
> process or a 64-bit process. There would be no need for the hybrid
> mode and all the extra APIs that go with it.
>
>> 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.
>
> But this is about a portable version of VMS, not the non-portable
> version that was created. In a portable version of VMS, you would
> not have Macro-32 as a supported application language and the only
> place you would see it is in little bits of architecture-specific
> code on VAX that couldn't be written in C or a higher-level language..

If DEC in 1976-1977 had prioritized making VMS portable and
if applications from that time and forward had done the same, then
a lot of things would have been easier today.

But I believe that line of thinking is a rather futile mental
exercise. If I could see out in the future then I could become
rich from either the stock market or playing the lottery.
But I can't. DEC could not see out in the future back then either.

> BTW, how is INTEGER*4 handled on Unix or was Fortran code never
> written that way on Unix ? (It's been a very long time since I
> wrote any Fortran code.)

INTEGER*4 is not a problem if used to store a 32 bit
integer data. It only becomes a problem if it is used to store
an address.

Like:

STRUCTURE /ITEMLIST/
INTEGER*2 BUFLEN,CODE
INTEGER*4 BUFADR,RETLENADR
ENDSTRUCTURE

Point is that non-portable data types used for addresses is
not a Macro-32 only problem.

Another problem with going only 64 bit pointers in Alpha
would have been VEST. When the tool saw a MOVL should it guess
on whether it was moving data or moving an address?

Arne

On 5/18/21 2:33 PM, Simon Clubley wrote:
> On 2021-05-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/17/2021 3:12 PM, Simon Clubley wrote:
>>>
>>> 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.
>>
>
> VAX. Which is where VMS started (and 32-bit processors are where Unix
> and Linux started).

PDP-7? PDP-11?

bill

On 5/18/2021 2:43 PM, Simon Clubley wrote:
> Supervisor mode is where DCL lives. (It cannot be in user mode because,
> due to the design of VMS, DCL has access to the privileges of the
> programs it runs).

The main reason for DCL being in S mode must be that the U stack
goes away at program termination so it has to be in the S stack.

Arne

On 2021-05-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Another problem with going only 64 bit pointers in Alpha
> would have been VEST. When the tool saw a MOVL should it guess
> on whether it was moving data or moving an address?
>

In a portable VMS, that problem probably would not exist and if
it was required for some reason, it would be handled in the same
way as however the Macro-32 compiler works in that case on Alpha.

Simon.

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

On 5/18/2021 2:54 PM, Bill Gunshannon wrote:
> On 5/18/21 2:33 PM, Simon Clubley wrote:
>> On 2021-05-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 5/17/2021 3:12 PM, Simon Clubley wrote:
>>>>
>>>> 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.
>>
>> VAX. Which is where VMS started (and 32-bit processors are where Unix
>> and Linux started).
>
> PDP-7?  PDP-11?

:-)

Unix started with PDP-7 (18 bit) and PDP-11 (16 bit).

Linux started with 386 (32 bit).

Arne

On 2021-05-18, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 5/18/21 2:33 PM, Simon Clubley wrote:
>> On 2021-05-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 5/17/2021 3:12 PM, Simon Clubley wrote:
>>>>
>>>> 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.
>>>
>>
>> VAX. Which is where VMS started (and 32-bit processors are where Unix
>> and Linux started).
>
> PDP-7? PDP-11?
>

Good point. IIRC, Unix in C first happened on the PDP-11. That
makes Unix even more portable (but I would not fancy working with
K&R C :-) ).

Simon.

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

On 5/18/2021 3:03 PM, Simon Clubley wrote:
> On 2021-05-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Another problem with going only 64 bit pointers in Alpha
>> would have been VEST. When the tool saw a MOVL should it guess
>> on whether it was moving data or moving an address?
>
> In a portable VMS, that problem probably would not exist

It would.

char *p1, *p2;
p2 = p1;

may be portable but in the binary it would either move 4 bytes
or 8 bytes.

> and if
> it was required for some reason, it would be handled in the same
> way as however the Macro-32 compiler works in that case on Alpha.

The Macro-32 compiler uses 32 bit pointers on 64 bit VMS.

Arne

On 2021-05-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/18/2021 3:03 PM, Simon Clubley wrote:
>> and if
>> it was required for some reason, it would be handled in the same
>> way as however the Macro-32 compiler works in that case on Alpha.
>
> The Macro-32 compiler uses 32 bit pointers on 64 bit VMS.
>

Then your translated VEST image would work in the same way.

After all, the image is coming from a 32-bit environment.

Simon.

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

On 5/18/2021 3:08 PM, Simon Clubley wrote:
> On 2021-05-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/18/2021 3:03 PM, Simon Clubley wrote:
>>> and if
>>> it was required for some reason, it would be handled in the same
>>> way as however the Macro-32 compiler works in that case on Alpha.
>>
>> The Macro-32 compiler uses 32 bit pointers on 64 bit VMS.
>
> Then your translated VEST image would work in the same way.
>
> After all, the image is coming from a 32-bit environment.

And it did.

But that means 32 bit pointers.

And then Macro-32 is obviously fine as it uses the same 32 bit pointers.

Arne

On 2021-05-17 19:12:23 +0000, Simon Clubley said:

> ...Operating system concepts mostly have nothing to do with portability...

Gonna have to decide if you're building new with ease of porting
OpenVMS apps to the new, or building new with close OpenVMS
compatibility with the old.

The former presumably with a path toward more updates and new work and
evolving, while the latter maintaining the existing apps and with less
work for the developers porting the apps.

DEC MICA tried to split this, allowing what amounted to containers for
the operating systems. The modern version being paravirtualized
hypervisors, and Sector7-style porting environments.

The trade-offs continue from there too, including the two- or
four-modes discussions, whether drivers will be included, how much of
POSIX or of .NET, and many thousands of other choices.

And I don't see a viable market for stasis; for OpenVMS not moving
forward, and quickly. Nor a viable market for an alternative to OpenVMS
that isn't moving forward.

I don't see itemlists or descriptors or FAB/RAB/NAML/XAB or the rest of
the existing OpenVMS API design being particularly interesting to
developers, either—not outside of existing code.

Support for OO and FRP would be expected, either in the existing
OpenVMS environment, or as an upgrade path for OpenVMS apps.

Looking at current and future hardware too, we're getting more cores,
more memory and with NUMA and clustering, and with faster storage. But
we're not getting robust support for more modes. Not past two modes
plus hypervisor and enclave support.

But the scale of operating system development work here is
change-back-from-your-billion and that over a decade of work and a
decade of trade-offs, and I'd have to check the couch cushions for that
kind of cash and schedule time.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-05-19, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2021-05-17 19:12:23 +0000, Simon Clubley said:
>
>> ...Operating system concepts mostly have nothing to do with portability...
>
> Gonna have to decide if you're building new with ease of porting
> OpenVMS apps to the new, or building new with close OpenVMS
> compatibility with the old.
>

My comment refers back to the linked article where the regret was
that VAX was the architecture instead of VMS being the architecture
that was implemented on a C machine.

With a 2-mode architecture with C as an implementation language, you
could either have had everything that is currently VMS (clusters,
the DLM, VMS APIs, etc) implemented unchanged, or the same functionality
but implemented in a different way (DCL, RMS, etc).

It would have still been VMS, but implemented in a much more portable way.
There is nothing in the above list that would reduce portability to
a new architecture, which is the point I was making.

Simon.

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

On 2021-05-19 17:38:50 +0000, Simon Clubley said:

> My comment refers back to the linked article where the regret was that
> VAX was the architecture instead of VMS being the architecture that was
> implemented on a C machine.
>
> With a 2-mode architecture with C as an implementation language, you
> could either have had everything that is currently VMS (clusters, the
> DLM, VMS APIs, etc) implemented unchanged, or the same functionality
> but implemented in a different way (DCL, RMS, etc).
>
> It would have still been VMS, but implemented in a much more portable
> way. There is nothing in the above list that would reduce portability
> to a new architecture, which is the point I was making.

There are risks and trade-offs in any complex design.

I suspect the influence of Multics among the DEC designers of the VAX era.

Bell Labs took the ideas and designs of Multics in a different
direction with Unix.

As for porting OpenVMS, VSI followed the porting approach used twice
before, rather than the DEC R&D approach prototyped once.

Risks and trade-offs.

--
Pure Personal Opinion | HoffmanLabs LLC

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> VAX. Which is where VMS started (and 32-bit processors are where Unix
> and Linux started). It was a lot easier to get 32-bit Unix/Linux working
> on 64-bit architectures than it was VMS.

NB: For the purposes of this discussion, Unix started on a *16*-bit
architecture. (We'll ignore the fact that it actually started on an 18-bit
word addressed architecture.)

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 2021-05-21, Rich Alderson <news@alderson.users.panix.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> VAX. Which is where VMS started (and 32-bit processors are where Unix
>> and Linux started). It was a lot easier to get 32-bit Unix/Linux working
>> on 64-bit architectures than it was VMS.
>
> NB: For the purposes of this discussion, Unix started on a *16*-bit
> architecture. (We'll ignore the fact that it actually started on an 18-bit
> word addressed architecture.)
>

Yes, oops. :-) Somebody already reminded me about this a few days ago
and as I pointed out in response this just shows how much more portable
things are when you are using an implemention language not tied to the
architecture.

Simon.

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

On Mon, 24 May 2021 12:28:32 +0000, Simon Clubley wrote:

> On 2021-05-21, Rich Alderson <news@alderson.users.panix.com> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>> VAX. Which is where VMS started (and 32-bit processors are where Unix
>>> and Linux started). It was a lot easier to get 32-bit Unix/Linux
>>> working on 64-bit architectures than it was VMS.
>>
>> NB: For the purposes of this discussion, Unix started on a *16*-bit
>> architecture. (We'll ignore the fact that it actually started on an
>> 18-bit word addressed architecture.)
>>
>>
> Yes, oops. :-) Somebody already reminded me about this a few days ago
> and as I pointed out in response this just shows how much more portable
> things are when you are using an implemention language not tied to the
> architecture.

They still made some mistakes. Such as a 16 bit limit for the number of
sectors on a disk (they solved that one by inventing partitions). And the
16 bit seek distance (in bytes, solved by inventing lseek in Seventh
Edition).

The language isn't everyting.
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On 24/05/2021 13:28, Simon Clubley wrote:
> On 2021-05-21, Rich Alderson <news@alderson.users.panix.com> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>> VAX. Which is where VMS started (and 32-bit processors are where Unix
>>> and Linux started). It was a lot easier to get 32-bit Unix/Linux working
>>> on 64-bit architectures than it was VMS.
>>
>> NB: For the purposes of this discussion, Unix started on a *16*-bit
>> architecture. (We'll ignore the fact that it actually started on an 18-bit
>> word addressed architecture.)
>>
>
> Yes, oops. :-) Somebody already reminded me about this a few days ago
> and as I pointed out in response this just shows how much more portable
> things are when you are using an implemention language not tied to the
> architecture.
>
> Simon.
>

Yeah sure, UNIX code was so portable that back in the 1980s anything
much more complex than "Hello World" had little chance of being portable
between (e.g.) BSD and System V even on the very same hardware.

When the two main camps can't even agree on the basics of opening a file
from C,
as in fd = open(...),
it's no wonder there was a customer/vendor need for a Single UNIX
Specification.

Fortunately times have moved on since then.