Path: utzoo!attcan!uunet!nih-csl!lhc!adm!cmcl2!yale!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!charon!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: speculative execution
Message-ID: <2326@charon.cwi.nl>
Date: 12 Oct 90 11:21:00 GMT
References: <PHILIP.90Oct11102731@beeblebrox.dle.dg.com> <2321@charon.cwi.nl> <1990Oct11.191126.21408@rice.edu>
Sender: news@cwi.nl
Organization: CWI, Amsterdam
Lines: 49

I write:
 >There is another aspect: after
 >the three pfmul instructions the pipeline is filled in an indeterminate
 >state if the false path is to be taken.  There might be an overflow status
 >or somesuch pending in the last stage, and that must be cleared.
 > 
Preston Briggs responds:
 > The pipe would have to be drained, but we must always drain the
 > pipe anyway.  So, if at some later point in the program,
 > I perform a multiply, the first 3 pfmul's must direct
 > their (unspecified) values into f0.  But we always have to
 > do this anyway.  And, as you point out, a scalar (non-pipelined)
 > multiply will overwrite the pipe.
As far as I understand the processor this is still wrong:
 > So, if we'd had an if-then-else instead, we might get this result.
 >            int-1, pfmul.ss f3,f4,f0     <--- These floats hoisted from
 >            int-2, pfmul.ss f0,f0,f0     <--- from the then clause
 >            int-3, pfmul.ss f0,f0,f0
 >            if (something) {
 >                pfmul.ss f0,f0,f5
 >            }
 > 	   else {
 >                pfmul.ss f7,f8,f0	-- draining the pipe
Note the above instruction may generate a result trap because the result of the
multiplication of f3 and f4 is stored in this stage!  (Nowhere in the
documentation do I find that result traps are discarded if the result is
stored in f0.  Documentation even carefully tells us that 'f0 always reads
as 0 whatever is stored in it.')
 > 
 > Note also that the scalar multiply doesn't "clear the pipe"; it just
 > overwrites it with new junk.  We need to be careful to drain this
 > new junk to avoid traps.
Yes, we have to drain this to avoid source traps but not to avoid result
traps: 'After a scalar operation, the values of all pipeline stages of the
affected unit are undefined.  No spurious result-exception traps result
when the undefined values are subsequently stored by pipelined operations;
however, the values should not be referenced as source operands.'

 >                           Recently I tried to use the "r2pt.ss f10,f0,f0"
 > instruction to set the KR register to f10.  Unfortunately, this may
 > provoke a source exception trap from the adder if the multiply
 > pipeline is not in some nice state.
Yes, source exceptions occur when you do use undefined results.

So a scalar multiply does indeed not totally clear the pipe, but clears all
status information.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl