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

x86 prefixes and escape opcodes flowchart

soc.me

Post reply on HN
Print view View original

41–50 of 53 posts

Re: x86 prefixes and escape opcodes flowchart

#41

Post by Nzen »

mghackerlady wrote: post #29
koito17 wrote: post #24

Earlier quoted context omitted.

The fact sites do evil things with these headers is why I configure Firefox with network.http.referer.XOriginTrimmingPolicy set to 2. It "breaks" sites, but often in good ways (such as the site in TFA).

Referrer links are a dumb idea. Why the hell do you want to know where I'm coming from other than to track me

For targeting advertising expendatures at the site level. If most of my traffic, as revealed by referrer links, comes from social-media-platform-foo and only a little from social-media-platform-bar, then I am likely to spend more on ads from foo than from bar. I'll grant that it is a noisy measure, but doesn't need to be about tracking a particular individual.

Re: x86 prefixes and escape opcodes flowchart

#42

Post by mghackerlady »

Nzen wrote: post #41
mghackerlady wrote: post #29

Earlier quoted context omitted.

Referrer links are a dumb idea. Why the hell do you want to know where I'm coming from other than to track me

For targeting advertising expendatures at the site level. If most of my traffic, as revealed by referrer links, comes from social-media-platform-foo and only a little from social-media-platform-bar, then I am likely to spend more on ads from foo than from bar. I'll grant that it is a noisy measure, but doesn't need to be about tracking a particular individual.

Businesses survived just fine before this. Do personalised ads earn more money? Maybe. But they're invasive and if the governments bowed down to the people instead of corporations they'd be just as illegal as stalking a potential customer to harass them when they're most likely to see you

Re: x86 prefixes and escape opcodes flowchart

#44

Post by adrian_b »

jcranmer wrote: post #35
adrian_b wrote: post #30

Earlier quoted context omitted.

Not at all. The correct behavior for allowing future extensions has already been introduced by Intel with 80186, in 1982, which has introduced an invalid instruction exception, to be used for all undefined instruction opcodes. This behavior was unlike 8086/8088, which happily executed any undefined instructions, most of them being aliases to defined instructions. For any opcode where current CPUs generate invalid ins…

There is utility for having a reserved set of opcode space for "NOP if you don't know what the semantics are, but later ISAs may attach semantics for it," because this allows you to add various instructions that merely do nothing on processors that don't support them. The ENDBR32/ENDBR64 instructions for CET, XACQUIRE/XRELEASE hints for LOCK, the MPX instructions, the PREFETCH instructions all use reserved NOP space…

This is true, but the encoding space reserved for future extensions that is interpreted as NOP should be many times smaller than the space for encodings that generate the invalid instruction exception.

The reason is that the number of useful instructions that are only performance hints or checks for some exceptional conditions, so that if they are ignored that does not have bad consequences, is very limited.

For the vast majority of instruction set extensions, not executing the new instructions completely changes the behavior of the program, which is not acceptable, so the execution of such programs must be prevented on older CPUs.

Regarding the order of prefixes, Intel has made mistakes in not specifying it initially in 8086 and in allowing redundant prefixes. The latter has been partially corrected in later CPUs by imposing a limit for the instruction length.

Because of this lack of specification, the various compilers and assemblers have generated any instruction formats that were accepted by an 8088, so it became impossible to tighten the specification.

However, what is really weird is why Intel and AMD have continued to accept incrorrect instruction encodings even after later extensions of the ISA that clearly specified only a certain encoding to be valid, but in reality the CPUs also accept other encodings and now there are programs that use those alternative encodings that were supposed to be invalid.

Re: x86 prefixes and escape opcodes flowchart

#45

Post by jcranmer »

adrian_b wrote: post #44
jcranmer wrote: post #35

Earlier quoted context omitted.

There is utility for having a reserved set of opcode space for "NOP if you don't know what the semantics are, but later ISAs may attach semantics for it," because this allows you to add various instructions that merely do nothing on processors that don't support them. The ENDBR32/ENDBR64 instructions for CET, XACQUIRE/XRELEASE hints for LOCK, the MPX instructions, the PREFETCH instructions all use reserved NOP space…

This is true, but the encoding space reserved for future extensions that is interpreted as NOP should be many times smaller than the space for encodings that generate the invalid instruction exception. The reason is that the number of useful instructions that are only performance hints or checks for some exceptional conditions, so that if they are ignored that does not have bad consequences, is very limited. For the…

