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

[Simon Clubley]

On 2021-11-28, Johnny Billquist <bqt at softjar.se> wrote:
> 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.
>

I actually do understand how all this works (or should work). Read my
reply to Dan.

I write bare metal assembly language dispatchers that call C language
interrupt handlers on a regular basis, and they sometimes need to store
information outside of the usual registers. That information is always
private to the interrupt dispatcher, not the C language interrupt handler.

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

I'm not nuts. I just have some firm opinions about how it should work... :-)

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

This is the bit I simply don't get either.

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

This is how I design my own bare metal setups and it works robustly
and cleanly. The information is still on the stack, but it is strictly
outside of the bounds of the stack space that the called routine is
allowed to touch or view. The information is considered to belong to
the dispatcher and _not_ to the routine the dispatcher calls.

Simon.

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