From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFYey-0000db-Sa for qemu-devel@nongnu.org; Sun, 16 Oct 2011 17:54:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFYex-0005PJ-Nc for qemu-devel@nongnu.org; Sun, 16 Oct 2011 17:54:20 -0400 Received: from auth.b.painless.aaisp.net.uk ([90.155.4.48]:45740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFYex-0005CN-EL for qemu-devel@nongnu.org; Sun, 16 Oct 2011 17:54:19 -0400 Date: Sun, 16 Oct 2011 22:54:04 +0100 From: Stuart Brady Message-ID: <20111016215403.GA18648@zubnet.me.uk> References: <4E74FC29.1050003@mail.berlios.de> <1316289634-18786-5-git-send-email-weil@mail.berlios.de> <20110919202446.GA19005@zubnet.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110919202446.GA19005@zubnet.me.uk> Subject: Re: [Qemu-devel] [PATCH 5/8] tcg: Add interpreter for bytecode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel@nongnu.org On Mon, Sep 19, 2011 at 09:24:47PM +0100, Stuart Brady wrote: > On Sat, Sep 17, 2011 at 10:00:31PM +0200, Stefan Weil wrote: > [...] > > + u64 = ((helper_function)t0)(tci_read_reg(TCG_REG_R0), > > + tci_read_reg(TCG_REG_R1), > > + tci_read_reg(TCG_REG_R2), > > + tci_read_reg(TCG_REG_R3)); > > + tci_write_reg(TCG_REG_R0, u64); > > +#endif > > + break; [...] > Unfortunately, this won't work on all architectures. [...] Stefan, have you had a chance to consider this, yet? I think it would be nice to do this in a way that: * allows enabling TCI at runtime. * doesn't rely on a huge switch table or wrapper for every conceivable type of function. For example, if helpers have three argument types, i32, i64 and ptr and up to four arguments, together with return types of void, i32, i64 and ptr, we might have something like: 4 * (3^4 + 3^2 + 3^1 + 3^0) == 376 wrapper functions (or cases). Most of these wouldn't be used for any given target. This gets worse if we add a few extra arguments and types. With up to six arguments, and an extra type, there'd be 26985 cases / wrappers. :-( So, I wonder if it would be best to place this in the target and generate a wrapper for each helper function. When using TCI, we'd generate a call to this wrapper function instead of the helper function. No extra space in the ops buffer would be required, since the wrapper function would call the helper function directly, rather than taking it as a parameter. This could be compiled out on those architectures for which the current approach is okay. If we wanted to allow enabling TCI at runtime, then we'd need to choose between the wrapper functions and helper functions at translation time, either in gen_helper_* or when generating the TCI bytecode by way of a somewhat vile switch() statement... Should I try to put something together? Cheers, -- Stuart