Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!tinman.Berkeley.EDU!matloff
From: matloff@tinman.Berkeley.EDU
Newsgroups: comp.arch
Subject: undoing autoincrement
Message-ID: <21971@agate.BERKELEY.EDU>
Date: 23 Mar 89 20:53:18 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: matloff@iris.ucdavis.edu (Norm Matloff)
Organization: EECS, UC Davis
Lines: 25

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

baum@apple.com had asked:

%Why would an autoincrement be undone on a branch?

Suppose there is an instruction containing autoincrement immediately following
a conditional branch instruction.  If the pipe is such that the autoinc is
done during or before the branch decision, the autoinc will have to be undone.

Again, all this depends on whether the pipe is designed that way.

   Norm