Re: x86 WBINVD prefix allocations

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

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

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

--
C.