The prefix structure has been enforced starting with the VEX prefixes (which is a lot later than it should have; AMD made a mistake not enforcing more rules around the REX prefix). The legacy prefixes are of course an unfixable mess because of legacy.

Re: x86 prefixes and escape opcodes flowchart

#46

Post by SilentM68 »

koito17 wrote: post #24
debugnik wrote: post #2

This site redirects to HN when it notices HN in the referrer.

The fact sites do evil things with these headers is why I configure Firefox with network.http.referer.XOriginTrimmingPolicy set to 2. It "breaks" sites, but often in good ways (such as the site in TFA).

Got same issue with Edge, but works with Firefox :)

Re: x86 prefixes and escape opcodes flowchart

#47

Post by adrian_b »

adgjlsfhk1 wrote: post #32
themafia wrote: post #9

Earlier quoted context omitted.

Awful compared to what? I've seen benchmarks that go both ways in terms of a "winner" but in terms of overall variance there seems to be very little. There are some cases where ARM64 or RISCV do better and there are some cases where x86_64 does better. I can't see code density being a relevant factor when picking one ISA over another. We've got good compilers now anyways.. outside of power consumption.. the ISA wars…

> outside of power consumption. This is a pretty huge caveat. >90% of cpus are <1W (usb cables, wifi cards, storage controllers etc), and 99% are <10W (phones, lots of laptops)

You are right about the order of magnitude of the percentages, but the CPUs The vast majority of laptops and mini-PCs uses more powerful CPUs. While 15 W CPUs were normal many years ago, when Intel launched the "Ultrabook" campaign, in recent years, due to better cooling, most laptops and mini-PCs use 25 W to 30 W CPUs, and a significant fraction of them (bigger than the fraction of the laptops/mini-PCs that uses <=10 W CPUs) uses CPUs with a TDP between 35 W and 65 W.

Re: x86 prefixes and escape opcodes flowchart

#48

Post by adgjlsfhk1 »

adrian_b wrote: post #47
adgjlsfhk1 wrote: post #32

Earlier quoted context omitted.

> outside of power consumption. This is a pretty huge caveat. >90% of cpus are <1W (usb cables, wifi cards, storage controllers etc), and 99% are <10W (phones, lots of laptops)

You are right about the order of magnitude of the percentages, but the CPUs The vast majority of laptops and mini-PCs uses more powerful CPUs. While 15 W CPUs were normal many years ago, when Intel launched the "Ultrabook" campaign, in recent years, due to better cooling, most laptops and mini-PCs use 25 W to 30 W CPUs, and a significant fraction of them (bigger than the fraction of the laptops/mini-PCs that uses <=1…

Lots of laptops have ~30W cpus, but that's peak usage. A typical laptop has a ~50WH battery, and a ~5W screen. If it's getting 5hr battery life, that means the CPU is averaging <5W.

Re: x86 prefixes and escape opcodes flowchart

#49

Post by adgjlsfhk1 »

st_goliath wrote: post #10

Fun little tidbit: The 0x40-0x4f range used for the REX prefix actually clashes with the single-byte encodings for increment/decrement. When AMD designed the 64 bit extension, they had run out of available single-byte opcodes to use as a prefix and decided to re-use those. The INC/DEC instructions are still available in 64 bit mode, but not in their single-byte encodings.

It is still crazy to me that intel though having 2 1 byte instructions for something that could just be coded as a single add with immediate instruction (which they had anyway).

Re: x86 prefixes and escape opcodes flowchart

#50

Post by adrian_b »

adgjlsfhk1 wrote: post #48
adrian_b wrote: post #47

Earlier quoted context omitted.

You are right about the order of magnitude of the percentages, but the CPUs The vast majority of laptops and mini-PCs uses more powerful CPUs. While 15 W CPUs were normal many years ago, when Intel launched the "Ultrabook" campaign, in recent years, due to better cooling, most laptops and mini-PCs use 25 W to 30 W CPUs, and a significant fraction of them (bigger than the fraction of the laptops/mini-PCs that uses <=1…

Lots of laptops have ~30W cpus, but that's peak usage. A typical laptop has a ~50WH battery, and a ~5W screen. If it's getting 5hr battery life, that means the CPU is averaging <5W.

True, but if you are classifying the CPUs by their idle power consumption, then that is completely unrelated to the ISA implemented by the CPU and even the correlation with the power consumed at maximum load is very weak.
Post reply on HN