On 26/11/2021 18:54, Simon Clubley wrote:
> On 2021-11-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/25/2021 1:25 PM, Simon Clubley wrote:
>>>
>>> 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.
>>
>
> The problem Arne is that in many companies, those who want to stay
> on VMS are not those who actually make the final decision about whether
> to stay on VMS.
>
> Those kinds of decisions are usually made one or two levels higher up
> and those people tend not to have an emotional bond to VMS and they also
> want to take what they perceive as the safer decision (both for them and
> for their pension.)
>
> Saying that a port to x86-64 would be available in about 8 years is
> not the kind of thing that endears you to those types of managers. :-)
>
>> 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.
>>
>
> Alpha not so much, because full system emulation is available.
>
> But yes, for Itanium, when replacement physical boxes are no longer
> available is when the real problems start to occur.
>
> It really is a pity that a full system emulator was never developed
> for the Itanium architecture. That would have given people a few more
> options.
>
> Simon.
>

Well there's an opportunity for you!

--
Chris

On 2021-11-25, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <sno4v1$efp$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>Compared to later operating system designs the internal design
>>of VMS is a direct product of the 1970s mindset because it is
>>ugly, hard to alter, not modular, full of internal hacks such
>>as jumping internally all over the place and was designed when
>>it was getting close to the end of when assembly language was
>>considered to be both an acceptable system implementation language
>>and an application language.
>
> What's hard to alter? Many people say an alternator is difficult to
> replace. I did one two weeks ago.
>

Have you ever looked inside the Linux internals to see how clean
they are compared to VMS internals ?

A really good starting point would be the VFS layer for plugging in
new filesystems so you can see just how easy and clean it is to add
a new filesystem to Linux compared to adding one to VMS.

Here's an overview document to get you started:

https://www.kernel.org/doc/html/latest/filesystems/vfs.html

Now try doing something like that 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.
>
> LOL. I suppose you could do it in a week. I bow to your greatness.
>

No, I could not Brian. Nowhere near as fast as the experienced people
working on it and they have been at it for 7 years now.

Simon.

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

On 2021-11-26, Chris Townley <news@cct-net.co.uk> wrote:
> On 26/11/2021 18:54, Simon Clubley wrote:
>>
>> Alpha not so much, because full system emulation is available.
>>
>> But yes, for Itanium, when replacement physical boxes are no longer
>> available is when the real problems start to occur.
>>
>> It really is a pity that a full system emulator was never developed
>> for the Itanium architecture. That would have given people a few more
>> options.
>>
>
> Well there's an opportunity for you!
>

I already had a look a while back. :-)

Given the complexity of the architecture, it's a massive undertaking
and required quite a bit of access to documents, firmware and knowledge
that was not public (or at least I could not find the materials).

Start with the system firmware. That's locked up behind a HPE paywall
and is not freely available.

Simon.

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

On 2021-11-25, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>
> Trolling and changing the thread subject line does not excuse you from
> answering the question I asked. <crickets... in November nonetheless>
>
> Troll, troll troll, the troll is marching...
>

I already answered your question Brian as you would have seen if you
had actually read my replies.

It turns out that the reason those arguments are available to the called
function is because VMS needs to preserve those registers across the AST
call and some bright spark during the design of VMS thought it was
acceptable to push those registers onto a user-visible call frame instead
of storing them in a private area that the called AST function did not
have access to.

That's the kind of design decision that was so insane it should never
have passed a design review but at least it appears to have been fixed
in later architectures with a private storage area, just like it should
have been on VAX.

And the reason I thought it _must_ be Macro-32 related was because the
real reason was so crazy it never even occurred to me. :-)

Simon.

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

On 2021-11-26, Félim Doyle <felim.doyle@gmail.com> wrote:
> On Thursday, 25 November 2021 at 15:48:37 UTC, Dave Froble wrote:
>> VMS was designed and implemented for VAX, not generic computers.
>
> As I remember it, VAX/VMS was designed by DEC to be its best ever OS then the VAX hardware was designed and built to run it not the other way around. There were probably some mistakes made, unforeseen implementation issues and some miscommunications during parallel development of the hardware and software but the facilities that this combination provided, especially in comparison to the price range of other systems at the time, was revolutionary.
>

