From: Peter Maydell <peter.maydell@linaro.org>
To: Michael Rolnik <mrolnik@gmail.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Initial commit of AVR cores
Date: Sun, 29 May 2016 13:45:44 +0100 [thread overview]
Message-ID: <CAFEAcA96+K8DjE3vUs1vGbLJMou4PtpfCwa8VSrxDp_jRqAkrw@mail.gmail.com> (raw)
In-Reply-To: <CAK4993gh8De=RsYfPdhN31Rv=1vUCBaQceSeMsZFH2-iwr-kig@mail.gmail.com>
On 29 May 2016 at 09:57, Michael Rolnik <mrolnik@gmail.com> wrote:
> 1. Initial commit of AVR 8bit cores support
> 2. all instruction, except BREAK/DES/SPM/SPMX, are implemented
> 3. not fully tested yet, however I was able to execute simple code with
> functions. e.g fibonacci calculation
> 4. the current patch includes a non real, sample board
> 5. this patch does not include any peripheral devices.
> 6. no fuses support yet. PC is set to 0 at reset.
Hi; thanks for this contribution to QEMU. Unfortunately as
it is it isn't really reviewable. If you could take a look
at our documentation on how to submit patches and follow
those recommendations that would be very helpful:
http://wiki.qemu.org/Contribute/SubmitAPatch
In particular, you need to split this single huge
patch up into multiple separate patches which each
do one thing and which aren't too large, and you should
then send those as a set of patch emails, rather than
an email with a patch in an attachment. You should
also make sure there aren't any unnecessary changes
in there too (for instance, what are your changes to
gdbstub.c for?). You might find it helpful to look back
through the qemu-devel archives for where other people
added new-architecture support to see how they
structured their patchsets and what kinds of issues
were raised on code review that might apply to your
patches too.
As a random thing I noticed just scrolling through your
patch, you'll also want to change all these unions:
+typedef union avr_opcode_LDI_1110aaaabbbbcccc_u {
+ uint16_t opcode;
+ struct { uint16_t lImm:4;
+ uint16_t Rd:4;
+ uint16_t hImm:4;
+ uint16_t:4; /* 1110 */
+ };
+} avr_opcode_LDI_1110aaaabbbbcccc_t;
to something else -- bitfield layouts aren't portable
(there's no guarantees about endianness, for instance).
Most targets use the bitops.h functions like extract32().
thanks
-- PMM
prev parent reply other threads:[~2016-05-29 12:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-29 8:57 [Qemu-devel] Initial commit of AVR cores Michael Rolnik
2016-05-29 12:45 ` Peter Maydell [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=CAFEAcA96+K8DjE3vUs1vGbLJMou4PtpfCwa8VSrxDp_jRqAkrw@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=mrolnik@gmail.com \
--cc=qemu-devel@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).