[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] target-tilegx: Execute _start and reach to __li

From: Chen Gang S
Subject: Re: [Qemu-devel] [PATCH] target-tilegx: Execute _start and reach to __libc_start_main successfully
Date: Fri, 27 Feb 2015 11:41:20 +0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 2/27/15 11:01, Chris Metcalf wrote:
> On 2/25/2015 8:44 PM, Chen Gang S wrote:
>> On 02/26/2015 01:19 AM, Richard Henderson wrote:
>>> On 02/24/2015 05:40 PM, Chen Gang S wrote:
>>>>>> +static int gen_shl16insli(struct DisasContext *dc,
>>>>>> +                          unsigned char rdst, unsigned char rsrc, short 
>>>>>> im16)
>>>>> Use uint16_t, as the field is not signed.
>>>> objdump print it as signed, e.g. "shl16insli r32, r32, -30680"
>>> I think you've just found a bug in objdump.  ;-)
>> According to the ISA document, I guess, it assumes imm16 is unsigned
>> number (although ISA document does not mention about it, directly). But
>> for tcg_gen_ori_i64, it assumes imm16 is signed number:
>>    void tcg_gen_ori_i64(TCGv_i64 ret, TCGv_i64 arg1, int64_t arg2);
>> So for me, I am not sure that objdump must be a bug. For safety reason,
>> I still prefer to treat imm16 as signed number.
> You have to consider the immediate value as having the high 48 bits zero
> when you "or" it into the result, so it's hard to consider it as signed in
> any meaningful way.  Richard is right.

That the reason why I have to use:

  imm = (int64_t)im16 & 0x000000000000ffffLL;

But I don't know why both objdump and tcg_gen_ori_i64 treate imm16 as
signed integer. I guess:

 - For tcg_gen_ori_i64, I don't know why, does it need improvement?

 - For objdump, for me, the main reason is that the opcode only has
   TILEGX_OP_TYPE_IMMEDIATE which is only for signed immediate number,
   no one for unsigned immediate number (the same in Linux kernel).

If I have to use unsigned immediate number, I guess, at least, we also
need fix the related issue in both binutils and Linux kernel (if
possible, I should do it, within next month).

>> Y1 can issue branches, which can be buffered. And Y1 also can issue call
>> (which will store pc to sp stack) -- e.g. jalr, jalrp.
> Richard already covered this, but yes, jal/jalr etc are not memory ops.
> There is only one memory op possible per bundle.

OK, thanks.

Chen Gang

Open, share, and attitude like air, water, and life which God blessed

reply via email to

[Prev in Thread] Current Thread [Next in Thread]