Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How many x86 instructions are there? (2016)

fgiesen.wordpress.com

Post reply on HN
Print view View original

61–70 of 92 posts

Re: How many x86 instructions are there? (2016)

#61

Post by bogomipz »

Symmetry wrote: post #56
bogomipz wrote: post #48

Earlier quoted context omitted.

What do you mean by "precise" interrupts here? Do some types of interrupts cause worse pipeline stalls than other types? Are the interrupt handlers in RISC faster because of more efficient decoding? Is that the issue?

No, it's just that the fact that RISC didn't have any load-op-store instructions made it easier to pipeline them back in the day while still being able to handle interrupts as if they executed one instruction at a time and there was one instruction that had executed while the following one hadn't executed at all. That's possible to do with CISC architectures, of course, we do it all the time these days. But back in t…

Thanks these are both very helpful and good bits of historical perspective as well. Cheers.

Re: How many x86 instructions are there? (2016)

#62

Post by thechao »

richardwhiuk wrote: post #38
thechao wrote: post #27

Earlier quoted context omitted.

It's not that variable length is expensive, it's that variable length the way Intel does it is expensive. For instance — not that this is a good idea — you could burn the top 2b to mark instructions as 2/4/6/8 bytes (or whatever) in length. Then you can have your variable-width-cake-and-eat-your-fast-decode-too.

Variable length is always going to restrict the parralelism of your instruction decode (for a given chip area/power/etc cost).

Only because a single instruction would take the "space" of multiple instructions in the I$-fetch-to-decode. The idea with variable-length encodings is that, for example, an 8B encoding does more than twice the work of a 4B encoding, so you lose out on the instruction slot, but win on the work done.

I mean ... that's the theory.

Re: How many x86 instructions are there? (2016)

#63

Post by bogomipz »

akira2501 wrote: post #44
thechao wrote: post #27

Earlier quoted context omitted.

It's not that variable length is expensive, it's that variable length the way Intel does it is expensive. For instance — not that this is a good idea — you could burn the top 2b to mark instructions as 2/4/6/8 bytes (or whatever) in length. Then you can have your variable-width-cake-and-eat-your-fast-decode-too.

> you could burn the top 2b to mark Which seems reasonable.. but you just burned 3/4 of the single opcode instruction space, which may not be worth it for most general purpose loads.

Would you mind elaborating on the math of how the "top 2b" ends up burning 3/4 of the single opcode instruction space?

Re: How many x86 instructions are there? (2016)

#64

Post by saagarjha »

Out_of_Characte wrote: post #45
account4mypc wrote: post #42

Earlier quoted context omitted.

i think if you were writing such a program, this article would show that using such a number is a much more complicated idea than it sounds

Enumerating all instructions would be usefull to check wether you can decode all legal instructions.

The issue is that the list of all legal instructions is hard to define.

Re: How many x86 instructions are there? (2016)

#65

Post by saagarjha »

dreamcompiler wrote: post #16
johnklos wrote: post #9

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."

Probably a couple hundred at most, and for common programs several dozen.

Re: How many x86 instructions are there? (2016)

#66

Post by saagarjha »

snvzz wrote: post #52

The only real answer is: Too Many. This complexity is pushed down to operating systems, compilers, assemblers, debuggers. It ends up causing brutal human time overhead throughout the chain, and its cost effectively prevents security and high assurance. This more than justifies moving away from x86 into RISC architectures, such as the rising open and royalty-free RISC-V.

There is complexity, but it’s not nearly as large as you claim it is, nor does RISC magically resolve the issues you’ve brought up.

Re: How many x86 instructions are there? (2016)

#67

Post by deepspace »

snvzz wrote: post #52

The only real answer is: Too Many. This complexity is pushed down to operating systems, compilers, assemblers, debuggers. It ends up causing brutal human time overhead throughout the chain, and its cost effectively prevents security and high assurance. This more than justifies moving away from x86 into RISC architectures, such as the rising open and royalty-free RISC-V.

> This complexity is pushed down to operating systems, compilers, assemblers, debuggers.

Is that really true though? In my experience, the amount of complexity in a layered system is roughly constant, and if you make one layer simpler, you have to make another more complex.

I would expect that compiler for a RISC architecture, for example, needs to do a lot of work figuring out which set of 'simple' instructions encode an intent most efficiently. It also needs to deal with instruction scheduling and other issues that a RISC compiler does not care about.

Re: How many x86 instructions are there? (2016)

#68

Post by saagarjha »

Symmetry wrote: post #47
bogomipz wrote: post #46

Earlier quoted context omitted.

Could you elaborate - what is about the Intel design that makes the decode so inefficient? Is "2b" bits here? Are there examples of ISA or chips that handle variable length instruction encoding efficiently?

Intel x86 isn't self synchonizing. In theory you have to decode every byte of the instruction stream that came before to be sure where the boundaries of an instruction are. Normally it stabilizes after a while in real world instruction streams but you can craft malicious instruction streams which yield two different valid sets of instructions depending on whether you start reading them at an offset or not. Contrast t…

Note that random x86 code is usually “eventually self-synchronizing”, which id useful if you’re trying to disassemble a blob at a random offset.

Re: How many x86 instructions are there? (2016)

#69

Post by stevemk14ebr »

gbrown_ wrote: post #7

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

Also see https://blog.can.ac/2021/03/22/speculating-x86-64-isa-with-o...
Post reply on HN