Path: utzoo!attcan!uunet!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: End-of-buffer interrupt instruction
Summary: Why should all interrupts involve the kernel?
Message-ID: <2567@l.cc.purdue.edu>
Date: 17 Sep 90 12:52:14 GMT
References: <2516@l.cc.purdue.edu> <6838.26e7f109@vax1.tcd.ie> <2123@key.COM> <2128@key.COM>
Organization: Purdue University Statistics Department
Lines: 30

In article <2128@key.COM>, sjc@key.COM (Steve Correll) writes:
> In article <3747@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> > In article <2123@key.COM>, sjc@key.COM (Steve Correll) writes:
> > [about Herman Rubin's proposed support for reading from a buffer]
> > 
> > Why should Herman Rubin's proposed operation involve the UNIX kernel at all?
> > He never asked for that!  Imagine a scheme where we have
> > 
> 	[scheme defined in C++ notation]
> 
> Well, Prof. Rubin _did_ ask for an "interrupt", and most Unix kernels insist
> on being involved in any interrupts. And Unix is not unique in this.

Let me clarify the situation.  There are natural situations arising in 
Monte Carlo where one cannot predict when a buffer will empty.  Steps
can be taken to make it rare.  Therefore, the "natural" way to want to
handle this is to have an interrupt, or exception if you prefer, when
this does happen.  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.

The advantage of an interrupt procedure over a test each time is that
the interrupt is rare, and does not have the costs of the test when it
is not invoked.  It is likely to lengthen the instruction, however.  On
the other hand, an interrupt certainly has much higher costs than the
test when it does cut in.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)