Re: [Xen-devel] [PATCH v7 03/49] x86emul: support AVX512{F, BW, DQ} extract insns

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.12.18 at 19:20, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 19/12/2018 14:36, Jan Beulich wrote:
>> @@ -280,6 +285,12 @@ static const struct test avx512bw_all[]
>>      INSN(ptestnm,     f3, 0f38, 26,    vl,   bw, vl),
>>  };
>>  
>> +static const struct test avx512bw_128[] = {
>> +    INSN(pextrb, 66, 0f3a, 14, el, b, el),
>> +//       pextrw, 66,   0f, c5,     w
> 
> I presume this isn't tested, due to its lack of a memory operand?

Correct - without a memory operand there's no Disp8 either,
yet validation of the handling of that is what the file is for.
Nevertheless I wanted to add all instructions to their tables,
to have a way to validate complete coverage for insns at
the end of the series.

> It does appear to be a particularly odd encoding.

Not sure what you find odd with it. When its original, legacy
form was first introduced, a memory operand was apparently
not deemed useful, and hence the (register only) encoding
was with the source operands encoded in the place of where
a memory operand would be encoded. That's the common
(but not exclusive) principle - unless a memory write is
intended, it's preferably the source to allow for encoding of
a memory operand. Later, when they extended the insn to
have byte/dword/qword equivalents, they allowed for
memory operands, yet deemed it more useful for them to
be the destination (i.e. alongside the GPR).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel