[PATCH]: powerpc documentation: Clarify why twi appears in the i/o macros.

Segher Boessenkool segher at kernel.crashing.org
Tue Dec 12 03:37:19 EST 2006


>> Except we use a trap with TO=0 so the CPU could optimise the
>> dependency away -- or where does it say this is prohibited?
>
> I don't know that it explicitly says it is prohibited, but Ed Silha
> agreed when I asked him that optimizing this would be against the
> spirit of the architecture, at least.

Yeah true.  Weirder things that go against "the spirit of the
architecture" have happened though :-)

> I don't think the cpu designers
> would bother optimizing this since it wouldn't get them any extra
> performance on any benchmark.

Not directly for this case -- but it might happen as a side
effect of a more general optimisation perhaps.  Who knows.

>> My only nit is I can't find a guarantee that the trap instruction  
>> will
>> have to get the read data as input before it can "report the  
>> exceptions
>> it caused".  Would you have anything on that?  I'll sleep so much  
>> better
>> if I know it's safe :-)
>
> Well, clearly in general the conditional-trap instructions would have
> to see their input operand(s) before they can report an exception,
> since reporting an exception before that would be incorrect behaviour
> - you would end up taking a 700 interrupt when you shouldn't.

I meant for the case where the exceptions it reports are
"no exceptions".  In some cases (like TO=0) the CPU could
short-circuit the evaluation of what exceptions can be
caused before it has all the input data.  As another
(farfetched but perhaps more realistic) example, a CPU that
does a lot of (memory) speculation could decide that an
instruction will not cause an exception, if it doesn't do
so on any of the possible (speculated) paths.

> Your point about TO=0 is reasonable, and something I also worried
> about a little, but Ed Silha didn't seem to think it was a problem.

It would be lovely to get a guarantee about this in the
architecture.  Failing that, what about this comment (edited
from Linas' patch and your mail):


Read operations have additional twi & isync to make sure the read
is actually performed (i.e. the data has come back) before we start
executing any following instructions.

isync is context synchronizing.  In the definition of context
synchronization, the architecture documents say "2.  The operation
is not initiated, or in the case of isync, does not complete, until
all instructions already in execution have completed to a point at
which they have reported all exceptions they will cause".  The twi
conditionally causes an exception depending on the data from the
previous load; on all current CPUs it will not complete until it
sees the data from the load.  Therefore the isync cannot complete
(and allow following instructions to start) until the data from the
load has returned.


Segher




More information about the Linuxppc-dev mailing list