On Tue, Mar 20, 2012 at 12:12:45PM +0000, Peter Maydell wrote: > (I can't find the relevant patches in the mailing list at > this point. I'm talking about this tree from Andreas: > http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-cpu-arm ) > > So in an IRC discussion yesterday we didn't seem to make much headway > on what the right class hierarchy is here. There seem to be two basic > options: > > (1) subclass per CPU type > This is what Andreas' tree does at the moment, so there's an ARMCPU > which is a subclass of CPUState, and then a lot of subclasses of > that, one per CPU ("arm926", "arm1026", "cortex-a8", "cortex-a9", etc). > Mostly these subclasses just arrange for different reset values for > various registers, setting feature bits, etc. > > (2) no subclasses for CPU types > This approach would just have a single ARMCPU, and then -cpu foo > is syntactic sugar for setting a lot of qom properties. > > Option two looks kind of nice, but I'm not sure whether it would > actually work. I think you could do 95% of what you need for a > different CPU that way (lots of properties for "value of ID_MMFR1", > "value of "ID_MMFR2", "reset value of SCTLR", etc etc, plus properties > for all our existing ARM_FEATURE_*, and some new ones where we're > currently keying off "which CPU is this?" rather than using a feature > bit, or just failing to distinguish things which aren't really > common to all CPUs). But I'm not sure how you'd handle the genuinely > implementation specific cp15 registers (eg cp15 crn=15). We could > have a property which says "is this a 926/1026/1176/A8/A9/..." (or > equivalently, key off the relevant fields of the main ID register) but > it doesn't seem very OO-like to have one class whose behaviour changes > based on an integer that's basically defining an ad-hoc sub-type...
Rather than key off an ID you could also just break implementation-specific functionality out into a set of interfaces you implement/override as part of the objects' initialization. Same ends, and still fits the model pretty nicely, assuming the functionality is all derivable from the common base-class. > > Regardless, it seems to me that we ought to be doing this the > same way for all our target CPUs. I don't know whether mips/x86/ > etc have any preference one way or the other. > > -- PMM >
