Re: [Qemu-devel] [PATCH] Added more entries to the LEON processor configuration register

[Blue Swirl]

On Thu, Sep 20, 2012 at 7:15 AM, Ronald Hecht <address@hidden> wrote:
> On 09/19/2012 08:56 PM, Blue Swirl wrote:
>>>
>>> --- a/target-sparc/translate.c
>>> +++ b/target-sparc/translate.c
>>> @@ -2590,13 +2590,9 @@ static void disas_sparc_insn(DisasContext * dc,
>>> unsigned int insn)
>>>                                          microSPARC II */
>>>                       /* Read Asr17 */
>>>                       if (rs1 == 0x11&&  dc->def->features&
>>> CPU_FEATURE_ASR17) {
>>>
>>> -                        TCGv r_const;
>>> -
>>> -                        /* Read Asr17 for a Leon3 monoprocessor */
>>> -                        r_const = tcg_const_tl((1<<  8)
>>> -                                               | (dc->def->nwindows -
>>> 1));
>>> -                        gen_movl_TN_reg(rd, r_const);
>>> -                        tcg_temp_free(r_const);
>>> +                        /* Read Asr17 on LEON3 */
>>> +                        gen_helper_rdasr17(cpu_dst, cpu_env);
>>>
>>
>> Is the register is read very often? If it is, we could avoid the
>> helper call by performing the load of env->cpu_index, the shift and OR
>> with the above constant with TCG ops. The arithmetic could be even
>> avoided completely by storing precalculated values in cpu_index, then
>> other accesses to cpu_index need to shift right by 28 to read the
>> index (depends on balance of other cpu_index uses vs. this
>> instruction).
>>
>
>
> The register is read quite often, but not as often as the PSR. It is
> normally read when entering the OS (Linux, PikeOS ...) Kernel to know on
> which CPU we are running a thread. But polluting the cpu_index in env sounds
> a bit strange and overkill to me. Do you really mean the cpu_index in the
> structure CPUSPARCState? Or could we place it in dc->def as a constant?

It could be a new field specific to asr17. The field value is not
necessarily known at translation time since translation could be done
for another CPU, so dc->def would not work.

>
> Best regards,
> Ronald