Re: x86 WBINVD prefix allocations

On 01.09.2026 11:53, Christian Ludloff wrote:
> On Tue, Sep 1, 2026 at 1:32 AM Jan Beulich <[email protected]> wrote:
>>>   0x67 = no CODE hint => skip L0i/L1i cache
>>>   0x66 = no DATA hint => skip L0d/L1d cache
>>>   0xF3 = no INVD hint => skip invalidations
>>>   0xF2 = no LLC  hint => skip LLC cache
>>
>> I view (ab)use of 0x67 as an operation modifying prefix as problematic.
> 
> In an increasingly 64-bit world the classic 0x67
> functionality is becoming... much less relevant.
> 
>>>   0x26 = ES implementation-specific hint
>>>   0x2E = CS implementation-specific hint
>>>   0x36 = SS implementation-specific hint
>>>   0x3E = DS implementation-specific hint
>>>   0x64 = FS implementation-specific hint
>>>   0x65 = GS implementation-specific hint
>>
>> ... allowing combinations of these to mean anything else than "last one
>> takes effect" is pretty much against how x86 has been working. In gas
>> I think you couldn't even encode multiple of them "normally", i.e. without
>> resorting to .byte or alike.
> 
> WBINVD is privileged – so not an app problem.
> 
> For the target scenarios of the hints, emitting a
> one or more bytes has not been an issue afaik.
> 
>>> All ten prefixes can be combined, resulting
>>> in an instruction up to 12 bytes long.
>>
>> Along the lines of the above, F2 and F3 used together and gaining
>> meaning other than "last one takes effect" also goes against any
>> existing use of those prefixes (afaict).
> 
> HLE permits XACQUIRE with XRELEASE.  :-)

Of course you can specify both, but not with both taking effect. Quote
from SDM Vol 2: "If an encoded byte sequence that meets XACQUIRE/XRELEASE
requirements includes both prefixes, then the HLE semantic is determined
by the prefix byte that is placed closest to the instruction opcode."

I.e. the same rule as for any other use of F2 vs F3.

> And P5 vs P6/P4 disagree over first/last REPs.

With their REP meaning, you mean? There wasn't any other meaning to REP
prefixes yet in the P5, was there?

>> In fact with your WBINVD examples above, what would the combined
>> use of both prefixes mean? "Skip INVD and LLC"?
> 
> Yes. And behavior depends on inclusiveness.
> 
>> Even new combined uses of F2/F3 plus 66 look problematic to me. The few
>> that there are are bad enough. Nothing like that can be promoted to VEX
>> or EVEX encoding, unless you want to start permitting use of those
>> legacy prefixes together with VEX/EVEX (opening up new problems).
> 
> WBINVD isn't getting promoted to VEX/EVEX.

I read the latter part of your initial mail as meaning to be more generic.
Was that a mistake of mine?

Jan