From: Joel Brobecker <brobecker@adacore.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v3] sim: bfin: new port
Date: Mon, 21 Feb 2011 10:13:00 -0000 [thread overview]
Message-ID: <20110221095436.GD2600@adacore.com> (raw)
In-Reply-To: <AANLkTim3WfEHqKc2MZ0wysszteqD0wXHZadtXWLdzC_E@mail.gmail.com>
Please, sending compressed files makes it harder to look at the file.
I think you were right to do it for a file that's 4MB, but in that case,
using something a little more usual like gz, zip or bzip2 would have
made things easier... I had to install the xzutil on my laptop and it
wasn't without its little scary moment...
> changes since v3:
> - stubbed all the bootroms (i'll follow up)
> - add simple jtag/watchpoint device simulation
I'm not a sim expert, so I can only provide cosmetic review.
However, I did notice a couple of important things: The copyright
headers should mention 2011, and the license should be GPL version 3.
Question: Why do you have .h files whose name starts with an underscore?
For instance: sim/bfin/_proc_list.h...
General comment: We should really strive to follow the same coding
standards in sim/ as we do in gdb/. In particular, it would be nice
to have more comments, and to follow the maximum line length as
possible.
For instance:
> typedef enum
> {
> c_0, c_1, c_4, c_2, c_uimm2, c_uimm3, c_imm3, c_pcrel4,
> c_imm4, c_uimm4s4, c_uimm4s4d, c_uimm4, c_uimm4s2, c_negimm5s4, c_imm5, c_imm5d, c_uimm5, c_imm6,
> c_imm7, c_imm7d, c_imm8, c_uimm8, c_pcrel8, c_uimm8s4, c_pcrel8s4, c_lppcrel10, c_pcrel10,
For the comments - I think that's a lot of code now, and I wont' block
the commit for something like that. But, to me, code documentation is
an integral part of software quality... For instance, the following
function has a relatively cryptic name, particularly for someone who
is not familiar with the bfin architecture:
> +static const char *
> +fmtconst_str (const_forms_t cf, bs32 x, bu32 pc)
Remove the '*' at the beginning of each line in multi-line comments:
> /* If an operation would otherwise cause a positive value to overflow
> * and become negative, instead, saturation limits the result to the
> * maximum positive value for the size register being used.
Binary operators should be at the start of the line rather than
at the end:
> if ((gs < 2) || /* Dregs/Pregs as source */
> (gd < 2) || /* Dregs/Pregs as dest */
> (gs == 4 && src < 4) || /* Accumulators as source */
> (gd == 4 && dst < 4 && (gs < 4)) || /* Accumulators as dest */
I am pretty sure you already know all this; it's just that it's so
much code that it's hard to always be complient, particularly if
the code started in something like 2005.
I have no other comment. I think you know what you're doing in
the simulator area, so I'm inclined to trust your judgment on
the rest of the code (if you could just remember for future
contributions that comments are important). If Pedro has no further
comments, the meat of the patch is OK with me.
--
Joel (burp - 100K lines of patch later)
next prev parent reply other threads:[~2011-02-21 9:54 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-16 1:41 [PATCH] " Mike Frysinger
2010-12-31 23:12 ` [PATCH v2] " Mike Frysinger
2011-02-14 20:18 ` [PATCH v3] " Mike Frysinger
2011-02-14 20:49 ` Pedro Alves
2011-02-14 21:12 ` Mike Frysinger
2011-02-14 21:55 ` Pedro Alves
2011-02-14 22:11 ` Mike Frysinger
2011-02-14 22:23 ` Mike Frysinger
2011-02-15 16:25 ` Pedro Alves
2011-02-16 1:34 ` Mike Frysinger
2011-02-16 5:34 ` Joel Brobecker
2011-02-20 7:24 ` Mike Frysinger
2011-02-21 10:13 ` Joel Brobecker [this message]
2011-02-21 18:27 ` Mike Frysinger
2011-02-22 8:28 ` Joel Brobecker
2011-02-22 17:58 ` Mike Frysinger
2011-02-22 10:50 ` Pedro Alves
2011-02-22 18:07 ` Mike Frysinger
2011-02-22 10:08 ` Pedro Alves
2011-02-22 17:57 ` Mike Frysinger
2011-02-22 18:25 ` Pedro Alves
2011-02-22 20:54 ` Mike Frysinger
2011-02-22 20:29 ` [PATCH v5] " Mike Frysinger
2011-03-01 5:16 ` Mike Frysinger
2011-03-01 10:11 ` Joel Brobecker
2011-03-01 21:19 ` Pedro Alves
2011-03-01 23:42 ` Mike Frysinger
2011-03-02 1:13 ` Pedro Alves
2011-03-02 2:23 ` Mike Frysinger
2011-03-02 9:30 ` Pedro Alves
2011-03-02 21:46 ` Mike Frysinger
2011-03-02 23:32 ` Pedro Alves
2011-03-02 23:32 ` Pedro Alves
2011-03-03 21:40 ` [PATCH v6] " Mike Frysinger
2011-03-04 10:19 ` Pedro Alves
2011-03-04 21:12 ` Mike Frysinger
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=20110221095436.GD2600@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=vapier@gentoo.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