Re: Pentium __delay weirdness... the final results (longish)

Gordon Oliver (gordo@telsur.cl)
Tue, 16 Sep 1997 16:52:28 -0400 (CST)

...Harald Koenig says...:
> > Solution 2: make __delay not be an inline function. That way it should not
> > cause problems as it will _always_ be at the same offset.
> >
> > Solution 3: make __delay not be an inline function, and also have it use
> > rdtsc when available (this idea is from H. Peter Anvin). This means
> > adding some sort of check for rdtsc and using a function pointer
> > to choose the appropriate delay. As long as there are fewer bugs
> > in rdtsc than in jump prediction this will be a win (seems likely).
>
> I'd prefer #2 and #3 as long as I don't know a good reason for using
> __delay as inline function.

I'm mailing a separate patch to do #2...

> which gcc options did you use for compilation of the generated asm file ?
> using gcc-2.7.2.1 without any options I don't get all possible offsets.
> check with

ok... so I didn't use any options, and the awk line you sent also prints
out a bunch of numbers... The strange thing about it is that there is
exactly one at each offset, and I don't understand how the address is wrong
for a few of them.

> and what's the number in the 4th column (1st %f) ?

the difference between the actual number of cycles and the average...
it is kind of pointless.

BTW: I have yet another version that doesn't have that, but still has
the problem of some addresses being wrong...

> I've attached both output files (w/o and with nop in the loop)...

I looked at them... much more random than on my pentium.
I was also sent a set of data for the K6, which also has a variation of up
to 3 times (1-3 cycles per loop).
-gordo