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

[Alexey Kardashevskiy <aik@ozlabs.ru>]

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 <aik@ozlabs.ru>
>>> 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". I do not
know anything else though. So your point is taken, I'll try to do what you
want :)


-- 
Alexey