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

[Chen Gang S]

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.


Thanks.
-- 
Chen Gang

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