x86: Add support for Intel AMX instructions

[Jan Beulich]

On 02.07.2020 18:50, H.J. Lu wrote:
> On Thu, Jul 2, 2020 at 9:31 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 02.07.2020 17:58, Cui, Lili wrote:
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Thursday, July 2, 2020 7:22 PM
>>>>
>>>> For maintainability following existing style and arrangements is really quite
>>>> important.
>>>>
>>>> Along these lines just look at
>>>>
>>>> +  X86_64_VEX_0F3849_P_0_W_0_M_0_L_0,
>>>> +  X86_64_VEX_0F3849_MOD_3_REG_0_RM_0_LEN_0,
>>>>
>>>> Why two different styles even in adjacent lines? Or look at this
>>>>
>>>
>>> Because the abbreviation of  "REG_0_RM_0" is " R_0_R_0" , so I used full name instead.
>>
>> Oh, I see. At least MOD and LEN should still be abbreviated then,
>> I think.
>>
>>>> @@ -1852,7 +1889,19 @@ enum
>>>>    VEX_LEN_0F381A_P_2_M_0,
>>>>    VEX_LEN_0F3836_P_2,
>>>>    VEX_LEN_0F3841_P_2,
>>>> +  LEN_VEX_0F3849_P_0_W_0_M_0,
>>>> +  LEN_VEX_0F3849_MOD_3_REG_0_RM_0,
>>>> +  LEN_VEX_0F3849_P_2_W_0_M_0,
>>>> +  LEN_VEX_0F3849_P_3_W_0_M_0,
>>>> +  LEN_VEX_0F384B_P_1_W_0_M_0,
>>>> +  LEN_VEX_0F384B_P_2_W_0_M_0,
>>>> +  LEN_VEX_0F384B_P_3_W_0_M_0,
>>>>    VEX_LEN_0F385A_P_2_M_0,
>>>> +  LEN_VEX_0F385C_P_1_W_0_M_0,
>>>> +  LEN_VEX_0F385E_P_0_W_0_M_0,
>>>> +  LEN_VEX_0F385E_P_1_W_0_M_0,
>>>> +  LEN_VEX_0F385E_P_2_W_0_M_0,
>>>> +  LEN_VEX_0F385E_P_3_W_0_M_0,
>>>>    VEX_LEN_0F38DB_P_2,
>>>>    VEX_LEN_0F38F2_P_0,
>>>>    VEX_LEN_0F38F3_R_1_P_0,
>>>>
>>>> You insert LEN_VEX_* when everything around is named VEX_LEN_*.
>>>> And there's again an outlier style wise (which is also lacking a _P_<n> infix
>>>> from the looks of it).
>>>
>>> I will fix it.
>>>
>>>>
>>>> There's also still no support for or checking of uses of %tmm8...%tmm15.
>>>> Even worse, there are a number of "reg > 8"
>>>> checks, when the respective arrays only have 8 entries.
>>>
>>> Sorry, it should be "reg > 0x07", I will fix it.
>>> From spec we only define TMM0..TMM7, so any tmm register number exceeding
>>> 7 is illegal.
>>
>> There's nowhere the spec says so, afaics. What is or is not legal
>> is solely controlled by the chosen palette (which is not something
>> you can know at assembly time). We've already settled with H.J. on
>> providing all 16 registers.
> 
> After internal discussion, we decide to treat TMM registers like
> mask registers.  Encoding supports 16 registers, but only first 8 are
> valid.

Hmm, I disagree (without the doc getting changed to express this, ideally
alongside a "why"), but I guess I get no saying here. However, if so,
then this absolutely needs to be accompanied by a specification of what
VEX.R. VEX.B, and the high bit of VEX.VVVV mean then: Are they to be
ignored, or would them being clear be a reason for #UD? There are similar
rules for the mask registers, after all (#UD for the first and last of
the cases, while VEX.B is ignored, from all I can tell).

Also what about a hypothetical palette then for which e.g. registers
above %tmm3 "are not valid tiles" (using the ISA Extensions doc wording
intentionally here)?

Jan