From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afRWk-0003to-UP for qemu-devel@nongnu.org; Mon, 14 Mar 2016 08:23:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afRWh-0001to-OQ for qemu-devel@nongnu.org; Mon, 14 Mar 2016 08:23:14 -0400 Received: from greensocs.com ([193.104.36.180]:37511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afRWh-0001tP-BW for qemu-devel@nongnu.org; Mon, 14 Mar 2016 08:23:11 -0400 References: <87r3fjpvgx.fsf@fimbulvetr.bsc.es> <56E046D3.2080709@twiddle.net> From: KONRAD Frederic Message-ID: <56E6AD2B.7060304@greensocs.com> Date: Mon, 14 Mar 2016 13:23:07 +0100 MIME-Version: 1.0 In-Reply-To: <56E046D3.2080709@twiddle.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , qemu-devel@nongnu.org Cc: Paolo Bonzini , Peter Crosthwaite Hi, Le 09/03/2016 16:52, Richard Henderson a =E9crit : > On 03/09/2016 09:38 AM, Llu=EDs Vilanova wrote: >> Hi, >> >> NOTE: I won't be throwing patches anytime soon, I just want to know=20 >> if there's >> interest in this for the future. >> >> While adding events for tracing guest instructions, I've found that th= e >> per-target "gen_intermediate_code()" function is very similar but not=20 >> exactly >> the same for each of the targets. This makes architecture-agnostic=20 >> features >> harder to maintain across targets, specially when it comes to their=20 >> relative >> order. >> >> So, would it be worth it if I generalized part of that code into an >> architecture-agnostic function that calls into target-specific hooks=20 >> wherever it >> needs extending? There are many ways to do it that we can discuss late= r. > > It's worth talking about, since I do believe it would make long-term=20 > maintenance across the targets easier. > > These "target-specific hooks" probably ought not be "hooks" in the > traditional sense of attaching them to CPUState. I'd be more=20 > comfortable with a refactoring that used include files -- maybe .h or=20 > maybe .inc.c. If we do the normal sort of hook, then we've got to=20 > either expose DisasContext in places we shouldn't, or dynamically=20 > allocate it. Neither seems particularly appealing. > > > r~ > On the other side I think attaching them to CPUState would make=20 heterogenous system emulation easier? Fred