Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!sun!amdahl!key!sjc
From: sjc@key.COM (Steve Correll)
Newsgroups: comp.arch
Subject: Re: End-of-buffer interrupt instruction
Message-ID: <2128@key.COM>
Date: 17 Sep 90 04:12:20 GMT
References: <2516@l.cc.purdue.edu> <6838.26e7f109@vax1.tcd.ie> <2123@key.COM> <3747@goanna.cs.rmit.oz.au>
Organization: Key Computer Labs, Fremont, CA
Lines: 23

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.

I don't understand from the C++ code precisely what hardware instruction
you're suggesting--for example, how it will specify the procedure and the
count. But if you're interested, you could define the instruction precisely
and ask some of the experts among the readership to estimate its costs. For
example: If you use existing registers to specify the procedure address and
the count, does that complicate decoding? If you put a pointer in memory, does
that make it complicated for a pipelined processor to restart the instruction
in case of a page fault? If you use a special prefix register, are you adding
context which must be saved?
-- 
sjc@key.com or ...{sun,pyramid}!pacbell!key!sjc 		Steve Correll