qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] GSoC Idea: Motorola DSP56k


From: Peter Maydell
Subject: Re: [Qemu-devel] GSoC Idea: Motorola DSP56k
Date: Sun, 21 Apr 2013 10:50:36 +0100

On 20 April 2013 17:52, Niel van der Westhuizen <address@hidden> wrote:
> So I've been hacking away on an Xbox target in qemu
> (https://github.com/espes/xqemu). The Xbox APU contains a Motorola DSP56362
> core, and there's API and tooling for applications to generate and load
> custom "effects" consisting of DSP code, so a reasonable emulation of it
> seems to be required. I imagine it makes sense to implement it as a TCG
> frontend, but I do not know how annoying it would be to get it wired up as a
> component of a device and executing alongside x86...

Unfortunately the assumption that QEMU has only a single TCG frontend
at once is pretty heavily baked in (ie you have one CPU with possible
multiple cores but it's all the same architecture). I think it would
be nice to fix this, but it's pretty complicated to do it[*]. I would
think that doing that all by itself would be too big to do as a GSoC
project, let alone also adding a DSP tcg frontend on top.

[*] Some properties of the tcg frontend are compile time constants,
like "are we bigendian?", "what is the target_long type?". The TCG
codegen stuff also has a single global code cache, which obviously
would need to be split. [Actually it might well be better to split
it for even a single-arch system -- this could be a useful stepping
stone to proper MP-on-MP and/or fixing threading bugs with multithreaded
linux-user guests. Anyway, serious design decisions to be made in
that area.]

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]