One of the biggest mistakes made is that DEC went to the trouble of
implementing a 4-mode architecture and then completely blew how it was
used.

That 4-mode architecture could have provided some really truly radical
internal security separation within VMS, but once you are in any of the
3 inner modes, you can get to any of the other inner modes so all those
extra modes were wasted from a security isolation point of view.

In case you are wondering, you can escalate from supervisor mode because
DCL has access to the privileges of the programs it runs even though it
doesn't actually need them. That kind of thing should have stayed within
the kernel so DCL never sees those privileges.

Just yet another VMS design "feature". :-)

Simon.

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

On 2021-11-26, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> But there is the rub. VSI does have customers but based on the
> comments I am still seeing here the numbers may be decreasing.
> And people may be getting concerned about the time scale.
>

Longer term, they have not done themselves any favours with those
time-limited production licences either.

I wonder how many potential VSI customers that decision has scared off.

Simon.

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

On Friday, November 26, 2021 at 2:41:59 PM UTC-5, Simon Clubley wrote:
> On 2021-11-26, Félim Doyle <felim...@gmail.com> wrote:
> > On Thursday, 25 November 2021 at 15:48:37 UTC, Dave Froble wrote:
> >> VMS was designed and implemented for VAX, not generic computers.
> >
> > As I remember it, VAX/VMS was designed by DEC to be its best ever OS then the VAX hardware was designed and built to run it not the other way around. There were probably some mistakes made, unforeseen implementation issues and some miscommunications during parallel development of the hardware and software but the facilities that this combination provided, especially in comparison to the price range of other systems at the time, was revolutionary.
> >
> One of the biggest mistakes made is that DEC went to the trouble of
> implementing a 4-mode architecture and then completely blew how it was
> used.
>
> That 4-mode architecture could have provided some really truly radical
> internal security separation within VMS, but once you are in any of the
> 3 inner modes, you can get to any of the other inner modes so all those
> extra modes were wasted from a security isolation point of view.
>
> In case you are wondering, you can escalate from supervisor mode because
> DCL has access to the privileges of the programs it runs even though it
> doesn't actually need them. That kind of thing should have stayed within
> the kernel so DCL never sees those privileges.
>
> Just yet another VMS design "feature". :-)
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
I find these kind of comments somewhat offensive since it is easy to criticize the decisions of people made 40 years ago using the context of knowledge today. VMS was designed as a cooperative pairing of both hardware and software. The use of R0 and R1 was for consistency across calls and had nothing to do with MACRO32 at all. Bliss used the same register conventions. If the VMS and VAX engineers knew in the late 70's what was known now, I suspect things would have been done differently.

On 11/26/2021 2:26 PM, Simon Clubley wrote:
> And the reason I thought it _must_ be Macro-32 related was because the
> real reason was so crazy it never even occurred to me. :-)

So anything you don't know why is by default a Macro-32 problems??

Arne

On 11/26/2021 3:31 PM, abrsvc wrote:
> On Friday, November 26, 2021 at 2:41:59 PM UTC-5, Simon Clubley wrote:
>> On 2021-11-26, Félim Doyle <felim...@gmail.com> wrote:
>>> On Thursday, 25 November 2021 at 15:48:37 UTC, Dave Froble wrote:
>>>> VMS was designed and implemented for VAX, not generic computers.
>>>
>>> As I remember it, VAX/VMS was designed by DEC to be its best ever OS then the VAX hardware was designed and built to run it not the other way around. There were probably some mistakes made, unforeseen implementation issues and some miscommunications during parallel development of the hardware and software but the facilities that this combination provided, especially in comparison to the price range of other systems at the time, was revolutionary.
>>>
>> One of the biggest mistakes made is that DEC went to the trouble of
>> implementing a 4-mode architecture and then completely blew how it was
>> used.
>>
>> That 4-mode architecture could have provided some really truly radical
>> internal security separation within VMS, but once you are in any of the
>> 3 inner modes, you can get to any of the other inner modes so all those
>> extra modes were wasted from a security isolation point of view.
>>
>> In case you are wondering, you can escalate from supervisor mode because
>> DCL has access to the privileges of the programs it runs even though it
>> doesn't actually need them. That kind of thing should have stayed within
>> the kernel so DCL never sees those privileges.
>>
>> Just yet another VMS design "feature". :-)
>> Simon.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
> I find these kind of comments somewhat offensive since it is easy to criticize the decisions of people made 40 years ago using the context of knowledge today. VMS was designed as a cooperative pairing of both hardware and software. The use of R0 and R1 was for consistency across calls and had nothing to do with MACRO32 at all. Bliss used the same register conventions. If the VMS and VAX engineers knew in the late 70's what was known now, I suspect things would have been done differently.
>

