qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Simpson <tsimpson@quicinc.com>
To: "Taylor Simpson" <tsimpson@quicinc.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Aleksandar Markovic" <aleksandar.m.mail@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "Alessandro Di Federico" <ale@rev.ng>,
	"nizzo@rev.ng" <nizzo@rev.ng>,
	"Niccolò Izzo" <izzoniccolo@gmail.com>
Subject: RE: QEMU for Qualcomm Hexagon - KVM Forum talk and code available
Date: Tue, 17 Dec 2019 18:14:47 +0000	[thread overview]
Message-ID: <BYAPR02MB488640DD7CC887E5FCC0F167DE500@BYAPR02MB4886.namprd02.prod.outlook.com> (raw)
In-Reply-To: <SN6PR02MB48953397AA553FA7456E7CFCDE700@SN6PR02MB4895.namprd02.prod.outlook.com>

Hi again,

Per Aleksandar's feedback, I'm finishing up the rewrite of the code imported from the existing Hexagon simulator.  Once I'm finished with that work, I'll start breaking down the code into a patch series.  I have a couple of questions I hope someone would be kind enough to answer.

Question 1:
I see this error from checkpatch.pl
ERROR: Macros with complex values should be enclosed in parenthesis
However, there are times when the code will not compile with parenthesis.  For example, we have a file that defined all the instruction attributes.  Each line has
DEF_ATTRIB(LOAD, "Loads from memory", "", "")
So, we create an enum of all the possible attributes as follows
enum {
#define DEF_ATTRIB(NAME, ...) A_##NAME,
#include "attribs_def.h"
#undef DEF_ATTRIB
};
This is one simple example.  We also things like create an array of values or a series of small functions or cases in a switch statement.

Question 2:
What is the best source of guidance on breaking down support for a new target into a patch series?  I see avr being reviewed currently.  I have mostly new files: 12 in linux-user/hexagon, and ~50 in target/hexagon.  I also need to add test cases and a container for the toolchain.  Is it OK to break things down mostly at file boundaries?  In some cases small files could be combined, and large files would be broken down into reviewable chunks.  Late in the series, I can introduce the changes to common code.  The implication of having the common code changes late is that code would compile and run only at the end of the series.

Thanks,
Taylor


-----Original Message-----
From: Qemu-devel <qemu-devel-bounces+tsimpson=quicinc.com@nongnu.org> On Behalf Of Taylor Simpson
Sent: Thursday, November 14, 2019 6:54 PM
To: Richard Henderson <richard.henderson@linaro.org>; Alex Bennée <alex.bennee@linaro.org>; qemu-devel@nongnu.org
Cc: Alessandro Di Federico <ale@rev.ng>; nizzo@rev.ng; Niccolò Izzo <izzoniccolo@gmail.com>; Aleksandar Markovic <aleksandar.m.mail@gmail.com>
Subject: RE: QEMU for Qualcomm Hexagon - KVM Forum talk and code available

OK, I changed the code in github and will upstream it that way.



-----Original Message-----
From: Richard Henderson <richard.henderson@linaro.org>
Sent: Wednesday, November 13, 2019 3:10 PM
To: Taylor Simpson <tsimpson@quicinc.com>; Alex Bennée <alex.bennee@linaro.org>; qemu-devel@nongnu.org
Cc: Alessandro Di Federico <ale@rev.ng>; nizzo@rev.ng; Niccolò Izzo <izzoniccolo@gmail.com>; Aleksandar Markovic <aleksandar.m.mail@gmail.com>
Subject: Re: QEMU for Qualcomm Hexagon - KVM Forum talk and code available

On 11/13/19 8:31 PM, Taylor Simpson wrote:
> [Taylor] Currently, I have the generator and the generated code sitting in the source tree.  I'm flexible on this if the decision is to regenerate it every time.

I would prefer to regenerate every time, and not store the generated code in the source tree at all.  It makes it a no-brainer to modify the source and not have to remember how to regenerate, because the rules are right there in the makefile.


r~

  reply	other threads:[~2019-12-17 18:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25 16:26 Taylor Simpson
2019-11-01 18:29 ` Philippe Mathieu-Daudé
2019-11-04  2:35   ` Taylor Simpson
2019-11-05  0:05 ` Aleksandar Markovic
2019-11-05 16:32   ` Taylor Simpson
2019-11-12 22:52     ` Taylor Simpson
2019-11-13 10:31       ` Alex Bennée
2019-11-13 19:31         ` Taylor Simpson
2019-11-13 21:10           ` Richard Henderson
2019-11-15  0:54             ` Taylor Simpson
2019-12-17 18:14               ` Taylor Simpson [this message]
2019-12-17 18:19                 ` Thomas Huth
2019-12-17 18:21                 ` Peter Maydell
2019-12-17 18:41                   ` Philippe Mathieu-Daudé
2019-12-17 18:44                     ` Philippe Mathieu-Daudé
2019-12-18 23:50                   ` Richard Henderson
2019-11-13 21:27         ` Peter Maydell
2019-11-19  9:12       ` Philippe Mathieu-Daudé

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=BYAPR02MB488640DD7CC887E5FCC0F167DE500@BYAPR02MB4886.namprd02.prod.outlook.com \
    --to=tsimpson@quicinc.com \
    --cc=ale@rev.ng \
    --cc=aleksandar.m.mail@gmail.com \
    --cc=alex.bennee@linaro.org \
    --cc=izzoniccolo@gmail.com \
    --cc=nizzo@rev.ng \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --subject='RE: QEMU for Qualcomm Hexagon - KVM Forum talk and code available' \
    /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

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