matloff@tinman.Berkeley.EDU (03/24/89)
>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
cik@l.cc.purdue.edu (Herman Rubin) (03/24/89)
In article <21971@agate.BERKELEY.EDU>, matloff@tinman.Berkeley.EDU writes: < <In article <21931@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes: < <>In article xxx henry@utzoo.uucp (Henry Spencer) writes: > > 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. > Why is this problem restricted to autoincrement? Any action taken after a conditional branch instruction not wanted in the actual branch path taken may have to be undone. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (03/24/89)
In article <21971@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes: | 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. I assume that there are a LOT of instructions which shouldn't follow a conditional branch. The compiler should be able to handle that. While I'm not a chip designer, I would assume that the hard part is exceptions. I would assume that the operation would have to be "atomic" in the sense that the IC increment and auto increment would never be separated. Would some of the chip designers like to indicate if that's a bigger problem for RISC than CISC? -- bill davidsen (wedu@crd.GE.COM) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
baum@Apple.COM (Allen J. Baum) (03/25/89)
[] > matloff@iris.ucdavis.edu (Norm Matloff) writes: >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. > Well, suppose that I have an ADD instruction following a conditional branch, and the ADD is evaluated before the branch decision. Do I have to undo the ADD? Whats the difference? Am I missing something here? baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
matloff@winnie.Berkeley.EDU (Norman Matloff) (03/25/89)
In article <13414@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <21971@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes: >| Suppose there is an instruction containing autoincrement immediately followin >| 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 > I assume that there are a LOT of instructions which shouldn't follow a ^^^^^^^^^^^^ >conditional branch. Well, I was really referring to what amounts to a side effect of an instruction, not an instruction itself. E.g. consider an ADD (R0)+,R1. We tend to think of the addition as being "the" execution part of the instruction, and this view is right, in the sense that it would be final stage in the pipe. But the autoinc side effect might be done in an earlier pipe stage. So the point is that if an architecture includes side effects in instructions, then one must design the processor's branch handling logic to not only CANCEL the final stage of the pipe, but also possibly UNDO the already-completed work of an earlier stage of the pipe. The "cancellation" will probably be much less costly to implement -- watch for and execute -- than will be the "undoing." >The compiler should be able to handle that. Sure, the compiler could simply not place any autoincrement instructions following a branch. Aesthetically, this doesn't appeal to me -- translating code differently just because there is a branch -- but of course I agree that IS the best way to handle it. Norm
matloff@bizet.Berkeley.EDU (Norman Matloff) (03/25/89)
In article <27799@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: >Well, suppose that I have an ADD instruction following a conditional branch, >and the ADD is evaluated before the branch decision. Do I have to undo the >ADD? Whats the difference? Am I missing something here? Are you assuming a "multiple resource" CPU, so that instructions might execute out of order? [I was assuming a simple linear pipe, e.g. instr. fetch/decode/operand fetch/execute.] Anyway, in your case you again would have to do more work in undoing an ADD which has autoincrement than a plain ADD without autoincrement, and thus the autoinc wouldn't be "almost free" in this case either. Or am *I* missing something [a real possibility :-) ]? Norm