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

41–50 of 92 posts

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

#41

Post by irdc »

ConcernedCoder wrote: post #36
thechao wrote: post #32

Earlier quoted context omitted.

_mm256_movemask_epi8, i.e., the "fast lexer" instruction. That instruction takes ~3c (depending on uarch), and the ARM equivalent (7-8 instructions) takes ~5-6c (depending on uarch). It's just annoying .

This instruction does quite a bit of leg work, and it becomes obvious why a RISK architecture would need 7-8 instructions to do the same, see: https://software.intel.com/sites/landingpage/IntrinsicsGuide...

This looks like a task for gorc: https://five-embeddev.com/riscv-bitmanip/draft/bext.html#gen...

(granted, that’s only 32/64 bits, but still…)

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

#42

Post by account4mypc »

wglb wrote: post #34
anyfoo wrote: post #15

Earlier quoted context omitted.

Curious, does anyone actually care about the actual number primarily? I thought pretty much everyone who clicks on an article with that title would do so because they are interested in the insights gathered when getting to that number.

If you are writing a disassembler or binary program decoder, such a number will help you be sure that you enumerate all the instructions.

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

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

#44

Post by akira2501 »

thechao wrote: post #27
api wrote: post #18

Earlier quoted context omitted.

It's way easier to determine instruction length on ARM. It's usually fixed. That eliminates a lot of brute force thrashing that X86 decoders have to do. It doesn't impact transistor count all that much on a huge modern CPU but it saves a decent amount of power. It's one of the things that factors into why ARM is so power efficient. ARM has also been willing to drop older optional legacy stuff like Java oriented instr…

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.

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

#45

Post by Out_of_Characte »

account4mypc wrote: post #42
wglb wrote: post #34

Earlier quoted context omitted.

If you are writing a disassembler or binary program decoder, such a number will help you be sure that you enumerate all the instructions.

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.

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

#46

Post by bogomipz »

thechao wrote: post #27
api wrote: post #18

Earlier quoted context omitted.

It's way easier to determine instruction length on ARM. It's usually fixed. That eliminates a lot of brute force thrashing that X86 decoders have to do. It doesn't impact transistor count all that much on a huge modern CPU but it saves a decent amount of power. It's one of the things that factors into why ARM is so power efficient. ARM has also been willing to drop older optional legacy stuff like Java oriented instr…

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.

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?

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

#47

Post by Symmetry »

bogomipz wrote: post #46
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.

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 that to something like utf8 where that isn't possible.

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

#48

Post by bogomipz »

Symmetry wrote: post #22
mobilio wrote: post #2

In short - endless battle between RISC or CISC.

These days RISC is mostly about regular encoding of instructions which don't present challenges to doing precise interrupts on a deeply pipelined machine rather than just few instructions per se .

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?

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

#49

Post by ketralnis »

wglb wrote: post #34
anyfoo wrote: post #15

Earlier quoted context omitted.

Curious, does anyone actually care about the actual number primarily? I thought pretty much everyone who clicks on an article with that title would do so because they are interested in the insights gathered when getting to that number.

If you are writing a disassembler or binary program decoder, such a number will help you be sure that you enumerate all the instructions.

I doubt most people reading the article coming from HN are writing disassemblers, and all such people would have to read it anyway because the number itself isn't sufficient to validate that you've enumerated all of them (because as my sibling points out, it's more complicated than that). The specific number is the least interesting part.

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

#50

Post by atq2119 »

thechao wrote: post #27
api wrote: post #18

Earlier quoted context omitted.

It's way easier to determine instruction length on ARM. It's usually fixed. That eliminates a lot of brute force thrashing that X86 decoders have to do. It doesn't impact transistor count all that much on a huge modern CPU but it saves a decent amount of power. It's one of the things that factors into why ARM is so power efficient. ARM has also been willing to drop older optional legacy stuff like Java oriented instr…

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 instructions as 2/4/6/8 bytes (or whatever) in length.

FWIW, this is exactly what RISC-V does.

Post reply on HN