From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHB8q-0007f5-Hw for qemu-devel@nongnu.org; Wed, 04 Sep 2013 07:21:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHB8h-0000Nz-SK for qemu-devel@nongnu.org; Wed, 04 Sep 2013 07:20:56 -0400 Sender: Paolo Bonzini Message-ID: <5227178C.9090203@redhat.com> Date: Wed, 04 Sep 2013 13:20:44 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1378285521-3230-1-git-send-email-afaerber@suse.de> <1378285521-3230-4-git-send-email-afaerber@suse.de> <52270ABA.7090102@redhat.com> <52271345.4050603@suse.de> In-Reply-To: <52271345.4050603@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC qom-cpu 03/41] cpu: Turn cpu_get_tb_cpu_state() into a CPUClass hook List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Peter Maydell , Peter Crosthwaite , Jia Liu , Anthony Green , Alexander Graf , qemu-devel@nongnu.org, Blue Swirl , Max Filippov , Michael Walle , qemu-ppc , "Edgar E. Iglesias" , Guan Xuetao , Aurelien Jarno , Richard Henderson Il 04/09/2013 13:02, Andreas Färber ha scritto: > Am 04.09.2013 12:26, schrieb Paolo Bonzini: >> Another is to change cpu-exec.c into a file that is #included by >> target-*/helper.c or something like that. This way cpu-exec.c can still >> use the inline functions. > > I don't see how that would help with compiling multiple CPU types into > one executable. > > A common CPU struct type is needed to compile the core > CPU code once, which in turn requires dispatching for target-specific > bits, such as this one or previously gdbstub and TBD monitor. cpu-exec.c is all but common to the various targets. You could make cpu_exec() itself a CPU method. Then calls to cpu_get_tb_cpu_state() from cpu_exec() can remain inlined instead of being virtual calls. Not all files have to be compiled "per target", probably only cputlb.c and cpu-exec.c. Paolo > Combining only targets with target_ulong of the same size and identical > endianness is a restriction we can accept, I think - examples include > 32-bit ARM+SH4A, ARM+MicroBlaze, ARM+Hexagon, ARM+Epiphany. > > For performance reasons I have been careful not to have an, e.g., > cpu_get_tb_cpu_state() wrapper that calls CPU_GET_CLASS() each time. > Many of the "cpu" variables added are being cleaned up later in the > series by argument propagation. And in placement of variables requiring > CPU() cast I have been careful to place them depending on where they > are/will be actually used rather than always placing them at the top. > But if behavior depends on the CPU type, then it cannot be a global > function - cpu.h as-is is a problem and needs to be broken up. > > Andreas >