Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!ll-xn!mit-eddie!bloom-beacon!gatech!mcnc!rti!xyzzy!meissner
From: meissner@xyzzy.UUCP (Michael Meissner)
Newsgroups: comp.arch
Subject: Re: User mode trap handlers (was: Is the Intel memory ...)
Message-ID: <876@xyzzy.UUCP>
Date: 18 May 88 16:18:50 GMT
References: <353@cf-cm.UUCP> <3095@edm.UUCP> <20618@think.UUCP> <1988May12.162207.16764@utzoo.uucp>
Reply-To: meissner@xyzzy.UUCP (Michael Meissner)
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 29

In article <1988May12.162207.16764@utzoo.uucp> Henry Spenser writes:
| > ... it traps into SUPERVISOR mode, even though the program
| > that executed the divide instruction was running in USER mode.  Why
| > should a zero-divide need to be handled by the protected kernel,
| > rather than simply trapping to a user handler?
| 
| 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".

The Data General MV series of computers traps many of the fault conditions
(overflow, underflow, etc.) directly into user code.  In our UNIX
implementation, the language runtimes commonly intercept these faults
and turn them into signals via kill, but I've written programs targeted
for the machine that swaps the default handlers with my own.

The machine used to trap segmentation violations (as opposed to normal
page faults) to user mode as well, but we had to retrofit trapping to
the kernel because we wanted to conform to the Government security
guidelines (C2 I think), which mandate that any attempt to read/write
protected code like the kernel be logged.  Nowadays, both the
propriatary and the native UNIX kernels catch segmentation errors,
and call the user handler, since some of our software depends on
using their own handlers.
-- 
Michael Meissner, Data General.

Uucp:	...!mcnc!rti!xyzzy!meissner
Arpa:	meissner@dg-rtp.DG.COM   (or) meissner%dg-rtp.DG.COM@relay.cs.net