qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: Stuart Brady <sdb@zubnet.me.uk>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Clean up definition of MAX_OPC_PARAM
Date: Sun, 2 May 2010 00:06:17 +0300	[thread overview]
Message-ID: <s2of43fc5581005011406x7bce3031z1d4460d8841154c0@mail.gmail.com> (raw)
In-Reply-To: <20100427212335.GA6194@zubnet.me.uk>

Thanks, applied.

On 4/28/10, Stuart Brady <sdb@zubnet.me.uk> 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 <sdb@zubnet.me.uk>
>  ---
>  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)
>
>
>
>

      reply	other threads:[~2010-05-01 21:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-27 21:23 [Qemu-devel] [PATCH] Clean up definition of MAX_OPC_PARAM Stuart Brady
2010-05-01 21:06 ` Blue Swirl [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s2of43fc5581005011406x7bce3031z1d4460d8841154c0@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sdb@zubnet.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).