From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adjFO-0004Ob-Dw for qemu-devel@nongnu.org; Wed, 09 Mar 2016 13:54:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adjFL-0006QO-2D for qemu-devel@nongnu.org; Wed, 09 Mar 2016 13:54:14 -0500 Received: from mail-qk0-x22d.google.com ([2607:f8b0:400d:c09::22d]:33055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adjFK-0006QK-T7 for qemu-devel@nongnu.org; Wed, 09 Mar 2016 13:54:10 -0500 Received: by mail-qk0-x22d.google.com with SMTP id s5so24257539qkd.0 for ; Wed, 09 Mar 2016 10:54:10 -0800 (PST) Sender: Richard Henderson References: <87r3fjpvgx.fsf@fimbulvetr.bsc.es> <56E046D3.2080709@twiddle.net> <87twkfo6tn.fsf@fimbulvetr.bsc.es> From: Richard Henderson Message-ID: <56E0714F.1090602@twiddle.net> Date: Wed, 9 Mar 2016 13:54:07 -0500 MIME-Version: 1.0 In-Reply-To: <87twkfo6tn.fsf@fimbulvetr.bsc.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: qemu-devel@nongnu.org, Paolo Bonzini , Peter Crosthwaite On 03/09/2016 01:16 PM, Lluís Vilanova wrote: > Richard Henderson writes: > >> On 03/09/2016 09:38 AM, Lluís Vilanova wrote: >>> Hi, >>> >>> NOTE: I won't be throwing patches anytime soon, I just want to know if there's >>> interest in this for the future. >>> >>> While adding events for tracing guest instructions, I've found that the >>> per-target "gen_intermediate_code()" function is very similar but not exactly >>> the same for each of the targets. This makes architecture-agnostic features >>> harder to maintain across targets, specially when it comes to their 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 wherever it >>> needs extending? There are many ways to do it that we can discuss later. > >> It's worth talking about, since I do believe it would make long-term 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 comfortable with a >> refactoring that used include files -- maybe .h or maybe .inc.c. If we do the >> normal sort of hook, then we've got to either expose DisasContext in places we >> shouldn't, or dynamically allocate it. Neither seems particularly appealing. > > Great. I pondered about using QOM vs "template code", and I'm leaning towards > the latter: > > * translate.c: > > struct DisasContextArch { > DisasContext common; > }; > > // implement "hooks" > > void gen_intermediate_code(CPUArchState *env, TranslationBlock *tb) > { > DisasContextArch dc; > gen_intermediate_code_template(get_cpu(env), &dc.common, tb); Pointer down into "common" here... > } > > * translate-template.h: > > struct DisasContext { /* ... */ }; > > void gen_intermediate_code_template(CPUState *cpu, DisasContext *dc, > TranslationBlock *tb) > { > // init dc > // arch-specific init dc hook > > // gen_icount, etc. > while (true) { > // generic processing code with calls to hooks ... means you have to upcast to DisasContextArch here, or in the hooks themselves. > } > } > > While initially simpler, the "template code" still feels a little dirty to > me. With QOM, you could implement a DisasContextClass that provides the > per-target hook pointers, which can be globally allocated once per target and > pointed to by the DisasContext allocated in stack. > > I'm not sure about what you mean by exposing DisasContext in places it shouldn't > be, though. You either split DisasContextArch / DisasContext in "odd" ways, and then have to cast back and forth, or you have to expose the whole of DisasContextArch. It's the latter that I considered inappropriate. Alternately... can we broach the subject of C++? Honestly, it seems we work too hard sometimes to re-implement templates and classes in C. r~