> On 07/15/2013 11:53:54 AM, Scott Wood wrote:
> > On 07/15/2013 03:45:36 AM, David Laight wrote:
> >> Also, if the high word changes, there is no need to loop.
> >> Just return the second value with a low word of zero
> >> (the returned count happened while the function was active).
> >
> > That would be more complicated than looping.
I'm not that familiar with the ppc instructions set, but on x86
the equivalent instructions are synchronising ones - so can have
performance penalties, so a few extra 'normal' instructions to
avoid re-reading the timebase counter may be worth while.
The branch for the loop might also be statically predicted 'taken'
leading to a branch misprediction penalty as well.
> That said, it's since been confirmed internally that the low word
> should always be zero when this happens, so we could share the Cell
> workaround code -- as long as we do something special in the timebase
> sync code so that we don't get stuck if the timebase happens to be
> frozen with TBL==0. This would avoid the need for scratch registers
> (other than CR0).
Yes - if the actual errata is that the low word is read one clock
later then the high word then the only illegal value is one where
the low word is zero.
In that case it is sufficient to reread the counter - it can't be
wrong again!
Indeed it is only necessary to read the high part (even if the
code pre-empted for over 2^32 counts, the returned value will
have happened during the designated period).
David
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
