Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!midway!tank!stephen From: stephen@estragon.uchicago.edu (Stephen P Spackman) Newsgroups: comp.arch Subject: Re: Architecture questions Message-ID: Date: 11 Sep 90 00:11:25 GMT References: <2516@l.cc.purdue.edu> <6838.26e7f109@vax1.tcd.ie> <2531@l.cc.purdue.edu> <4043@auspex.auspex.com> Sender: news@midway.uchicago.edu (News Administrator) Organization: University of Chicago CILS Lines: 20 In-Reply-To: guy@auspex.auspex.com's message of 10 Sep 90 17:14:05 GMT In article <4043@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >There are quite a few situations in transaction processing which could use a >few intelligent instructions, like reading from a buffer with an automatic >interrupt when the buffer becomes empty. This operation localises better in the MMU than in the CPU (which is nice). It's not conceptually difficult to do, either. "Reading from a buffer" in what sense? Is this just an in-memory buffer being read by a transaction processing application - in which case I don't see how an *interrupt* would help, as a dumb old conditional branch testing whether the number of characters left in the buffer was zero would probably be *faster* than an interrupt (no tons of context so save, etc.), or is it something else? Er. You have an 8k buffer. Each branch takes 1 cycle to test, 1 cycle if not taken. There goes 16k cycles. You're telling me that servicing a trap is going to take 16k cycles? stephen p spackman stephen@estragon.uchicago.edu 312.702.3982