qemu-devel
[Top][All Lists]
Advanced

[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: Tue, 24 Feb 2015 23:39:51 +0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 2/24/15 22:38, Peter Maydell wrote:
> On 24 February 2015 at 23:21, Chris Metcalf <address@hidden> 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



reply via email to

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