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

31–40 of 53 posts

Re: x86 prefixes and escape opcodes flowchart

#31

Post by colejohnson66 »

self_awareness wrote: post #25
st_goliath wrote: post #8

Earlier quoted context omitted.

If you have JavaScript enabled, that is. JWZ at least does the redirect on the server side. The following is pulled in from ` https://soc.me/assets/js/turnBack.js `: const undesirables = [ "news.ycombinator.com/", // "reddit.com/", // disable temporaily "lobste.rs/" ] ; if (undesirables.find(site => document.referrer.includes(site))) { window.location.replace(document.referrer); } I wonder why Reddit is "temporarily…

Git history doesn't explain it unfortunately https://github.com/soc/soc.me/blame/main/assets/js/turnBack.... Although, when we inspect author's profile on lobste.rs, we'll see that he's banned: https://lobste.rs/~soc [Banned 4 years ago by pushcx: Troll.] Maybe he's banned from HN as well. And this 'undesirables' is a method of taking some kind of revenge.

Last comment was just over 5 years ago.

https://news.ycombinator.com/user?id=soc

Re: x86 prefixes and escape opcodes flowchart

#32

Post by adgjlsfhk1 »

themafia wrote: post #9
snvzz wrote: post #6

This is in no small part why x86 code density is awful despite variable size encoding.

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)

Re: x86 prefixes and escape opcodes flowchart

#33

Post by bonzini »

jxors wrote: post #18

This flowchart hides the most awful parts (IMO) of x86 prefixes: some combinations of prefixes are invalid but still parsed and executed, like combining two segment overrides, or placing a legacy prefix after a REX prefix. The CPU also doesn't care if you use prefixes that aren't valid for a specific instruction, for example a REP on a non-repeatable instruction. The LOCK prefix is the only prefix that makes the sane…

Yes, I wish this was this simple. :) There are many other complications:

* Some instructions require VEX.L or VEX.W to be 0 or 1, and some encodings result in completely different instructions if you change VEX.L.

* Different bits of the EVEX prefix are valid depending on the opcode byte.

* Some encodings (called groups) produce different instructions depending on bits 3-5 of the modrm byte (the second byte after all prefixes). Some encodings further produce different groups depending on whether bits 6-7 (mod) of the modrm byte identifies a register or not.

* Some instructions read a whole vector register but only a scalar if the same instruction has a memory operand. Sometimes this is clear in the manual, sometimes it is not, sometimes the manual is downright wrong.

* Some instructions do not allow using the legacy high-8-bits registers even though they don't do anything with bits 8 and above of the operand: they only want a 32- or 64-bit register as their operand.

* APX (EVEX map 4) looks a lot like legacy map 0, but actually a few instructions were moved there from other maps for good reasons, a few more were moved there for no apparent reason (SHLD/SHRD iirc), and a few more are new.

* REX2 does not extend SSE and AVX instructions to 32 registers even though REX does extend them to 16.

* Intel defines a thing called VEX instruction classes, which makes sense except for a dozen or two instructions where it doesn't. For these, sometimes AMD uses a different class, sometimes doesn't; sometimes AMD's choice makes sense, sometimes it doesn't.

And many more that I found out while writing QEMU's current x86 decoder (which tries to be table based but sometimes that's just impossible).

Re: x86 prefixes and escape opcodes flowchart

#35

Post by jcranmer »

adrian_b wrote: post #30
peterfirefly wrote: post #22

Earlier quoted context omitted.

> The CPU also doesn't care if you use prefixes that aren't valid for a specific instruction, for example a REP on a non-repeatable instruction. This is one of the reasons why the x86 could be extended so much. PAUSE is just REP NOP, for example. Segment prefixes in front of conditional branches were used as static branch prediction hints (which I believe have returned in some newer Intel CPUs). Useful if you want to…

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 (0F0D and 0F18-0F1F opcode space).

Re: x86 prefixes and escape opcodes flowchart

#36

Post by jxors »

bonzini wrote: post #33
jxors wrote: post #18

This flowchart hides the most awful parts (IMO) of x86 prefixes: some combinations of prefixes are invalid but still parsed and executed, like combining two segment overrides, or placing a legacy prefix after a REX prefix. The CPU also doesn't care if you use prefixes that aren't valid for a specific instruction, for example a REP on a non-repeatable instruction. The LOCK prefix is the only prefix that makes the sane…

Yes, I wish this was this simple. :) There are many other complications: * Some instructions require VEX.L or VEX.W to be 0 or 1, and some encodings result in completely different instructions if you change VEX.L. * Different bits of the EVEX prefix are valid depending on the opcode byte. * Some encodings (called groups) produce different instructions depending on bits 3-5 of the modrm byte (the second byte after all…

> Some instructions require VEX.L or VEX.W to be 0 or 1, and some encodings result in completely different instructions if you change VEX.L.

There is even an instruction where AMD got this wrong! VPERMQ requires VEX.W=1, but some AMD CPUs also happily execute it when VEX.W=0 even though that is supposed to raise an exception.

Re: x86 prefixes and escape opcodes flowchart

#37

Post by benj111 »

jxors wrote: post #18

This flowchart hides the most awful parts (IMO) of x86 prefixes: some combinations of prefixes are invalid but still parsed and executed, like combining two segment overrides, or placing a legacy prefix after a REX prefix. The CPU also doesn't care if you use prefixes that aren't valid for a specific instruction, for example a REP on a non-repeatable instruction. The LOCK prefix is the only prefix that makes the sane…

> doesn't behave like the other prefixes: it must be placed last

As in a suffix??? or a post prefix (suf prefix??? Brunch-fix!)

Re: x86 prefixes and escape opcodes flowchart

#38

Post by jxors »

benj111 wrote: post #37
jxors wrote: post #18

This flowchart hides the most awful parts (IMO) of x86 prefixes: some combinations of prefixes are invalid but still parsed and executed, like combining two segment overrides, or placing a legacy prefix after a REX prefix. The CPU also doesn't care if you use prefixes that aren't valid for a specific instruction, for example a REP on a non-repeatable instruction. The LOCK prefix is the only prefix that makes the sane…

> doesn't behave like the other prefixes: it must be placed last As in a suffix??? or a post prefix (suf prefix??? Brunch-fix!)

It must be the rightmost prefix among the prefixes. It also can't be repeated, unlike all other prefixes

Re: x86 prefixes and escape opcodes flowchart

#39

Post by jxors »

vardump wrote: post #19
jxors wrote: post #18

This flowchart hides the most awful parts (IMO) of x86 prefixes: some combinations of prefixes are invalid but still parsed and executed, like combining two segment overrides, or placing a legacy prefix after a REX prefix. The CPU also doesn't care if you use prefixes that aren't valid for a specific instruction, for example a REP on a non-repeatable instruction. The LOCK prefix is the only prefix that makes the sane…

I wonder whether there are some prefixes that cause (some) CPUs to execute the instruction a lot slower.

This is indeed a thing. I believe in general instructions are executed slower when there are more than 4 legacy prefixes. And there are plenty of other timing differences between different microarchitectures
Post reply on HN