Path: utzoo!attcan!uunet!husc6!purdue!decwrl!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.arch
Subject: Re: Hardware-supported user handlers: examples
Message-ID: <21671@amdcad.AMD.COM>
Date: 18 May 88 17:29:48 GMT
References: <353@cf-cm.UUCP> <3095@edm.UUCP> <20618@think.UUCP> <1988May12.162207.16764@utzoo.uucp> <8722@ames.arc.nasa.gov> <10002@tekecs.TEK.COM>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 29

+-+---------------
| | "Probably because practically every machine in existence routes
| | *all* traps and interrupts to the kernel, which can pass them
| | on to the user if it pleases.  I know of no machine, offhand,
| | whose hardware has any notion of a "user handler"."
| +---------------
| There's the PDP-10, with "Unimplemented User Operations" (UUOs) which
| vector directly to the user's UUO trap handler.  -=- Andrew Klossner
+---------------

Ah, yes, the PDP-10... it trapped 1/2 the UUO's to the user, and 1/2 to
the kernel (for use as system calls). The user UUO's were used by things
like the FORTRAN (and other language) libraries to synthesize "fat"
instructions, like "IO." This was nice since the hardware resolved any
indirection/indexing before taking the trap.

By the way, the KI- and KL-10 processors also reserved a few addresses
in the I/O space to be "unprivileged". That is, I/O instructions (DATAI,
DATAO, CONI, CONO) were allowed to these few addresses from normal user-mode
programs. I'm not sure if this was ever used by anyone...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403