From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQHT6-00067o-Co for qemu-devel@nongnu.org; Tue, 24 Feb 2015 10:32:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQHT3-0005al-2U for qemu-devel@nongnu.org; Tue, 24 Feb 2015 10:32:16 -0500 Received: from out114-136.biz.mail.alibaba.com ([205.204.114.136]:60158 helo=out21.biz.mail.alibaba.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQHT2-0005aO-FW for qemu-devel@nongnu.org; Tue, 24 Feb 2015 10:32:12 -0500 Message-ID: <54EC9B47.1040006@sunrus.com.cn> Date: Tue, 24 Feb 2015 23:39:51 +0800 From: Chen Gang S MIME-Version: 1.0 References: <54EC2DEE.8050809@sunrus.com.cn> <54EC88D6.3060402@ezchip.com> In-Reply-To: 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: Peter Maydell , Chris Metcalf Cc: "walt@tilera.com" , Riku Voipio , Richard Henderson , qemu-devel On 2/24/15 22:38, Peter Maydell wrote: > On 24 February 2015 at 23:21, Chris Metcalf wrote: >> On 2/24/2015 2:53 AM, Chen Gang S wrote: >>> >>> typedef struct CPUTLState { >>> + uint64_t regs[TILEGX_R_COUNT]; /* Common used registers by outside */ >>> + uint64_t zero; /* Zero register */ >>> + uint64_t pc; /* Current pc */ >>> CPU_COMMON >>> } CPUTLState; >> >> >> I skimmed through this and my only comment is that I was surprised to see >> "zero" as part of the state, since it's always 0. :-) No doubt there is >> some reason that this makes sense. > > I think that is definitely an error... > >>> +#define TILEGX_GEN_CHK_BEGIN(x) \ >>> + if ((x) == TILEGX_R_ZERO) { >>> +#define TILEGX_GEN_CHK_END(x) \ >>> + return 0; \ >>> + } \ >>> + if ((x) >= TILEGX_R_COUNT) { \ >>> + return -1; \ >>> + } >> >> >> This macro pattern seems potentially a little confusing and I do wonder if >> there is some way to avoid having to explicitly check the zero register >> every time; for example, maybe you make it a legitimate part of the state >> and declare that there are 64 registers, and then just always finish any >> register-update phase by re-zeroing that register? It might yield a smaller >> code footprint and probably be just as fast, as long as it was easy to know >> where registers were updated. > > See target-arm/translate-a64.c for one way to handle an > always-reads-as-zero register. > After read through target-arm/translate-a64.c, I guess, the main reason is: the zero register (r31) shares with the sp register (also r31). - So it uses cpu_reg() and cpu_reg_sp() for them. - For each zero register access, it will new a tcg temporary variable for it, and release it after finish decoding one insn (so it will not overwrite sp register.). For tilegx, zero register (r63) does not share with other registers (sp is r54), so we needn't use wrap functions for it. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed