Re: x86 WBINVD prefix allocations

On 29.08.2026 01:30, Christian Ludloff wrote:
> If the use of x86 prefixes on WBINVD is not
> of your concern, you can stop reading.
> 
> -------------------- 8< -------------------
> 
> I was asked to relay this to binutils/LKML.
> 
> Existing Behavior
> -----------------
> 
> WBINVD has been using opcode 0x0F,0x09 ever
> since the 486 days, to perform a write back
> and invalidation of the on-chip cache.
> 
> WBNOINVD -- that is, using WBINVD with 0xF3
> as a prefix to hint that the INVD operation
> should be skipped -- was added a while ago,
> with a CPUID flag, by AMD, then Intel. When
> not supported, a normal WBINVD ensues.
> 
> New Skip Hints
> --------------
> 
> As of 2025, the following are in active use
> by a corporate entity other than Intel/AMD;
> therefore they shouldn't be redefined.
> 
>   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
> 
> While CODE and DATA hint that the operation
> should skip code and data caches, LLC hints
> that the operation should skip a last-level
> cache, and INVD does remain unchanged.

I view (ab)use of 0x67 as an operation modifying prefix as problematic.
Yet it might be okay that way. However, ...

> More New Hints
> --------------
> 
> In addition the six implementation-specific
> hints select up to six or 2^6=64 behaviors,
> depending on the particular processor.
> 
>   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.

> One particular implemention might use these
> to target CODE vs DATA vs STREAMING STORES,
> as well as cache level L1 vs L2 vs L3.
> 
> Another particular implementation might use
> these to target programmable behavior.
> 
> Miscellaneous
> -------------
> 
> 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). In fact with your WBINVD
examples above, what would the combined use of both prefixes mean?
"Skip INVD and LLC"?

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

Jan