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)
>
>
>
>
prev parent 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).