🚀 go-pugleaf

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