From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O8JtJ-0005Un-18 for qemu-devel@nongnu.org; Sat, 01 May 2010 17:06:25 -0400 Received: from [140.186.70.92] (port=46488 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O8JtF-0005Qj-1M for qemu-devel@nongnu.org; Sat, 01 May 2010 17:06:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O8JtD-000692-9B for qemu-devel@nongnu.org; Sat, 01 May 2010 17:06:20 -0400 Received: from mail-px0-f173.google.com ([209.85.212.173]:46722) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O8JtD-00068p-4K for qemu-devel@nongnu.org; Sat, 01 May 2010 17:06:19 -0400 Received: by pxi19 with SMTP id 19so659725pxi.4 for ; Sat, 01 May 2010 14:06:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20100427212335.GA6194@zubnet.me.uk> References: <20100427212335.GA6194@zubnet.me.uk> Date: Sun, 2 May 2010 00:06:17 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH] Clean up definition of MAX_OPC_PARAM From: Blue Swirl Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stuart Brady Cc: qemu-devel@nongnu.org Thanks, applied. On 4/28/10, Stuart Brady wrote: > MAX_OPC_PARAM is intended to refer to the maximum number of entries used > in gen_opparam_buf[] for any single helper call. It is currently defined > as 10, but for 32-bit archs, the correct value (with a maximum for four > helper arguments) is 14, and for 64-bit archs, only 9 entries are needed. > > tcg_gen_callN() fills four entries with the function address, flags, > number of args, etc. and on 32-bit archs uses a further two entries per > argument (with a maximum of four helper arguments), plus two more for the > return value. On 64-bit archs, only half as many entries are used for the > args and the return value. > > In reality, TBs tend not to consist purely of helper calls exceeding the > stated 10 gen_opparam_buf[] entries, so this would never actually be a > problem on 32-bit archs, but the definition is still rather confusing. > > Signed-off-by: Stuart Brady > --- > diff --git a/exec-all.h b/exec-all.h > index 4bae1e2..1016de2 100644 > --- a/exec-all.h > +++ b/exec-all.h > @@ -44,8 +44,20 @@ typedef struct TranslationBlock TranslationBlock; > > /* XXX: make safe guess about sizes */ > #define MAX_OP_PER_INSTR 96 > -/* A Call op needs up to 6 + 2N parameters (N = number of arguments). */ > -#define MAX_OPC_PARAM 10 > + > +#if HOST_LONG_BITS == 32 > +#define MAX_OPC_PARAM_PER_ARG 2 > +#else > +#define MAX_OPC_PARAM_PER_ARG 1 > +#endif > +#define MAX_OPC_PARAM_IARGS 4 > +#define MAX_OPC_PARAM_OARGS 1 > +#define MAX_OPC_PARAM_ARGS (MAX_OPC_PARAM_IARGS + MAX_OPC_PARAM_OARGS) > + > +/* A Call op needs up to 4 + 2N parameters on 32-bit archs, > + * and up to 4 + N parameters on 64-bit archs > + * (N = number of input arguments + output arguments). */ > +#define MAX_OPC_PARAM (4 + (MAX_OPC_PARAM_PER_ARG * MAX_OPC_PARAM_ARGS)) > #define OPC_BUF_SIZE 640 > #define OPC_MAX_SIZE (OPC_BUF_SIZE - MAX_OP_PER_INSTR) > > > >