Yeah, hindsight can be 20/20.

If the Wright bros knew what is known now, they would have flown an F22 Raptor,
or maybe a 747, at Kittyhawk.

But if they would not have flown the Wright Flyer in 1903, perhaps we would not
have F22s and 747s today.

--
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 11/26/2021 2:26 PM, Simon Clubley wrote:
> it never even occurred to me. :-)

That seems to happen a lot ...

--
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 11/26/2021 1:54 PM, Simon Clubley wrote:
> On 2021-11-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/25/2021 1:25 PM, Simon Clubley wrote:
>>>
>>> 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.
>>
>
> The problem Arne is that in many companies, those who want to stay
> on VMS are not those who actually make the final decision about whether
> to stay on VMS.
>
> Those kinds of decisions are usually made one or two levels higher up
> and those people tend not to have an emotional bond to VMS and they also
> want to take what they perceive as the safer decision (both for them and
> for their pension.)
>
> Saying that a port to x86-64 would be available in about 8 years is
> not the kind of thing that endears you to those types of managers. :-)

Most won't care.

They are only interested in whether there will continue to be HW
available to run VMS on. At a reasonable price.

Whether that is Itanium for 4 years and x86-64 after that or
Itanium for 8 years and x86-64 after that does not matter
much.

There can be exceptions like they want to move VMS to
their on-prem ESXi cluster or to public cloud - then
the date does matter.

>> 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.
>>
>
> Alpha not so much, because full system emulation is available.

True.

> But yes, for Itanium, when replacement physical boxes are no longer
> available is when the real problems start to occur.
>
> It really is a pity that a full system emulator was never developed
> for the Itanium architecture. That would have given people a few more
> options.

Yes.

Arne

On 11/26/2021 2:41 PM, Simon Clubley wrote:
> On 2021-11-26, Félim Doyle <felim.doyle@gmail.com> wrote:
>> On Thursday, 25 November 2021 at 15:48:37 UTC, Dave Froble wrote:
>>> VMS was designed and implemented for VAX, not generic computers.
>>
>> As I remember it, VAX/VMS was designed by DEC to be its best ever
>> OS then the VAX hardware was designed and built to run it not the
>> other way around. There were probably some mistakes made,
>> unforeseen implementation issues and some miscommunications during
>> parallel development of the hardware and software but the
>> facilities that this combination provided, especially in comparison
>> to the price range of other systems at the time, was
>> revolutionary.
>
> One of the biggest mistakes made is that DEC went to the trouble of
> implementing a 4-mode architecture and then completely blew how it
> was used.
>
> That 4-mode architecture could have provided some really truly
> radical internal security separation within VMS, but once you are in
> any of the 3 inner modes, you can get to any of the other inner modes
> so all those extra modes were wasted from a security isolation point
> of view.

When that design was done then it was a good protection against
accidental S and E trashing something.

20-40 years later it was realized that it could have been
good if it also protected against malicious code that
tried to switch to an inner mode.

But what so?

It would also have been great if they had foreseen:
* future HW changes and had done a HAL
* the need for later switching from 32 to 64 bit
* etc.etc.

But looking back that way is a rather futile exercise.

There is an old quote:

"A man who never makes a mistake will never make anything."

