On 20 April 2013 17:52, Niel van der Westhuizen <nielg...@gmail.com> 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
