Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!ubc-cs!alberta!atha!aupair.cs.athabascau.ca!lyndon
From: lyndon@cs.athabascau.ca (Lyndon Nerenberg)
Newsgroups: comp.arch
Subject: Re: End-of-buffer interrupt instruction
Message-ID: <274@aupair.cs.athabascau.ca>
Date: 18 Sep 90 18:47:35 GMT
References: <2516@l.cc.purdue.edu> <6838.26e7f109@vax1.tcd.ie> <2123@key.COM> <2128@key.COM> <2567@l.cc.purdue.edu>
Organization: Athabasca University
Lines: 42

cik@l.cc.purdue.edu (Herman Rubin) writes:
>  Is there any good reason why the user cannot set up
>conditions for interrupts, and handling procedures for them?  I believe
>that some setups allow for these without necessarily invoking the kernel.

I'm reminded of the (undocumented) facility in MTS (Michigan Terminal
System) that allowed the user to intercept addressing exceptions without
going through the full blown exception handling mechanism. Very early
in the exception handling code, the kernel would look at the instruction
following the one that generated the exception. If this was a NOP, the
kernel would extract the address field and use it as a pointer to a user
specified exception handler in user VM space, and branch to it (in user
mode). Although this did involve decending into the kernel somewhat (there's
no way around that in a VM system), it avoided doing a full blown context
switch to supervisor mode.

Programs that liked to poke around in shared system memory (you thought
UNIX security was bad? :-) were littered with statements like:

	.
	.
	.
	MVC   mumble,foo	Move shared mem to user buffer
* Gack, where's my copy of Strubel?!? I can't even remember SS
* instruction syntax! :-(
	NOP   15,MYTRAP		Ack! Fell off shared memory
	.
	.
	.
MYTRAP	EQU   *		Routine to spin through non-existant memory
*			looking for the start of the next valid
*			chunk of VM

I sort of recall that the R field of the NOP instruction was interpreted
as a bitmask that you could use to flag to the supervisor which exceptions
you were willing to handle.

-- 
    Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
        {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca

      The only thing open about OSF is their mouth.  --Chuck Musciano