4 ms·

> It looks like the Intel 8086 architecture and its descendents will be with us for ever ... Why not take advantage of every idiosyncrasy of that instruction se

> It looks like the Intel 8086 architecture and its descendents will be with us for ever ... Why not take advantage of every idiosyncrasy of that instruction set? Because ARM.

chubs 15y ago
I was thinking that, but to be fair he gave that talk 4 years ago before the tablet/phone market took off.
- to3m 15y ago
  Additionally, the 8086 is not much like the 386! And the 386 isn't much like the 486, which differed surprisingly from the Pentium. And each subsequent revision has followed this trend of being (at the very least) different enough from its predecessors that assembly language programmers need to re-read the manuals. Today we even have a 64-bit version, which differs from its trail of 32-bit ancestors even more than they differed from one another...
- bluekeybox 15y ago
  If there is one lesson that people in this industry should have learned by now, it is, "never say forever". Or 640Kb of RAM still would have been enough for anybody.
barrkel 15y ago
Processors get tuned for the code that runs on them, and the code that runs on them is generated by compilers which have generally broken down high-level operations into low-level operations to seek out other kinds of optimization opportunities. Idiosyncratic opcodes end up as backwaters because so few general-purpose back ends can target them in broad scenarios. So they receive less focus from chip manufacturers, and their original purpose gets lost; they often end up slower than a handful of the simpler opcodes.
DarkShikari 15y ago
ARM has an a similarly large set of idiosyncrasies.
- wladimir 15y ago
  Like what? I have some experience with ARM assembly, and found it refreshingly simple compared to x86. All registers are handled in the same way, and instructions are very regular. There are fewer instructions and most importantly, every instruction can be used, there are no 'cruft, don't use! slow and old' instructions like in x86. Even MIPS is more peculiar.
wickedchicken 15y ago
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 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://support.microsoft.com/kb/192841 http://devforums.amd.com/forum/messageview.cfm?catid=36&threadid=2494&highlight_key=y http://devforums.amd.com/forum/messageview.cfm?catid=36&...
- sp332 15y ago
  It would have been a good reason to bring back the "Turbo" button :)

> It looks like the Intel 8086 architecture and its descendents will be with us for ever ... Why not take advantage of every idiosyncrasy of that instruction set? Because ARM.

chubs 15y ago

I was thinking that, but to be fair he gave that talk 4 years ago before the tablet/phone market took off.

to3m 15y ago
Additionally, the 8086 is not much like the 386! And the 386 isn't much like the 486, which differed surprisingly from the Pentium. And each subsequent revision has followed this trend of being (at the very least) different enough from its predecessors that assembly language programmers need to re-read the manuals. Today we even have a 64-bit version, which differs from its trail of 32-bit ancestors even more than they differed from one another...
bluekeybox 15y ago
If there is one lesson that people in this industry should have learned by now, it is, "never say forever". Or 640Kb of RAM still would have been enough for anybody.

barrkel 15y ago

Processors get tuned for the code that runs on them, and the code that runs on them is generated by compilers which have generally broken down high-level operations into low-level operations to seek out other kinds of optimization opportunities. Idiosyncratic opcodes end up as backwaters because so few general-purpose back ends can target them in broad scenarios. So they receive less focus from chip manufacturers, and their original purpose gets lost; they often end up slower than a handful of the simpler opcodes.

DarkShikari 15y ago

ARM has an a similarly large set of idiosyncrasies.

wladimir 15y ago
Like what? I have some experience with ARM assembly, and found it refreshingly simple compared to x86. All registers are handled in the same way, and instructions are very regular. There are fewer instructions and most importantly, every instruction can be used, there are no 'cruft, don't use! slow and old' instructions like in x86. Even MIPS is more peculiar.

wickedchicken 15y ago

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 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://support.microsoft.com/kb/192841 http://devforums.amd.com/forum/messageview.cfm?catid=36&threadid=2494&highlight_key=y http://devforums.amd.com/forum/messageview.cfm?catid=36&...

sp332 15y ago
It would have been a good reason to bring back the "Turbo" button :)