add UDW

[ludloff]

nasm/x86/insns.dat

Line 954 in f0c3b0e

Ages ago, UD0/UD1/UD2 got cleaned up.

More recently, UDB got cleaned up too.

This leaves 0xFF,0xFF to be cleaned up.

Which is another crucial #UD instruction,
i.e. something that must not be allocated
by any future instruction. Especially as it
plays along with "unclaimed transactions
returning all bits set instead of contents".

Something like...

  UDB       void                            [       d6]                                     X86_64,LONG

• UDW       void                            [    ff ff]                                     186
  

...whereas that W in UDW matches that B
in UDB. The name UDW is a fait accompli
from my table at sandpile.

[there is a diff-like plus char at the start of
the UDW line above, but markup dislikes it]

[lab-bat]

I'm guessing what you mean is that the current "ff ff" is being deassembled as two bytes data, rather than a explicit instruction. That was a problem for all byte data not fall into HINT_NOP fields. Or perhaps I'm misunderstanding something: does the special status of "ff ff" cause a #UD, while in all other cases involving "ff /7" the behavior is undefined?

[ludloff]

The point of UDW is to formally and explicitly allocate the FF FF encoding forever.

Which is useful because of how chipsets tend to work when it comes to addresses that aren't back by memory or devices.

The other 7 encodings in group #5 /7 – i.e. FF F8 ... FF FE – are simply not interesting from that perspective. If someone someday allocates actual instructions there, then that's acceptable.