Potential missing metadata attribute for REX.W prefix and no prefix needed

[Kashio]

There are some instructions where a rex prefix is used to change the instruction but not affect any of the operands, so one cannot use operand types like qp, dqp, vqp, ptp, for exmaple the instruction XRSTOR64 which is encoded as such (Taken from Intel's manual):

NP REX.W + 0F AE /5
XRSTOR64 mem

I think as far as my understanding it's doing the same operation as XRSTOR but saving different register data to the XSAVE AREA so one can argue it could have it's own syntax, even tho right now the XML reference doesn't mention any of these FPU registers besides the normal ST(i), MMX, XMM, etc...
*There're couple more related instructions like this like XSAVE etc..

So I'm wondering if we would like to support this different mnemonic we would need to think of a way to enforce REX.W prefix on a syntax element.
We can't use the pref attribute since it only covers one prefix and REX.W could be several, but we could make pref either a string or a list of strings in the xml for such cases or even a new attribute. If no instructions like this exists that actually does something different besides having 64 in the name of the mnemonic and just fiddling a bit different with some special registers, I think this feature is not a must.

Something else that bothers me more is the disregardance of the NP (no prefix allowed) encoding of alot of the instructions in the manual, if a parser would want to use the XML it would assume prefixes are allowed if no indication is given. I think a proper solution to this would be to add some attribute like np to the syntax element.

[BarebitOpenSource]

You're right, I didn't notice this before. I will need more time to think about the XML implementation.

And yes, NP and NFx should be implemented too. These were not indicated in the older manuals. See #58.

[BarebitOpenSource]

Idea: reuse pref element with new REXW pseudoconstant. The REXW doesn't mean value 0x48 but only the W bit in REX, if REX is present.

[BarebitOpenSource]

It seems that because of AVX VZEROUPPER vs. VZEROALL, there will be an attribute indicating dependency on VEX.L because it is not possible to indicate it using operand type. To make XRSTOR64 and similar cases consistent with this, there should be a new attribute indicating dependency on REX.W.

[BarebitOpenSource]

Related missing instructions:

XSAVEOPT, XSAVEOPT64

XSAVES, XSAVES64

[BarebitOpenSource]

Moved to mazegen/x86reference#15