11–20 of 92 posts
> To not leave you hanging: Intel has an official x86 encoder/decoder library called XED. According to Intel’s XED, as of this writing, there are 1503 defined x86 instructions (“iclasses” in XED lingo), from AAA to XTEST (this includes AMD-specific extensions too, by the way). Straightforward, right? Hopefully this will have either saved you a click or validated your time in reading the article.
How about undocumented instructions? Sandsifter[1] is an interesting project and the video from BlackHat[2] is a good watch. There's also a previous discussion of it on HN[3]. [1] https://github.com/Battelle/sandsifter [2] https://www.youtube.com/watch?v=KrksBdWcZgQ [3] https://news.ycombinator.com/item?id=18179212
I feel sudden urge to write some assembly for fun. Have not done it for at least a couple of years I think.
Then when checking the results are half the speed of what the compiler spits out and the fun is gone. At least that's what happens to me...
I think this is why assembler can be faster many times. Not because I'm better than a compiler. But because the structure of the language nudges you into faster approaches.
> To not leave you hanging: Intel has an official x86 encoder/decoder library called XED. According to Intel’s XED, as of this writing, there are 1503 defined x86 instructions (“iclasses” in XED lingo), from AAA to XTEST (this includes AMD-specific extensions too, by the way). Straightforward, right? Hopefully this will have either saved you a click or validated your time in reading the article.
> Does a non-instruction that is non-defined and unofficially guaranteed to non-execute exactly as if it had never been in the instruction set to begin with count as an x86 instruction? For that matter, does UD2 itself, the defined undefined instruction, count as an instruction?
> To not leave you hanging: Intel has an official x86 encoder/decoder library called XED. According to Intel’s XED, as of this writing, there are 1503 defined x86 instructions (“iclasses” in XED lingo), from AAA to XTEST (this includes AMD-specific extensions too, by the way). Straightforward, right? Hopefully this will have either saved you a click or validated your time in reading the article.
More than 1,500! Holy cow! While having instructions for everything that are slow in early models but can be significantly improved in silicon over time is one way to look at CISC, I genuinely wonder how much silicon is spent on instructions that are so rarely used they'd be better in software. Or to ask another way: how many instructions are in billions of x86 cores that rarely if ever get used? Hmmm...
> To not leave you hanging: Intel has an official x86 encoder/decoder library called XED. According to Intel’s XED, as of this writing, there are 1503 defined x86 instructions (“iclasses” in XED lingo), from AAA to XTEST (this includes AMD-specific extensions too, by the way). Straightforward, right? Hopefully this will have either saved you a click or validated your time in reading the article.
For me the article was well worth it; where else but in ISA discussions can you find gems like the following? > Does a non-instruction that is non-defined and unofficially guaranteed to non-execute exactly as if it had never been in the instruction set to begin with count as an x86 instruction? For that matter, does UD2 itself, the defined undefined instruction, count as an instruction?
ARM has all these variations which make it seem as complicated as x86, but they are distict variations and future CPUs can for example drop 16 bit Thumb fairly clearly.
ARM has also been willing to drop older optional legacy stuff like Java oriented instructions that almost nobody used and Thumb. X86 supports nearly all legacy opcodes, even things like MMX and other obsolete vector operations that modern programs never use.
In short - endless battle between RISC or CISC.
I always think of the AMD 29000.
More than 1,500! Holy cow! While having instructions for everything that are slow in early models but can be significantly improved in silicon over time is one way to look at CISC, I genuinely wonder how much silicon is spent on instructions that are so rarely used they'd be better in software. Or to ask another way: how many instructions are in billions of x86 cores that rarely if ever get used? Hmmm...
I'd also be curious to discover how many distinct x86 instructions gcc can even emit? I expect the answer is "a lot less than all of them."