Article 168003 of comp.os.vms:

On 18 Apr 1997, Glenn C. Everhart wrote:
 
> The NT inner mode scheduling with only 2 modes reminds me rather strongly
> of the way forks are handled in RSX11M and M+, which some of us remember
> well...
> 
> The VMS use of software interrupts was a device to avoid software polling
> that was the alternative...and I'm not at all sure that a 486 or better
> can't be equipped with something comparable. Recall the PIRQ on pdp11
> was at one time a separate circuit...

From memory, the only use of the PIRQ in M/M+ was to fob off an FPP
interupt to level 1...
 
> You can replace multilevel interrupts by suitable software; I've done it
> and so have many others. It may cost some speed (depending on the timings
> of the circuitry in the full path) but the real question is whether
> the resources to do so are available to spare.

An interesting comparison from M+ is the single $FORK que, vs VMS's
multiple levels, and the 4 levels of driver proi as well. The coment was,
that the short code path was as good as prioritizing the fork levels.
Almost all the time you only had one or 0 entries on the fork Q.
Also, if the interupts did burst in all at once, the fork level processes
had a good chance of running in priority order anyway.

But all this changes if you are looking to putting  32-64 or more
CPUs on a memory/IO system that won't die under the load. Then you are
after every bit you can get, and a single fork process just won't even
get off the ground! Hell, a 2 CPU M+ system is hit by modest lock contention
in the kernel.

BTW, dec had the x86 BLISS compilers, and all the rest, so that was
no problem.

~Paul