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 <a...@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
