[Info-vax] Pointless Nostalgia: System Service Dispatching

[Johnny Billquist]

On 2016-06-29 11:53, lawrencedo99 at gmail.com wrote:
> This is all water under the bridge now, but I remember something peculiar about the way system services were dispatched on the VAX using the CHMK instruction, particularly.
>
> As I recall from reading the “Internals & Data Structures” manual, each system service was invoked using the “CHMK #<code>” instruction, with a code identifying the system service.
>
> This instruction had to be 4 bytes long. To ensure this (and prevent optimization to short literals by the assembler), the codes were forward-defined in MACRO. This seemed an unnecessarily roundabout way to do things, when you could have just written “CHMK I^#<code>” to force immediate-mode literals.
>
> The other thing was, the CHMx instructions caused traps, not faults. Thus, restartable services (e.g. $HIBER) required the caller’s PC to be backed up by 4 before putting the process on a suitable wait queue. When it was woken up, the CHMK instruction would be automatically re-executed.
>
> This allowed, for example, ASTs to temporarily interrupt a hibernating process, after which the process would return to hibernation, unless a $WAKE had been done in the meantime (perhaps in the AST itself), whereupon the $HIBER call would simply fall through and the process would resume normal execution.
>
> Again, this could have been done a little simpler: why could the CHMx instructions not have triggered a fault (saved PC left pointing at start of instruction) rather than a trap (saved PC pointing at next instruction)? And the saved PSL would have had the FPD bit set. When one of these instructions was executed with FPD set, it would simply fall through as a no-op. Thus, restarting the system service would be as simple as clearing FPD in the saved PSL. The REI would do the rest.
>
> So much more elegant, do you think?
>
> I think the original VAX engineers missed a trick there...

I don't know for sure about VMS here, but if it works the same way as 
RSX, the system calls are never restarted, so no need to backup, and 
thus also no need to figure out the size of the instruction that caused 
the system call. (On a PDP-11 it's trivial, though, as the instruction 
used to cause a system call is fixed size anyway, and would be easy to 
back up and re-execute).

Normally, at the end of an AST, the system will either just directly 
cause the process to go back to sleep, or wake up, depending on why it 
was stopped before, and if those conditions still apply. The system call 
that caused the process to get into this state is not re-executed. That 
would actually be a rather silly waste of time, and potentially cause 
other odd side effect you do not want. Consider a $QIOW for example. If 
you get an AST, you do not want the $QIOW to be reexecuted. You just 
want the process to continue the wait, unless the conditions for the 
wait are now fulfilled.
Also, returning back to user mode at the end of an AST, to only 
immediately do a system call to get back into the kernel again is a 
rather long way for something you want to process. Better just get there 
directly without all that overhead.

And if I'm thus right, then your idea wouldn't really be of that much 
use. And then I really wonder if the CHMx instructions really must be 
coded with a constant as the argument in the first place.

Anyone else who knows some specifics on VMS here who can confirm or correct?

However, all this said, I bet this is something required by Unix on 
VAXen, as you often restart system calls there...

	Johnny