Also because you're permanently locking yourself to yesterday's speed.
> I know of no compiler that generates the Intel string instructions.
The x86 instruction set has over 20 years of cruft. There are entire sections on modern processors dedicated to handling weird addressing modes and complex CISC instructions that are unnecessary now. I don't know the specific reason why 'scasd' isn't generated when he wants it, but I do know that a lot of these special purpose instructions are often superseded by more powerful instructions less than a decade after they are introduced.
In fact, due to the unique awesomeness of x86, sometimes instructions are superseded by inferior instructions. My favorite is 'loop.' Most x86 loops are executed with two instructions -- decrement a counter and jump if not zero (dec/jnz). x86 has a 'loop' instruction that does this operation in one step, yet on modern processors (Athlon and up) it is at least 8 times slower than dec/jnz (http://crackthecode.us/amd64_opt/OptExperiment.html).
How could that be? Does 'loop' handle some edge case or trigger some crufty microcode that slows things down? Nope. Windows 98 relied on the 'loop' instruction for hard-coded timing loops in drivers. The k6-2 executed these very efficiently, and as the processor hit 350 mhz the speed of the processor triggered race conditions making Windows 98 crash. Consumers obviously found fault with AMD for making a chip that was too good, so loop was artificially slowed in the Athlon (and all processors afterward) forever crippling a perfectly good instruction. A wily assembly programmer optimizing for a k6-2 would have dramatically slower execution on tight loops for no good reason.
> I know of no compiler that generates the Intel string instructions.
The x86 instruction set has over 20 years of cruft. There are entire sections on modern processors dedicated to handling weird addressing modes and complex CISC instructions that are unnecessary now. I don't know the specific reason why 'scasd' isn't generated when he wants it, but I do know that a lot of these special purpose instructions are often superseded by more powerful instructions less than a decade after they are introduced.
In fact, due to the unique awesomeness of x86, sometimes instructions are superseded by inferior instructions. My favorite is 'loop.' Most x86 loops are executed with two instructions -- decrement a counter and jump if not zero (dec/jnz). x86 has a 'loop' instruction that does this operation in one step, yet on modern processors (Athlon and up) it is at least 8 times slower than dec/jnz (http://crackthecode.us/amd64_opt/OptExperiment.html).
How could that be? Does 'loop' handle some edge case or trigger some crufty microcode that slows things down? Nope. Windows 98 relied on the 'loop' instruction for hard-coded timing loops in drivers. The k6-2 executed these very efficiently, and as the processor hit 350 mhz the speed of the processor triggered race conditions making Windows 98 crash. Consumers obviously found fault with AMD for making a chip that was too good, so loop was artificially slowed in the Athlon (and all processors afterward) forever crippling a perfectly good instruction. A wily assembly programmer optimizing for a k6-2 would have dramatically slower execution on tight loops for no good reason.
More info: http://support.microsoft.com/kb/192841
http://devforums.amd.com/forum/messageview.cfm?catid=36&...