Yes, as a guest. Thanks for the helpful suggestions. We have a closed pipeline and code errors are caught by the assembler. Delaying writeback is most likely what I'll be doing.
Another question I have is how to handle this multithreaded architecture. This seems to be extraordinarily difficult as a dynamic translation problem and I'll probably defer it to later. But, if anyone has any suggestions, I'd be glad to hear them. Thanks, --Scott ----------------------------------------------------------- Qualcomm Inc. / Hexagon Tools Austin, TX -----Original Message----- From: Richard Henderson [mailto:rth7...@gmail.com] On Behalf Of Richard Henderson Sent: Wednesday, June 16, 2010 12:41 PM To: Gibbons, Scott Cc: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] VLIW? On 06/15/2010 08:53 AM, Gibbons, Scott wrote: > Has anyone done a port of QEMU to a VLIW architecture? I'm interested > in seeing what was done. Do you mean as guest or host? I presume guest. There's not such a port in the main repository; I don't know what might have been done privately. It'll be a more difficult job if you have an open pipeline, but even then I should think it could be done. It really depends on the exact specification of your cpu. For instance, with a closed pipeline, I think all you would need to track during translation are the output temporaries. You would translate each member instruction sequentially, but delay writeback to the architectual register until the end of the vliw packet. With an open pipeline, I imagine that you would model each exposed architectural feature. For instance, if a load insn places its result onto a bus in the cycle following the issue of the load, then you could model the bus with a TCG register and have the translator be responsible for issuing moves between the TCG registers during appropriate cycles. I imagine the difficulty increases (but not intractably) if you want the translator to catch and signal user coding errors in the vliw assembly. Though usually that's a job that can be performed statically by the assembler... r~
