From: Blue Swirl <blauwirbel@gmail.com>
To: Max Filippov <jcmvbkbc@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] xtensa: new target architecture for qemu
Date: Sat, 30 Apr 2011 10:07:47 +0300 [thread overview]
Message-ID: <BANLkTimZD-8ei3Xt+LCvdO7Qz1LxZ8tcxA@mail.gmail.com> (raw)
In-Reply-To: <BANLkTinJo81e_e=QRPEN8_hs33p+ph6UpA@mail.gmail.com>
On Sat, Apr 30, 2011 at 12:08 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> Hello.
>
> I'm developing support for new qemu target architecture: xtensa [1],
> primarily because AFAIK there's no free/open simulator for this
> architecture.
>
> Essential ISA parts (like core opcodes, special registers, windowed
> registers, exceptions and interrupts) are implemented, other (like
> TLB, MMU, caches, coprocessors, rare opcodes) are not, although I'm
> planning to implement them if/when needed.
Nice work. What is the status, can the emulator boot Linux for example?
> I'm wondering if this target could be eligible for inclusion into qemu mainline.
> If it is, could anyone please review the code [2]?
Please send the patch set for easier reviewing to the list, use
scripts/checkpatch.pl to avoid some predictable issues.
> There are several known issues which I'm planning to address:
> - mixed coding style;
> - no copyrights/license (it is BSD);
> - no direct TB linking;
> - dummy cpu_halted/cpu_has_work.
>
> If you see more, please report, especially if you know how to fix them (:
- rebase to HEAD
- fix/rearrange patches should be merged to the original commits so
that they are bug free
- commit descriptions are short/nonexistent
- options field does not necessarily belong to CPUState, see for
example Sparc sparc_def_t how the different models are handled
- env->options or env->singlestep shouldn't be used in disas_insn (it
shouldn't take env parameter at all) but the fields should be copied
to DisasContext and used from there
- macros should be replaced by inline functions (or enums) when possible
- pointers to CPU and chipset docs should be added
- commenting out code is a no-no
- there is no disassembler for target, can you check if binutils
before GPLv3 switch contains one? It should be easy to add.
- if possible, simcall should become a linux-user target instead
next prev parent reply other threads:[~2011-04-30 7:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 21:08 [Qemu-devel] xtensa: new target architecture for qemu Max Filippov
2011-04-30 7:07 ` Blue Swirl [this message]
2011-04-30 8:24 ` Max Filippov
2011-04-30 9:06 ` Blue Swirl
2011-04-30 10:25 ` Peter Maydell
2011-04-30 12:47 ` Max Filippov
2011-04-30 12:42 ` Max Filippov
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=BANLkTimZD-8ei3Xt+LCvdO7Qz1LxZ8tcxA@mail.gmail.com \
--to=blauwirbel@gmail.com \
--cc=jcmvbkbc@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).