[PATCH] AMD bdver2 processors 1/2 - BMI

[H.J. Lu]

On Tue, Jan 4, 2011 at 7:12 AM, Quentin Neill
<quentin.neill.gnu@gmail.com> wrote:
> On Mon, Jan 3, 2011 at 6:35 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Jan 3, 2011 at 4:06 PM, Quentin Neill
>> <quentin.neill.gnu@gmail.com> wrote:
>>> On Mon, Jan 3, 2011 at 10:35 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Mon, Jan 3, 2011 at 8:10 AM, Quentin Neill
>>>> <quentin.neill.gnu@gmail.com> wrote:
>>>>> On Tue, Dec 28, 2010 at 8:10 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>> On Tue, Dec 28, 2010 at 5:53 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>> On Mon, Dec 20, 2010 at 2:55 PM, Quentin Neill
>>>>>>> <quentin.neill.gnu@gmail.com> wrote:
>>>>>>>> On Mon, Dec 20, 2010 at 4:39 PM, Sebastian Pop <sebpop@gmail.com> wrote:
>>>>>>>>> On Mon, Dec 20, 2010 at 16:32, Quentin Neill
>>>>>>>>> <quentin.neill.gnu@gmail.com> wrote:
>>>>>>>>>> These two patches add support for BMI and TBM ISAs to be introduced in
>>>>>>>>>> AMD bdver2 processors.
>>>>>>>>>>
>>>>>>>>>> The full encoding specification is delayed, however I have posted
>>>>>>>>>> abbreviated specs on the gcc mailing list:
>>>>>>>>>> BMI: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01766.html
>>>>>>>>>> TBM: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01767.html
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Looks like your patch is reversed.  Could you please send another one
>>>>>>>>> that you get from git format-patch -1
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>> Oops.  Reposting with reversed patch.  Thanks for reviewing Sebastian.
>>>>>>>> --
>>>>>>>> Quentin
>>>>>>>>
>>>>>>>
>>>>>>> Please don't add ModrmRegExt, There are many examples in i386-opt.tbl
>>>>>>> without ModrmRegExt.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> You should check i.tm.extension_opcode != None instead.
>>>>>>
>>>>>> --
>>>>>> H.J.
>>>>>
>>>>> Hi H.J.,
>>>>> Thanks for the feedback.
>>>>> So you are saying remove ModrmRegExt from both patches, right?
>>>>
>>>> Yes.
>>>
>>> Hi H.J.,
>>>
>>> I concur that ModrmRegExt is not needed (I see opcode_extension used
>>> later to encode modrm.reg).  But I need a way to distinguish TBM/BMI
>>> from LWP instructions which don't swap the operand order:
>>>
>>> lwpins, 3, 0x12, 0x0, 1, CpuLWP, Modrm|VexOpcode=5|VexW=1|VexVVVV=3|Vex|...
>>> llwpcb, 1, 0x12, 0x0, 1, CpuLWP, Modrm|VexOpcode=4|VexW=1|Vex|...
>>> blsfill, 2, 0x01, 0x2, 1, CpuTBM, Modrm|VexOpcode=4|VexW=1|VexVVVV=3|Vex|...
>>> blcmsk, 2, 0x02,  0x1, 1, CpuTBM, Modrm|VexOpcode=4|VexW=1|VexVVVV=3|Vex|...
>>>
>>> Is it okay to branch on the number of instructions to make encoding
>>> decisions?   That seems about as kludgy as branching on the opcode or
>>> opcode_modifier, but rather than post a patch I thought I'd email
>>> first.
>>
>> x86 assembler always swap operands, except for
>>
>>  /* All intel opcodes have reversed operands except for "bound" and
>>     "enter".  We also don't reverse intersegment "jmp" and "call"
>>     instructions with 2 immediate operands so that the immediate segment
>>     precedes the offset, as it does when in AT&T mode. */
>>  if (intel_syntax
>>      && i.operands > 1
>>      && (strcmp (mnemonic, "bound") != 0)
>>      && (strcmp (mnemonic, "invlpga") != 0)
>>      && !(operand_type_check (i.types[0], imm)
>>           && operand_type_check (i.types[1], imm)))
>>    swap_operands ();
>>
>> What is the problem with TBM/BMI/LWP?
>>
>> --
>> H.J.
>
> For LWP (3 operands)
> vvvv = i.op[2].regs
> modrm.rm = i.op[1].regs->reg_num

How is op0 encoded?

> For BMI/TBM (2 operands)
> vvvv = i.op[1].regs
> modrm.rm = i.op[0].regs->reg_num
>
> I will post another patch presently that will ask the same question in
> the form of a code review :)


-- 
H.J.