From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YRBgO-0002Wh-OC for qemu-devel@nongnu.org; Thu, 26 Feb 2015 22:33:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YRBgK-00020d-O6 for qemu-devel@nongnu.org; Thu, 26 Feb 2015 22:33:44 -0500 Received: from out1134-250.mail.aliyun.com ([42.120.134.250]:21844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YRBgK-00020O-A9 for qemu-devel@nongnu.org; Thu, 26 Feb 2015 22:33:40 -0500 Message-ID: <54EFE760.8090905@sunrus.com.cn> Date: Fri, 27 Feb 2015 11:41:20 +0800 From: Chen Gang S MIME-Version: 1.0 References: <54EC2DEE.8050809@sunrus.com.cn> <54ECBB02.1080801@redhat.com> <54ED443B.7040207@sunrus.com.cn> <54EE0433.3070101@twiddle.net> <54EE7A6D.6000704@sunrus.com.cn> <54EFDE1C.4080507@ezchip.com> In-Reply-To: <54EFDE1C.4080507@ezchip.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-tilegx: Execute _start and reach to __libc_start_main successfully List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Metcalf , Richard Henderson Cc: Peter Maydell , Riku Voipio , qemu-devel , "walt@tilera.com" 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