Re: [Qemu-devel] xtensa: new target architecture for qemu

[Blue Swirl]

On Sat, Apr 30, 2011 at 12:08 AM, Max Filippov <address@hidden> 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