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

[Johnny Billquist]

On 2021-12-01 19:32, Simon Clubley wrote:
> On 2021-11-30, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>
>> Now I am confused.
>>
>> I thought the argument was that VMS VAX was doing
>> (and VMS Alpha + VMS Itanium continued to for
>> compatibility reasons):
>>
>> VMS---(5 args)--->AST function
>>
>> and many people would have preferred:
>>
>> VMS---(1 arg)--->AST function
>>
>> The language and language runtimes of the AST function does
>> not matter for that. The arguments are there.
>>
> 
> That is indeed exactly what this is about and you are right in
> what you say above. This is behaviour defined at VMS level, not
> at compiler level.

Right. VMS was doing a bit more than I was expecting. But with that 
said, it's still not purely a VMS issue, although I must admit VMS is 
trying to bend you here.

> Johnny was thinking this may be a compiler issue that exposed the
> extra arguments, not a VMS issue, based on something he appears to
> be seeing in Unix. (I don't have enough internals knowledge in that
> specific part of Unix to know if he's right about that or not.)

No, I wasn't thinking Unix at all. But I was thinking a bit RSX (as 
usual). There, an AST isn't really looking like a normal call sequence. 
So in C for example, you have to explicitly tell the compiler that the 
routine is an AST handler, and the compiler will sort the rest out for you.
But even in VMS, if the language allows for variable number of argument 
functions, you can certainly make it much more transparent.

But you could have done the same as in RSX, and have the functions be 
tagged to be AST handlers, and then the compiler could have done all 
kind of stuff under the hood to make it match just fine.

So even though VMS has one convention for how ASTs are called, any 
language could easily have made it look any other way it wanted.

But yes, VMS encourages a certain pattern.


In Unix, it's simply that a signal handler is always just called with 
one argument (the signal number) and is not supposed to return anything.

Whatever else is saved as a part of dispatching to the signal handler is 
not exposed in the function signature, but of course, if someone wants 
to be creative and reach up into the stack, all kind of stuff is there. 
But it's not standardized, so I doubt anyone would write anything that 
would do this.

And if people want to talk morass, signals in Unix is much worse than 
ASTs. The behavior have changed over the years, as well as what kind of 
function you are supposed to use to install a signal handler. Things 
like what happens if a signal happens while you are in a signal handler, 
and what happens when you return from a signal handler have been sortof 
undefined and have changed over the years. In old times, you could just 
loose signals when you were unlucky.

> However, on VMS, this is very much a part of VMS, is based on VMS
> standards, and is not something done in the compilers. It's just that
> the various compilers react differently to what VMS itself is doing.

Well, languages could still do whatever they want. But yeah, the easy 
way is to just take what VMS gives straight up, and then you get those 
extra arguments that VMS for some reason thought were good to have.

   Johnny