Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!halley!dps
From: dps@halley.UUCP (David Sonnier)
Newsgroups: comp.arch
Subject: Re: How to use silicon (was Re: Intel/MIPS Dhrystone ratio)
Summary: auto-increment does not come at 0 cost
Message-ID: <446@halley.UUCP>
Date: 23 Mar 89 17:14:34 GMT
References: <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp> <24889@amdcad.AMD.COM> <355@bnr-fos.UUCP> <1989Mar21.194914.3284@utzoo.uucp> <15693@winchester.mips.COM> <21931@agate.BERKELEY.EDU>
Reply-To: dps@halley.UUCP (David Sonnier)
Organization: Tandem Computers, Austin, TX
Lines: 26

In article <21931@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes:
>
>The cost is certainly far from 0 if an incrementation has to be "undone"
>when a conditional branch is taken.
>
>   Norm

This is actually the critical point.  It is very difficult to make
auto-increment idempotent.  However, the branch case is not the critical
case (the compiler could handle that).  The critical case is for exception
processing.  In PDP-11 unix(TM), a great deal of software effort is required
to un-increment registers in case of exceptions.  The VAX adds a great
deal of hardware to solve the same problem.  The MIPS Rn000 on the other
hand, simply defines all instructions to be idempotent.  Which means that
if you get an exception, you can simply restart the instruction.

With interrupt processing time being such a critical path in the system,
I think not having auto-increment is a definite win (IMHO).

I think that the most important thing RISC has done for us is to move
system design from "gut feeling" and "neat features" towards real
engineering.  Measure the cost of each feature and quantify the
trade-offs.
-- 
David Sonnier @ Tandem Computers, Inc.  14231 Tandem Blvd.  Austin, Texas  78728
...!{rutgers,ames,ut-sally}!cs.utexas.edu!halley!dps        (512) 244-8394