On 13/01/17 13:20, Jan Beulich wrote:
>
>>> @@ -2235,7 +2241,7 @@ x86_decode(
>>> break;
>>> }
>>> }
>>> -if ( mode_64bit() && !vex.r )
>>> +if ( !vex.r )
>>> rex_prefix |= REX_R;
>>>
>>> On 12.01.17 at 18:29, wrote:
> On 12/01/17 16:37, Jan Beulich wrote:
>> While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode,
>> VEX.B can be encoded as zero, but would be ignored by the processor.
>
> Really? That is unfortunate.
>
> It would have been far more helpful for th
On 12/01/17 16:37, Jan Beulich wrote:
> While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode,
> VEX.B can be encoded as zero, but would be ignored by the processor.
Really? That is unfortunate.
It would have been far more helpful for this to raise #UD, like the
other prohibited VEX
While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode,
VEX.B can be encoded as zero, but would be ignored by the processor.
Since we emulate instructions in 64-bit mode, we need to force the
bit to 1 in order to not act on the wrong {X,Y,Z}MM register.
We must not, however, fiddle wit
