From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uvu3a-0002Lf-By for qemu-devel@nongnu.org; Sun, 07 Jul 2013 14:51:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uvu3Y-0003tH-Qg for qemu-devel@nongnu.org; Sun, 07 Jul 2013 14:51:34 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58825 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uvu3Y-0003t4-GJ for qemu-devel@nongnu.org; Sun, 07 Jul 2013 14:51:32 -0400 Message-ID: <51D9B8AE.1090206@suse.de> Date: Sun, 07 Jul 2013 20:51:26 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1372536117-28167-1-git-send-email-afaerber@suse.de> <1372536117-28167-40-git-send-email-afaerber@suse.de> <51D813DC.2050400@suse.de> <51D86C31.1050901@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC qom-cpu 39/41] target-xtensa: Introduce XtensaCPU subclasses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Filippov Cc: jan.kiszka@web.de, qemu-devel@nongnu.org Am 06.07.2013 21:54, schrieb Max Filippov: > On Sat, Jul 6, 2013 at 11:12 PM, Andreas F=C3=A4rber = wrote: >> Am 06.07.2013 20:39, schrieb Max Filippov: >>> ...and maybe a stupid question, but why moving configuration pointer = away >>> from env and then changing every place that used to access it? >> >> Xtensa is the only target trying to implicitly access an "env" variabl= e >> through a macro to obtain the number of registers for gdbstub. That's >> what I'm trying to fix with 40/41 in order to get rid of the #ifdeffer= y. >> >> The number of registers is not accessed by TCG, so it could go into >> XtensaCPU instead of CPUXtensaState. >> Further it does not change during vCPU runtime, so it no longer belong= s >> in CPUXtensaState nor XtensaCPU but in XtensaCPUClass, which is shared >> among CPU cores and can be accessed statically. >=20 > I'm concerned about two things here: adding boilerplate code to access > CPU class and doing more work at runtime than just following a pointer. > I mean that env->config is almost always used together with env itself, > could we consider env->config to be a cache for xcc->config? xtensa_env_get_cpu() after the recent patch in my queue no longer does a cast, thus it's dirt cheap to switch between CPUXtensaState and XtensaCPU (and back via ->env). The ObjectClass is a pointer in Object, just like your XtensaConfig in CPUXtensaState. Anthony has added a cast cache for v1.5 and Paolo a configure option to turn cast checks off. That leaves declaring an extra variable. But since this is orthogonal to my gdbstub cleanups, v2 just initializes env->config in XtensaCPU's instance_init, to keep the patch small while keeping cpu_init() free of non-QOM initializations. Anything else can be done later in an xtensa-only series. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg