From: Stuart Brady <sdb@zubnet.me.uk>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: "Andreas Färber" <afaerber@suse.de>,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
"Fabien Chouteau" <chouteau@adacore.com>,
"Alexander Graf" <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH v2] target-ppc: improve "info registers" by printing SPRs
Date: Mon, 31 Mar 2014 20:59:12 +0100 [thread overview]
Message-ID: <20140331195912.GA17751@zubnet.me.uk> (raw)
In-Reply-To: <532FCFA3.3040804@ozlabs.ru>
On Mon, Mar 24, 2014 at 05:24:35PM +1100, Alexey Kardashevskiy wrote:
> On 03/23/2014 01:43 AM, Stuart Brady wrote:
> > This would leave the output without a trailing newline if the last spr
> > doesn't have a name registered. Is it necessary to handle unnamed sprs
> > at all (maybe add an assert to the registration function)? ... or would
> > we just want to warn about them here?
>
> In the current QEMU I do not see any place where SPR would be registered
> without a name so I would not bother.
Okay, although an assert probably wouldn't hurt. OTOH, if we never want
an SPR without a name, removing the handling for !spr->name entirely
would make sense. You could then get rid of the separate 'j' variable.
> > FWIW, my approach is often to write an outer loop that process one item
> > of output at a time, with an inner loop to obtain the next item of data,
> > and with prefixing of separators, as you then have a far simpler special
> > case for 'j == 0' instead of 'i == ARRAY_SIZE(env->spr_cb) - 1'. You can
> > then unconditionally finish on a '\n'.
>
> Oh. This is embarrassing, sorry :( This should do it, right? :)
Not that embarrassing, to be honest. The code I once fixed that built up
a string of comma-separated values, and then tried to remove the trailing
comma even if the string was empty, now *that* was embarrassing. This
was remarkably copied-and-pasted all over the shop and then fixed in some
files but not others. Luckily, corruption of the preceding variable was
harmless in all occurrences since it was held in a register. Erk. :-(
In that particular case it made more sense to increment to point past the
leading comma if present, and I've tended toward that style ever since.
> + for (i = 0, j = 0; i < ARRAY_SIZE(env->spr_cb); i++) {
> + ppc_spr_t *spr = &env->spr_cb[i];
> +
> + if (!spr->name) {
> + continue;
> + }
> + if (j % 4) {
> + cpu_fprintf(f, " ");
> + } else if (j) {
> + cpu_fprintf(f, "\n");
> + }
> + cpu_fprintf(f, "%-6s " TARGET_FMT_lx, spr->name, env->spr[i]);
> + j++;
> }
> + cpu_fprintf(f, "\n");
Looks good.
> btw while grepping through the code, I found dump_ppc_sprs() which prints
> this (first chunk is what my patch adds and the second chunk is from
> dump_ppc_sprs()):
>
[...]
> Special purpose registers:
[...]
> Which is nicer/more useful?
> The characters at the end tell what handler (read/write, oea/uea) is
> defined for SPR.
They're both perfectly fine. For the list of registers, you want detail
about access type, etc. and perhaps not the current values, but for the
simple register dump would want values and register names but without any
extraneous information.
--
Cheers,
Stuart
prev parent reply other threads:[~2014-03-31 19:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-22 12:25 [Qemu-devel] [PATCH v2] target-ppc: improve "info registers" by printing SPRs Alexey Kardashevskiy
2014-03-22 14:43 ` Stuart Brady
2014-03-24 6:24 ` Alexey Kardashevskiy
2014-03-31 1:25 ` Alexey Kardashevskiy
2014-03-31 8:24 ` Andreas Färber
2014-03-31 8:50 ` Alexey Kardashevskiy
2014-03-31 10:07 ` Peter Maydell
2014-03-31 10:48 ` Alexey Kardashevskiy
2014-03-31 13:27 ` Alexander Graf
2014-03-31 19:59 ` Stuart Brady [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=20140331195912.GA17751@zubnet.me.uk \
--to=sdb@zubnet.me.uk \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=chouteau@adacore.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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).