Nobody can foresee the future and mistakes are made.

Looking back and figuring out what decisions should have been
made is pointless (unless there is lesson learned for
decisions to be made now).

Arne

In article <snrbgf$7td$3@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-25, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <sno4v1$efp$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>Compared to later operating system designs the internal design
>>>of VMS is a direct product of the 1970s mindset because it is
>>>ugly, hard to alter, not modular, full of internal hacks such
>>>as jumping internally all over the place and was designed when
>>>it was getting close to the end of when assembly language was
>>>considered to be both an acceptable system implementation language
>>>and an application language.
>>
>> What's hard to alter? Many people say an alternator is difficult to
>> replace. I did one two weeks ago.
>>
>
>Have you ever looked inside the Linux internals to see how clean
>they are compared to VMS internals ?

Statement such as yours are purely unfounded without proofs. What is
so *unclean* in the VMS internals? I've never seen a book written as
well as the OpenVMS Internal and Data Structures Manual for Linux. I
demand a proof but not before you answer my question that you have so
completely ignored or skirted around since the inception of this long
thread.

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

I speak to machines with the voice of humanity.

In article <snrcd7$7td$5@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-11-25, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>
>> Trolling and changing the thread subject line does not excuse you from
>> answering the question I asked. <crickets... in November nonetheless>
>>
>> Troll, troll troll, the troll is marching...
>>
>
>I already answered your question Brian as you would have seen if you
>had actually read my replies.
>
>It turns out that the reason those arguments are available to the called
>function is because VMS needs to preserve those registers across the AST
>call and some bright spark during the design of VMS thought it was
>acceptable to push those registers onto a user-visible call frame instead
>of storing them in a private area that the called AST function did not
>have access to.
>
>That's the kind of design decision that was so insane it should never
>have passed a design review but at least it appears to have been fixed
>in later architectures with a private storage area, just like it should
>have been on VAX.

If you really must know, read the "VAX/VMS I&DS at Chapter and Section 7.5
in the V5.2 edition. Oh, I keep forgetting, you despise processor modes,
so that'll just open up this up to more "wank, wank, wank VMS IS NOT UNIX"
hatred you spew.

>And the reason I thought it _must_ be Macro-32 related was because the
>real reason was so crazy it never even occurred to me. :-)

What? What? WHAT? You mean it wasn't because there's something you could
do using C that one could not do with Macro-32? Is that what your saying?
Were you aware that all that "elegant" Murray Hill hieroglyphics you're so
fond of actually gets converted to machine code by these things they call
compilers? On a VAX, that'd be VAX machine code whose assembly is called,
wait for it, Macro-32. The AST mechanism was devised to allow "high level"
languages or C to be used for the AST routine, so why would Macro-32 be ANY
less capable? I knew you couldn't answer this but boy you can sure exhale
volumes of Ye Olde Hot Air.

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

I speak to machines with the voice of humanity.

I've been watching this thread with a mixture of amusement and horror. The
triggering thread regarding AST routines was equally enlightening. In
fact if I ever feel the urge to start a thread here I will probably make
the subject line something like this:

<My Topic>, was: Re: Something Simon Clubley felt strongly about

Purely curiosity to see if it stopped forking :)

So, for Simon...

>> One of the biggest mistakes made is that DEC went to the trouble of
>> implementing a 4-mode architecture and then completely blew how it was
>> used.

Well, a bit like Intel implementing a 4-mode architecture and then having
Microsoft completely blow how it is used?

Note that the OS/2 update that Cutler and Co were originally hired to work
on used 3 of the modes. When Windows looked like becoming a success then
it switched to a Windows upgrade instead. Gates wanted it to run on
consumer hardware, so things got dropped. There are still 4 modes available
and I'm sure VSI are using them.

>> That 4-mode architecture could have provided some really truly radical
>> internal security separation within VMS, but once you are in any of the
>> 3 inner modes, you can get to any of the other inner modes so all those
>> extra modes were wasted from a security isolation point of view.

Put your money where your mouth is. Prove it. Post examples that show a
fundamental flaw rather than an Ooops in a single privileged program.

