Am 30.04.2012 18:21, schrieb Paul Brook: >> Move feature register value setup to per-CPU init functions. > >> + env->cp15.c0_c1 = cpu->id_pfr0; >> + env->cp15.c0_c1 = cpu->id_pfr1; >> + env->cp15.c0_c1 = cpu->id_dfr0; >> + env->cp15.c0_c1 = cpu->id_afr0; >> + env->cp15.c0_c1 = cpu->id_mmfr0; >> + env->cp15.c0_c1 = cpu->id_mmfr1; >> + env->cp15.c0_c1 = cpu->id_mmfr2; >> + env->cp15.c0_c1 = cpu->id_mmfr3; >> + env->cp15.c0_c2 = cpu->id_isar0; >> + env->cp15.c0_c2 = cpu->id_isar1; >> + env->cp15.c0_c2 = cpu->id_isar2; >> + env->cp15.c0_c2 = cpu->id_isar3; >> + env->cp15.c0_c2 = cpu->id_isar4; >> + env->cp15.c0_c2 = cpu->id_isar5; > > Why are we copying these values? All these registers are readonly, so the > duplication seems wrong. Shouldn't we should be using cpu->whatever > everywhere? > > I feel like I've asked this before, but don't remember seeing an answer.
You had asked about duplication between ARMCPUClass and ARMCPU, and there were answers. Peter has now avoided adding fields to ARMCPUClass in favor of adding some fields to ARMCPU and multiple initfn functions that spare some ARMCPUClass -> ARMCPU copying through imperative hardcoding. In particular that was your request wrt non-declarative feature flags. There is also a follow-up series by Peter which reworks cp15 as a list of structs, so touching all cp15 code for cpu-> rather than env-> access did not seem like a good idea to me. > Overall I'm not convinced that the new open-coded initialization is better > then the tables it replaces. What I like better after this series is that it's in CPU-specific code rather than in common code trying to cater to all CPU models based on CPUID, which includes revision and variant numbers that we would like to expose as user-tunable QOM properties rather than as different CPU types where possible. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg