Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: How to use silicon (was Re: Intel/MIPS Dhrystone ratio)
Message-ID: <27757@apple.Apple.COM>
Date: 23 Mar 89 18:04:48 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: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 32

[]
>In article <21931@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes:
>>In article xxx henry@utzoo.uucp (Henry Spencer) writes:

>>>Autoincrement addressing modes simply aren't a worthwhile investment.
>
>>Really, this isn't an absolutely obvious conclusion.   There are certainly
>>intruction encodings, pipelines, register file designs where the incremental
>		       ^^^^^^^^^                                  ^^^^^^^^^^^
>>cost of this might be almost zero,in which case one would certainly put it in
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>The cost is certainly far from 0 if an incrementation has to be "undone"
>when a conditional branch is taken.
>
>   Norm

Why would an autoincrement be undone on a branch? Do you mean on a trap?
Besides, who says that the hardware cost for undoing the autoincrement is
significant? It could be that the register wasn't actually updated until
all possible traps have been evaluated, in which case the the cost IS zero.
His statement stands as it is written: there ARE pipelines where the
incremental cost IS zero (oh yes, not counting that pesky extra register
file port. That's when you have to decide if it is worth it).
 It seems to me that optimizing compilers can figure out when to use 
autoincrement, so by that (RISC) criteria, it shouldn't be counted out.
Only the statistics should count it out, and I ain't seen none ( in either
direction, to be sure).

--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum