This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] AMD bdver2 processors 1/2 - BMI


On Tue, Jan 4, 2011 at 9:24 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.

For LWP insns with 3 insns, op0 is always an immediate.
-- 
Quentin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]