Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!rochester!PT.CS.CMU.EDU!K.GP.CS.CMU.EDU!lindsay
From: lindsay@K.GP.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: register windows
Message-ID: <201@PT.CS.CMU.EDU>
Date: Mon, 19-Oct-87 10:28:04 EDT
Article-I.D.: PT.201
Posted: Mon Oct 19 10:28:04 1987
Date-Received: Tue, 20-Oct-87 05:58:30 EDT
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 25
Keywords: register windows, interrupt latency


I posted yesterday on the subject of minimizing the traffic required to save
and restore registers.

There are those who argue that interrupts and task switches are enormously
rare compared to subroutine calls and returns. They are right. They then
argue that the rare events can be penalized, if this makes the common events
run faster. (The RISC argument, if you will.)

I don't agree. There's the issue of "rare for which customer".  The HP
Spectrum addresses this by allowing differing resource mixes, so for
example, a customer who does a lot of multiplies can have a multiplier.

There's also the issue of "rare but critical". This brings me back to
register window state. If it's big, then interrupt latency and task-switch
latency are high. This affects more than just the upper bound on interrupt
rate. Interrupts may be announcing important events, and you want to get to
work. Aside from any costs due to slow response, there is the fact that a
slow chip just won't be as widely useful, or used. Also, machine features
tend to determine programming style. This is usually a pity. For example,
many device drivers are subroutine packages, rather than full processes,
simply because "faster" dominated "cleaner" at design time.

-- 
	Don		lindsay@k.gp.cs.cmu.edu    CMU Computer Science