Chuck Guzis 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.
True, but you wouldn't want to do the mov; dec; mov; jnz on anything
less than a 386, it's way too slow compared to rep movs.
To be fair, however, in a bunch of my code, I did have
a routine that
started out:
mov Is_x86,0 ; assume neither 286 nor 386
push sp
pop ax
cmp ax,sp ; see if the same
jne Init2 ; if not 2/386
inc Is_x86 ; it's at least a 286
.486
sgdt scratch ; stash the GDT
.8086
mov al,byte ptr scratch+5
test al,al
jnz Init2
inc Is_x86 ; at least a 386
Init2:
so I could make use of those 32 bit registers for moving data around
and calculating CRCs and such.
Hey, that's neat... I've never seen that technique (global descriptor
table) before. I used to check if pushf/popf preserved the Alignment
Check bit (386=no, 486=yes).
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.
As someone whose only computer was a 7MHz 8086 from 1985 to 1991, I was
able to experience this firsthand. I later replaced with an NEC V30 so
that "286" programs would work (99% of the time, the only "286" thing
about a program was SHR/SHL/ROR/ROL by an operand greater than 1, which
the NEC V30 could do) but they certainly didn't work well.
--
Jim Leonard (trixter at
oldskool.org)
http://www.oldskool.org/
Help our electronic games project:
http://www.mobygames.com/
Or check out some trippy MindCandy at
http://www.mindcandydvd.com/
A child borne of the home computer wars:
http://trixter.wordpress.com/