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

[VAXman- at SendSpamHere.ORG]

In article <685f4933-7224-485b-a19a-04e0624b4521n at googlegroups.com>, abrsvc <dansabrservices at yahoo.com> writes:
>On Monday, November 29, 2021 at 1:51:49 PM UTC-5, Simon Clubley wrote:
>> On 2021-11-26, abrsvc <dansabr... at yahoo.com> wrote:=20
>> > I find these kind of comments somewhat offensive since it is easy to cr=
>iticize the decisions of people made 40 years ago using the context of know=
>ledge 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 no=
>thing 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 su=
>spect things would have been done differently.=20
>> >
>> Hello Dan,=20
>>=20
>> The problem is not the preserving of R0/R1/PC/PS{L}, but the way in=20
>> which it was done. This information should be private to the AST=20
>> dispatcher that calls the AST routine. It should never be visible=20
>> to the called AST routine itself because that is an outright violation=20
>> of good modular design and that's as true back when VMS was designed=20
>> as it is now.=20
>>=20
>> In case you are familiar with bare metal interrupt programming, you can=
>=20
>> compare the calling of an AST routine with the way that an interrupt=20
>> handler is called when working with bare metal code or when implementing=
>=20
>> an OS itself.=20
>>=20
>> On more advanced MCUs, you can have an assembly language interrupt=20
>> dispatcher that calls the actual C language interrupt handler and you=20
>> can end up having to save more interrupt state than just the normal=20
>> registers in your assembly language interrupt dispatcher.=20
>>=20
>> However, that information is always private to the interrupt dispatcher,=
>=20
>> and is _never_ exposed to the interrupt handler itself and this is so=20
>> universally true, that I didn't even realise what the AST registers were=
>=20
>> being used for until it was pointed out to me.=20
>>=20
>> For example, in one bare metal assembly language interrupt dispatcher=20
>> I wrote a while back for an ARM processor and which I was looking at=20
>> recently, the dispatcher has to save what is called the priority limiter=
>=20
>> register before programming a new value (this allows nested interrupts=20
>> to occur).=20
>>=20
>> This is saved onto the stack by the dispatcher before calling the=20
>> C language interrupt handler and is restored by the interrupt dispatcher=
>=20
>> upon return from the interrupt handler. This information is private=20
>> to the dispatcher, it is not visible to the interrupt handler, and=20
>> I would never design a system where it was, because that is an utter=20
>> violation of modular and good programming practice.=20
>>=20
>> That priority limiter register can be compared to one of those private=20
>> AST registers and that's why I consider it so wrong that those private=20
>> registers are there in the AST call frame and hence visible to the=20
>> called routine as it's an utter violation of good modular design.
>> Simon.=20
>>=20
>> --=20
>> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP=20
>> 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 di=
>ctate what is correct design" attitude.  Look, while new technologies and t=
>echniques often make decisions made years ago seem incorrect, you MUST anal=
>yze decisions based upon the knowledge at the time.  As I stated earlier, i=
>t 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 o=
>f yourself since you seem to be the only one that knows the right way to do=
> anything ever.

Harrumph!  Harrumph!  Harrumph!

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

I speak to machines with the voice of humanity.