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

abrsvc dansabrservices at yahoo.com
Mon Nov 29 13:59:39 EST 2021


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



More information about the Info-vax mailing list