>> In case you are wondering, you can escalate from supervisor mode because
>> DCL has access to the privileges of the programs it runs even though it
>> doesn't actually need them. That kind of thing should have stayed within
>> the kernel so DCL never sees those privileges.

If this was such a huge fundamental problem I would expect masses of
vulnerability reports. Where are they? Post examples.

When a program runs in a privileged context then those writing the program
obviously need to exercise care. Ideally you enable/disable privileges
in a Just In Time basis and, obviously, when you are operating in a mode
higher than the originating mode any inputs from the lower mode must be
treated with caution. Failing to do this on one occasion does not invalidate
the security model.

I will now scrub my cookies and history back to bedrock which I recommend
after logging in to anything Google related.

On Saturday, November 27, 2021 at 12:46:16 AM UTC-5, Andrew Commons wrote:
> I've been watching this thread with a mixture of amusement and horror. The
> triggering thread regarding AST routines was equally enlightening. In
> fact if I ever feel the urge to start a thread here I will probably make
> the subject line something like this:
>
> <My Topic>, was: Re: Something Simon Clubley felt strongly about
>
> Purely curiosity to see if it stopped forking :)
>
> So, for Simon...
> >> One of the biggest mistakes made is that DEC went to the trouble of
> >> implementing a 4-mode architecture and then completely blew how it was
> >> used.
> Well, a bit like Intel implementing a 4-mode architecture and then having
> Microsoft completely blow how it is used?
>
> Note that the OS/2 update that Cutler and Co were originally hired to work
> on used 3 of the modes. When Windows looked like becoming a success then
> it switched to a Windows upgrade instead. Gates wanted it to run on
> consumer hardware, so things got dropped. There are still 4 modes available
> and I'm sure VSI are using them.
> >> That 4-mode architecture could have provided some really truly radical
> >> internal security separation within VMS, but once you are in any of the
> >> 3 inner modes, you can get to any of the other inner modes so all those
> >> extra modes were wasted from a security isolation point of view.
> Put your money where your mouth is. Prove it. Post examples that show a
> fundamental flaw rather than an Ooops in a single privileged program.
> >> In case you are wondering, you can escalate from supervisor mode because
> >> DCL has access to the privileges of the programs it runs even though it
> >> doesn't actually need them. That kind of thing should have stayed within
> >> the kernel so DCL never sees those privileges.
> If this was such a huge fundamental problem I would expect masses of
> vulnerability reports. Where are they? Post examples.
>
> When a program runs in a privileged context then those writing the program
> obviously need to exercise care. Ideally you enable/disable privileges
> in a Just In Time basis and, obviously, when you are operating in a mode
> higher than the originating mode any inputs from the lower mode must be
> treated with caution. Failing to do this on one occasion does not invalidate
> the security model.
>
> I will now scrub my cookies and history back to bedrock which I recommend
> after logging in to anything Google related.

Every time I see these posts I think "My God, what have I started?"

On 11/28/2021 9:13 AM, John Doppke wrote:

> Every time I see these posts I think "My God, what have I started?"
>

Actually, nothing. This general "conversation" has been going on for some time
now. It's like a tornado, touch down here, touch down there, etc.

--
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 2021-11-27 01:04, VAXman-@SendSpamHere.ORG wrote:
> In article <snrbgf$7td$3@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> On 2021-11-25, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>> In article <sno4v1$efp$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>
>>>> Compared to later operating system designs the internal design
>>>> of VMS is a direct product of the 1970s mindset because it is
>>>> ugly, hard to alter, not modular, full of internal hacks such
>>>> as jumping internally all over the place and was designed when
>>>> it was getting close to the end of when assembly language was
>>>> considered to be both an acceptable system implementation language
>>>> and an application language.
>>>
>>> What's hard to alter? Many people say an alternator is difficult to
>>> replace. I did one two weeks ago.
>>>
>>
>> Have you ever looked inside the Linux internals to see how clean
>> they are compared to VMS internals ?
>
> Statement such as yours are purely unfounded without proofs. What is
> so *unclean* in the VMS internals? I've never seen a book written as
> well as the OpenVMS Internal and Data Structures Manual for Linux. I
> demand a proof but not before you answer my question that you have so
> completely ignored or skirted around since the inception of this long
> thread.

In a way, David is actually completely incorrect. The internals of Linux
is changing all the time. You'll have problems running software more
than a year or two old if it's kernel internal, since the APIs inside
the kernel constantly is changing.

And why is that? Well, obviously because the people writing them and
using them constantly realize ways in which they are not good.

The various BSD systems would be better arguments here. They actually
try to think a little more before doing something, as opposed to Linux,
which is really a case of "do first, think later".

So, no. The claims Simon make are totally unfounded. However, it is
fairly easy to change and evolve in Linux or other Unix like systems,
which shows that there is *something* that is right in there. But it's
not the internals are well designed, stable, and well working.
But there is a simplicitly and modularity, which can be traced back to
Unix of old, which have been a big reason for the good properties in there.
But had the Linux kids been doing things from scratch on their own, it
would most likely have been a mess that noone would have wanted to touch.

Johnny

Johnny Billquist <bqt@softjar.se> wrote:
>
>In a way, David is actually completely incorrect. The internals of Linux
>is changing all the time. You'll have problems running software more
>than a year or two old if it's kernel internal, since the APIs inside
>the kernel constantly is changing.

This is absolutely true, and I am really pissed off about it.

>And why is that? Well, obviously because the people writing them and
>using them constantly realize ways in which they are not good.

It's because there is change for change's sake. I don't see dramatic
improvements taking place.

>The various BSD systems would be better arguments here. They actually
>try to think a little more before doing something, as opposed to Linux,
>which is really a case of "do first, think later".

Yes, BSD is much more sane in their approach to making updates of any
sort, and has avoided fundamental changes away from the Unix model in
the user space as well as the kernel.

>So, no. The claims Simon make are totally unfounded. However, it is
>fairly easy to change and evolve in Linux or other Unix like systems,
>which shows that there is *something* that is right in there. But it's
>not the internals are well designed, stable, and well working.
>But there is a simplicitly and modularity, which can be traced back to
>Unix of old, which have been a big reason for the good properties in there.
>But had the Linux kids been doing things from scratch on their own, it
>would most likely have been a mess that noone would have wanted to touch.

Modularity is a major, major deal here.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2021-11-26 20:26, Simon Clubley wrote:
> It turns out that the reason those arguments are available to the called
> function is because VMS needs to preserve those registers across the AST
> call and some bright spark during the design of VMS thought it was
> acceptable to push those registers onto a user-visible call frame instead
> of storing them in a private area that the called AST function did not
> have access to.

It seems you understand neither how interrupts (hardware or software)
work, nor where the problem actually is here.

> That's the kind of design decision that was so insane it should never
> have passed a design review but at least it appears to have been fixed
> in later architectures with a private storage area, just like it should
> have been on VAX.

No. You're nuts, and don't seem to understand some very simple things.

> And the reason I thought it _must_ be Macro-32 related was because the
> real reason was so crazy it never even occurred to me. :-)

Well, after reading your rants, I'm not sure you even understand what
the problem actually is.

Let's first observe that saving information on the stack when interrupt
happens are both common and normal, and is not unique to VAX or VMS.
All systems do it, even Unix.
What do you think happens when you get a signal? The previous context is
stored on your stack, and your signal handled is called. Exactly the
same as with the AST under VMS. There is literally no difference.

And when writing in assembler, it's all very simple and straight
forward. You don't normally care what's on the stack beyond the possible
arguments have have there that you might need to remove before
returning. In VMS, that would be AST dependent parameters, which are
there for your use, and which you should remove before returning (I
think you need to remove them manually, but I might be misremembering.
You need to do it manually in RSX at least).

