[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 06/17] x86emul: add EVEX decoding



>>> On 14.09.16 at 19:05, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 08/09/16 14:12, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -336,6 +336,27 @@ union vex {
>>          ptr[1] = rex | REX_PREFIX; \
>>  } while (0)
>>  
>> +union evex {
>> +    uint8_t raw[3];
>> +    struct {
>> +        uint8_t opcx:2;
>> +        uint8_t :2;
> 
> Is this legal syntax?  I am guessing it compiles for you, so is it
> perhaps a GCCism?

Unnamed bitfields are standard C afaik.

>> @@ -1852,6 +1876,14 @@ x86_decode(
>>                              op_bytes = 8;
>>                          }
>>                      }
>> +                    if ( b == 0x62 )
>> +                    {
>> +                        evex.raw[0] = vex.raw[0];
>> +                        evex.raw[1] = vex.raw[1];
>> +                        evex.raw[2] = insn_fetch_type(uint8_t);
>> +
>> +                        vex.opcx = evex.opcx;
> 
> What is the meaning of opcx? The manuals list these as the mm fields.

Well, we're already using opcx instead of mmmmm for VEX, so it seems
natural to also do so for EVEX. I'm in particular of the opinion that field
names like mmmmm or vvvv are rather meaningless.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.