Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!ut-sally!husc6!mit-eddie!ll-xn!ames!oliveb!intelca!mipos3!cpocd2!howard
From: howard@cpocd2.UUCP
Newsgroups: comp.arch
Subject: Re: register windows
Message-ID: <933@cpocd2.UUCP>
Date: Wed, 21-Oct-87 21:54:59 EDT
Article-I.D.: cpocd2.933
Posted: Wed Oct 21 21:54:59 1987
Date-Received: Sat, 24-Oct-87 21:24:44 EDT
References: <201@PT.CS.CMU.EDU>
Reply-To: howard@cpocd2.UUCP (Howard A. Landman)
Organization: Intel Corp. ASIC Systems Organization, Chandler AZ
Lines: 63
Keywords: register windows, interrupt latency

In article <201@PT.CS.CMU.EDU> lindsay@K.GP.CS.CMU.EDU (Donald Lindsay) writes:
>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.)

The argument is simply that this approach leads to the best average
performance.  Which it does.

The CISC argument is then that everything has to be optimized, even if
it's rare and optimizing it (locally) adversely affects overall cost and
performance.  Optimizing everything is the same as optimizing nothing.

>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.

"Which customer" is the one you based your studies on.  This gives you a
clean target and a clear metric for choosing between design variations.

Lack of a multiplier in the RISC-I was more due to lack of student design
time than anything else.  This has nothing to do with RISC.  Many RISC
machines have multipliers.  (E.g. MIPS-R2000)

>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.

Not necessarily.  Many interrupts can be handled almost like procedure
calls in some RISC architectures, so all you need to save is (possibly)
one register frame.  The "original" RISC architecture, the IBM 801, I
believe had a separate set of registers for interrupts (I'm possibly confusing
this with another machine, but the idea is certainly practical and provides
an easy counterexample to Donald's sweeping generalization).  Task switch is
harder to do well, agreed, but it occurs about 1/100th as often as call/return.

All these concerns are addressed in the early RISC papers.  Why bring them up
now, unless you haven't read those papers?

>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.

You seem to have a very narrow idea of "slow".  Interrupt latency counts,
but program execution time doesn't?  Give me a break!

>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.

And many people write in assembler because they have atrocious compilers,
which are in part due to overly complicated architectures.  It is better
to program in HLL when possible, which supports the notion of hardware
designed for compilers instead of the other way round.  This is where
RISC began.

-- 
	Howard A. Landman
	{oliveb,hplabs}!intelca!mipos3!cpocd2!howard	<- works
	howard%cpocd2%sc.intel.com@RELAY.CS.NET		<- recently flaky
	howard%cpocd2.intel.com@RELAY.CS.NET		<- ??? try this