From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrl7x-0003df-Sk for qemu-devel@nongnu.org; Mon, 11 May 2015 06:40:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yrl7u-0000zU-Ll for qemu-devel@nongnu.org; Mon, 11 May 2015 06:40:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrl7u-0000zO-Es for qemu-devel@nongnu.org; Mon, 11 May 2015 06:39:58 -0400 Message-ID: <555086F5.20001@redhat.com> Date: Mon, 11 May 2015 12:39:49 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <6920fa40d097d15d0cfcaf63c26b6325ee5edc46.1431322749.git.crosthwaite.peter@gmail.com> <55508206.5040206@suse.de> <55508368.3010300@redhat.com> <5550863F.6080009@suse.de> In-Reply-To: <5550863F.6080009@suse.de> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH 02/34] tcg+qom: QOMify core CPU defintions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, Peter Crosthwaite , sorenb@xilinx.com, edgari@xilinx.com, rth@twiddle.net On 11/05/2015 12:36, Andreas F=E4rber wrote: > > Right. My point was that these functions are not polymorphic. Each > > call to these should know exactly which function to call. > >=20 > > cputlb.c, cpu-exec.c and parts of translate-all.c should be the moral > > equivalent of C++ templates. I wouldn't mind switching to C++, but i= f > > we want to make them polymorphic we should do it at compile time thro= ugh > > multiple compilation and/or inclusion from target-*. >=20 > I think we got more concrete than that, possibly on IRC only? I believe > #include'ing cputlb.c from some target-* file was one of your proposed > solutions? Yes (but Peter is making more functions virtual, so he'd have to do the same also for cpu-exec.c and parts of translate-all.c). > And splitting some of the inline functions that I was getting > rid of into some new (or existing?) file? If I remember correctly, another solution could be to keep the virtual functions, but ensure that all the hot paths were "devirtualizing" them and calling the CPU-specific function directly. Paolo