[v3,4/5] target-unicore32: QOM'ify CPU

Am 30.03.2012 18:15, schrieb Michael Roth:
> On Fri, Mar 30, 2012 at 12:26:09PM +0200, Andreas Färber wrote:
>> +static void unicore_ii_cpu_initfn(Object *obj)
>> +{
>> +    UniCore32CPU *cpu = UNICORE32_CPU(obj);
>> +    CPUUniCore32State *env = &cpu->env;
>> +
>> +    env->cp0.c0_cpuid = 0x40010863;
> 
> Any reason not to use UC32_CPUID_UCV2 here, and UC32_CPUID_ANY below?
> 
>> +}
>> +
>> +static void uc32_any_cpu_initfn(Object *obj)
>> +{
>> +    UniCore32CPU *cpu = UNICORE32_CPU(obj);
>> +    CPUUniCore32State *env = &cpu->env;
>> +
>> +    env->cp0.c0_cpuid = 0xffffffff;
>> +}

Yes. Like for target-arm, the idea is to deprecate the use of
CPUID-dependent common code. For unicore32 we are in the lucky position
of being able to do that right away:

commit f8eb3e1d3f4e04b79513655f68fa23a43a31c74c
Author: Andreas Färber <afaerber@suse.de>
Date:   Fri Mar 30 23:19:20 2012 +0200

    target-unicore32: Drop UC32_CPUID macros

    Any code that depends on a particular CPU type can now go through
    callbacks on the QOM UniCore32CPUClass.

    Signed-off-by: Andreas Färber <afaerber@suse.de>

 #define cpu_signal_handler              uc32_cpu_signal_handler

But that can be done as follow-up IMO (just like adding reset support).

Andreas

On Fri, Mar 30, 2012 at 11:38:02PM +0200, Andreas Färber wrote:
> Am 30.03.2012 18:15, schrieb Michael Roth:
> > On Fri, Mar 30, 2012 at 12:26:09PM +0200, Andreas Färber wrote:
> >> +static void unicore_ii_cpu_initfn(Object *obj)
> >> +{
> >> +    UniCore32CPU *cpu = UNICORE32_CPU(obj);
> >> +    CPUUniCore32State *env = &cpu->env;
> >> +
> >> +    env->cp0.c0_cpuid = 0x40010863;
> > 
> > Any reason not to use UC32_CPUID_UCV2 here, and UC32_CPUID_ANY below?
> > 
> >> +}
> >> +
> >> +static void uc32_any_cpu_initfn(Object *obj)
> >> +{
> >> +    UniCore32CPU *cpu = UNICORE32_CPU(obj);
> >> +    CPUUniCore32State *env = &cpu->env;
> >> +
> >> +    env->cp0.c0_cpuid = 0xffffffff;
> >> +}
> 
> Yes. Like for target-arm, the idea is to deprecate the use of
> CPUID-dependent common code. For unicore32 we are in the lucky position
> of being able to do that right away:
> 
> commit f8eb3e1d3f4e04b79513655f68fa23a43a31c74c
> Author: Andreas Färber <afaerber@suse.de>
> Date:   Fri Mar 30 23:19:20 2012 +0200
> 
>     target-unicore32: Drop UC32_CPUID macros
> 
>     Any code that depends on a particular CPU type can now go through
>     callbacks on the QOM UniCore32CPUClass.
> 
>     Signed-off-by: Andreas Färber <afaerber@suse.de>
> 
> diff --git a/target-unicore32/cpu.h b/target-unicore32/cpu.h
> index 81c14ff..50d5695 100644
> --- a/target-unicore32/cpu.h
> +++ b/target-unicore32/cpu.h
> @@ -120,10 +120,6 @@ void cpu_asr_write(CPUUniCore32State *env1,
> target_ulong val, target_ulong mask)
>  #define UC32_HWCAP_CMOV                 4 /* 1 << 2 */
>  #define UC32_HWCAP_UCF64                8 /* 1 << 3 */
> 
> -#define UC32_CPUID(env)                 (env->cp0.c0_cpuid)
> -#define UC32_CPUID_UCV2                 0x40010863
> -#define UC32_CPUID_ANY                  0xffffffff
> -
>  #define cpu_init                        uc32_cpu_init
>  #define cpu_exec                        uc32_cpu_exec
>  #define cpu_signal_handler              uc32_cpu_signal_handler
> 
> But that can be done as follow-up IMO (just like adding reset support).

Ahh, gotcha, thanks (and agreed)

> 
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>