Where things go a bit weird is that in some (maybe all?) high level
languages, some additional stack content is exposed in the function
signature. There is absolutely no requirement that they need to be. But
this has nothing to do with VMS, and all to do with the language
implementation in relation to ASTs.
Why DEC choose to expose these elements on the stack to the AST function
is beyond me. You could possibly argue that there could be some reason
for sometimes being able to examine these in order to do something
specific, but in general I can't really think of a good reason, and if I
had designed the language environment, I'd kept them out of visibility.
It would be easy to do this, so it was obviously a conscious decision by
DEC for the high level languages to expose the information.

But again - this do not have anything to do with VMS itself, and VMS
isn't doing anything different than Unix is (well, actually ASTs work
much better than signals, but the reason and context for that should be
a different thread).

Unix on the other hand made the decision that the similar kind of
information on the stack when a signal handler is called is not being
exposed in the function signature.
Makes much more sense if you ask me, but this is something for the C
language, and don't have anything to do with Unix as such. The
information is there on the stack. It's just not exposed to the function.

Johnny

On 11/25/2021 8:01 AM, Simon Clubley wrote:
> On 2021-11-24, Chris Townley <news@cct-net.co.uk> wrote:
>> On 24/11/2021 21:45, Hunter Goatley wrote:
>>> On 11/24/2021 1:14 PM, Simon Clubley wrote:
>>>>
>>>> VMS should have been designed 5-10 years later on than when it was.
>>>>
>>>
>>> In a thread of backpedaling inanities, that has to be the most inane.
>>>
>>> Hunter
>>
>> +1
>>
>
> I am seriously annoyed by that comment Hunter because you have
> completely missed (either accidentally or deliberately) the point
> I am making (and have made before).

I didn't miss your point. Yes, you're right, there are things in VMS
that make it difficult to port to other architectures.

But your comment I quoted above is inane. If VMS had been designed 5--10
years later, I doubt it ever would have existed. DEC wouldn't have been
what they were. VAX would have never been what it was.

VMS is what it is. You might not like it, but it did what it was
supposed to do when it was designed, and it did it very well.

Your comment is like saying that that people shouldn't have developed
cell phones until the smart phone was designed. Building blocks. Sure,
that Nokia flip-phone isn't much now, but we wouldn't be where we are if
it hadn't existed.

VMS was designed when it was designed because they needed it, and its
design was exceptional for what it needed to do. You can't change
history or blame the original designers for not thinking of things that
were difficult to imagine at the time.

--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
goathunter@goatley.com http://hunter.goatley.com/

On 2021-11-26, abrsvc <dansabrservices@yahoo.com> wrote:
> I find these kind of comments somewhat offensive since it is easy to criticize the decisions of people made 40 years ago using the context of knowledge today. VMS was designed as a cooperative pairing of both hardware and software. The use of R0 and R1 was for consistency across calls and had nothing to do with MACRO32 at all. Bliss used the same register conventions. If the VMS and VAX engineers knew in the late 70's what was known now, I suspect things would have been done differently.
>

Hello Dan,

The problem is not the preserving of R0/R1/PC/PS{L}, but the way in
which it was done. This information should be private to the AST
dispatcher that calls the AST routine. It should never be visible
to the called AST routine itself because that is an outright violation
of good modular design and that's as true back when VMS was designed
as it is now.

In case you are familiar with bare metal interrupt programming, you can
compare the calling of an AST routine with the way that an interrupt
handler is called when working with bare metal code or when implementing
an OS itself.

On more advanced MCUs, you can have an assembly language interrupt
dispatcher that calls the actual C language interrupt handler and you
can end up having to save more interrupt state than just the normal
registers in your assembly language interrupt dispatcher.

However, that information is always private to the interrupt dispatcher,
and is _never_ exposed to the interrupt handler itself and this is so
universally true, that I didn't even realise what the AST registers were
being used for until it was pointed out to me.

For example, in one bare metal assembly language interrupt dispatcher
I wrote a while back for an ARM processor and which I was looking at
recently, the dispatcher has to save what is called the priority limiter
register before programming a new value (this allows nested interrupts
to occur).

This is saved onto the stack by the dispatcher before calling the
C language interrupt handler and is restored by the interrupt dispatcher
upon return from the interrupt handler. This information is private
to the dispatcher, it is not visible to the interrupt handler, and
I would never design a system where it was, because that is an utter
violation of modular and good programming practice.

