From: Nikodemus S. <nik...@ra...> - 2008-03-13 10:03:44
|
On 3/13/08, Paul Khuong <pk...@gm...> wrote: > Paul Khuong, not Paul K. Huong (the middle initial is a V if you > insist ;). Oops, sorry! > On a more technical note, I am not sure that inserting a > CPUID only before reading the cycle counter is enough. In theory, the > first RDTSC instruction could be moved further and further back in the > pipeline until its results are used. Right. Updated patch attached. > As for other architectures, the %tick register is user-readable on > Solaris 8+/USparc; I'm not sure about its status on linux/USparc, but > CMUCL sources should know: > 2003-02-20 > Experimental support for hardware cycle counters has been added for > x86 and UltraSPARC platforms. This is based on the RDTSC instruction > on Pentium and better processors, and on reading the %TICK register on > UltraSPARC. > > Alpha has the RPCC instruction, for two 32 bit values packed in a > single 64 bit GPR (the higher value is OS dependent, the lower one cpu > dependent). > > Finally, it seems like PPC has mftb (djb's pages seem useful here > <http://cr.yp.to/hardware/ppc.html>). That's good news. > FFTW's "cycle.h" (<www.fftw.org/cycle.h>) has support for such > instructions on all platforms SBCL supports; unfortunately, it's GPL. > We'd have to ask a lawyer about the interactions ;) GPL would taint SBCL, but cycle.h seems to be under 1-clause MIT, so cribbing from there is not problematic. Cheers, -- Nikodemus |