cclist at sydex.com
Sun Feb 4 00:52:44 CST 2007
On 4 Feb 2007 at 0:00, Jim Leonard wrote:
> Okay, just making sure. On 486, it was break-even; on Pentium, it was
> indeed faster for most cases to pair instructions. (Although, if you
> wanted to get fancy, you could copy memory even faster by loading 64
> bits at a time into the FPU registers, then storing them out...)
Yeah, but then you wouldn't have code that would run on *any* x86.
To be fair, however, in a bunch of my code, I did have a routine that
mov Is_x86,0 ; assume neither 286 nor 386
cmp ax,sp ; see if the same
jne Init2 ; if not 2/386
inc Is_x86 ; it's at least a 286
sgdt scratch ; stash the GDT
mov al,byte ptr scratch+5
inc Is_x86 ; at least a 386
so I could make use of those 32 bit registers for moving data around
and calculating CRCs and such.
That's one of the awful inequities of "improved" CPUs; something like
processor social economics. A trick used to exploit a faster CPU
will often run more slowly on the lower CPU than if you had left in
the non-tricky code. So the folks with older CPUs sometimes get
penalized additionally through no fault of their own.
On the CDC 6000 machines it was like that. The "Count the one's"
instruction on the fast 6600 ran in something like 8 cycles, while on
the slower 6400, it took 68 (slower than even a floating divide). So
a clever algorithm that used the pop count instruction on the 6600
really smoked; but on the 6400, it could make the speed disparity
between the two systems look much worse.
More information about the cctech