That priority limiter register can be compared to one of those private
AST registers and that's why I consider it so wrong that those private
registers are there in the AST call frame and hence visible to the
called routine as it's an utter violation of good modular design.

Simon.

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

On 2021-11-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/26/2021 2:26 PM, Simon Clubley wrote:
>> And the reason I thought it _must_ be Macro-32 related was because the
>> real reason was so crazy it never even occurred to me. :-)
>
> So anything you don't know why is by default a Macro-32 problems??
>

No. Read my detailed reply to Dan.

In my eyes, there must have been a reason for those registers being
present and only Macro-32 code could have made any use of them if
they were going to be used by the AST routine itself.

I simply had never considered that possibility that private registers
had been exposed to the called AST routine (instead of being stored
privately by the AST dispatcher) for the dispatcher to use on return
from the AST routine.

Simon.

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

On 2021-11-26, Dave Froble <davef@tsoft-inc.com> wrote:
> On 11/26/2021 2:26 PM, Simon Clubley wrote:
>> it never even occurred to me. :-)
>
> That seems to happen a lot ...
>

Hey, you are talking to a person whose favourite programming languages
emphasise good modular programming design and that shapes how you look
at a problem or situation... :-)

Simon.

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

On Monday, November 29, 2021 at 1:51:49 PM UTC-5, Simon Clubley wrote:
> On 2021-11-26, abrsvc <dansabr...@yahoo.com> wrote:
> > I find these kind of comments somewhat offensive since it is easy to criticize the decisions of people made 40 years ago using the context of knowledge today. VMS was designed as a cooperative pairing of both hardware and software. The use of R0 and R1 was for consistency across calls and had nothing to do with MACRO32 at all. Bliss used the same register conventions. If the VMS and VAX engineers knew in the late 70's what was known now, I suspect things would have been done differently.
> >
> Hello Dan,
>
> The problem is not the preserving of R0/R1/PC/PS{L}, but the way in
> which it was done. This information should be private to the AST
> dispatcher that calls the AST routine. It should never be visible
> to the called AST routine itself because that is an outright violation
> of good modular design and that's as true back when VMS was designed
> as it is now.
>
> In case you are familiar with bare metal interrupt programming, you can
> compare the calling of an AST routine with the way that an interrupt
> handler is called when working with bare metal code or when implementing
> an OS itself.
>
> On more advanced MCUs, you can have an assembly language interrupt
> dispatcher that calls the actual C language interrupt handler and you
> can end up having to save more interrupt state than just the normal
> registers in your assembly language interrupt dispatcher.
>
> However, that information is always private to the interrupt dispatcher,
> and is _never_ exposed to the interrupt handler itself and this is so
> universally true, that I didn't even realise what the AST registers were
> being used for until it was pointed out to me.
>
> For example, in one bare metal assembly language interrupt dispatcher
> I wrote a while back for an ARM processor and which I was looking at
> recently, the dispatcher has to save what is called the priority limiter
> register before programming a new value (this allows nested interrupts
> to occur).
>
> This is saved onto the stack by the dispatcher before calling the
> C language interrupt handler and is restored by the interrupt dispatcher
> upon return from the interrupt handler. This information is private
> to the dispatcher, it is not visible to the interrupt handler, and
> I would never design a system where it was, because that is an utter
> violation of modular and good programming practice.
>
> That priority limiter register can be compared to one of those private
> AST registers and that's why I consider it so wrong that those private
> registers are there in the AST call frame and hence visible to the
> called routine as it's an utter violation of good modular design.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

I am so sick and tired of this "holier than thou" attitude along with "I dictate what is correct design" attitude. Look, while new technologies and techniques often make decisions made years ago seem incorrect, you MUST analyze decisions based upon the knowledge at the time. As I stated earlier, it is easy to criticize based on what is known now.

Can you for once provide constructive criticism? I find it hard to believe that you have not produced "the best" OS in the world given your opinion of yourself since you seem to be the only one that knows the right way to do anything ever.