qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/9] target-ppc: Refactor init_proc_POWER7


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 2/9] target-ppc: Refactor init_proc_POWER7
Date: Thu, 22 May 2014 09:08:44 +0200


> Am 22.05.2014 um 05:59 schrieb Alexey Kardashevskiy <address@hidden>:
> 
>> On 05/21/2014 11:23 PM, Alexander Graf wrote:
>> 
>>> On 21.05.14 14:30, Alexey Kardashevskiy wrote:
>>>> On 05/21/2014 08:44 PM, Alexander Graf wrote:
>>>>> On 21.05.14 08:20, Alexey Kardashevskiy wrote:
>>>>> This moves SPR initialization to helper functions.
>>>>> 
>>>>> Signed-off-by: Alexey Kardashevskiy <address@hidden>
>>>> I like the idea, but please refactor all book3s CPUs, not just POWER7.
>>>> 
>>>> I also think we can cover a lot of the SPR registration by matching on
>>>> feature fields. VR for example is coupled to Altivec.
>>> 
>>> Ok.
>>> 
>>>> Maybe we could also introduce an enum for the exact cpu type, similar to
>>>> how we do it on e500? Then we could do fun things like
>>>> 
>>>> if (cpu_type >= CPU_TYPE_970) {
>>>>     gen_spr_book3s_vr(env);
>>>> }
>>>> 
>>>> if (cpu_type >= CPU_TYPE_POWER7) {
>>>>     gen_spr_lpar(env);
>>>> }
>>>> 
>>>> switch (cpu_type) {
>>>>     case CPU_TYPE_POWER7:
>>>>         env->slb_nr = 32;
>>>>         break;
>>>>     default:
>>>>         env->slb_nr = 64;
>>>>         break;
>>>> }
>>>> 
>>>> and thus combine all those book3s init functions into a single, more
>>>> maintainable version.
>>> If I can, I would like not to do it in this way, I'd rather have explicit
>>> list of gen_spr_FACILITY() calls always. For example,
>>> DABR/DABRX/whateverPOWER8has - it is not going to be always ">", and this
>>> breaks my weak mind :(
>> 
>> Could you give me some examples where a newer POWER has lost features over
>> an older POWER?
> 
> DABR/DABRX, also Paul mentioned "one exception is the instructions in
> power6 that are register moves between gpr and fpr registers".

For those cases, just switch() explicitly for the cpu type. We don't have to 
arithmetically solve all of the feature matches :)

Alex

> I do not
> know anything else though. So your point is taken, I'll try to do what you
> want :)
> 
> 
> -- 
> Alexey



reply via email to

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