From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA1y9-00063e-VW for qemu-devel@nongnu.org; Tue, 20 Mar 2012 12:31:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SA1y3-0007bY-Hj for qemu-devel@nongnu.org; Tue, 20 Mar 2012 12:31:33 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:44071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SA1y3-0007bF-Aq for qemu-devel@nongnu.org; Tue, 20 Mar 2012 12:31:27 -0400 Received: by yenr5 with SMTP id r5so275841yen.4 for ; Tue, 20 Mar 2012 09:31:25 -0700 (PDT) Sender: fluxion Date: Tue, 20 Mar 2012 11:31:20 -0500 From: Michael Roth Message-ID: <20120320163120.GB29058@illuin> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] ARM QOM conversion / class hierarchy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paul Brook , QEMU Developers , Anthony Liguori , Andreas =?iso-8859-1?Q?F=E4rber?= 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 >