On Thu, Sep 20, 2012 at 7:15 AM, Ronald Hecht <ronald.he...@gmx.de> 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
