Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!husc6!encore!pinocchio.encore.com
From: jkenton@pinocchio.encore.com (Jeff Kenton)
Newsgroups: comp.arch
Subject: Re: Interrupts in user space
Message-ID: <12743@encore.Encore.COM>
Date: 18 Sep 90 12:54:07 GMT
References: <3783@goanna.cs.rmit.oz.au>
Sender: news@Encore.COM
Lines: 31

From article <3783@goanna.cs.rmit.oz.au>, by ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe):
> In article <12738@encore.Encore.COM>, jkenton@pinocchio.encore.com (Jeff Kenton) writes:
> 
>> With the recent RISC chips (88000, MIPS and i860 come to mind) the overhead
>> of getting the machine state safely saved away in the low level exception
>> code is substantial.
> 
> But you are still thinking in terms of asynchronous interrupts.
> What we're talking about here is a "trap", and there isn't the
> slightest reason why a trap should have to save any more state
> than a procedure call.  The trap is synchronous:  it cannot happen
> at an _arbitrary_ point during the execution of an instruction,

Depends on the specifics.  You gave a VAX example; I had the 88000 in mind.
Even if this occurs as a synchronous trap you need to protect both the OS
kernel and the user code thread which was executing (in case you want to
dismiss the exception and continue).  On the 88000 this means saving at
least the volatile registers, checking the data pipeline for data faults
and letting the floating point unit drain (or take further exceptions).
If you implement this feature using existing hardware and having the MMU
indicate illegal memory access (as someone suggested), the exception is
not even synchronous.  The MMU will indicate a data fault several cycles
after the faulting instruction is issued.

All the world is not a VAX.


----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -----
----- jeff kenton  ---	temporarily at jkenton@pinocchio.encore.com ----- 
-----		   ---  always at (617) 894-4508  ---		    -----
----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -----