From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54704 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOwcm-0002Oi-NA for qemu-devel@nongnu.org; Wed, 16 Jun 2010 13:42:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOwcZ-0001Tz-3P for qemu-devel@nongnu.org; Wed, 16 Jun 2010 13:41:55 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:49605) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOwcY-0001Tt-Um for qemu-devel@nongnu.org; Wed, 16 Jun 2010 13:41:51 -0400 Received: by vws17 with SMTP id 17so3061143vws.4 for ; Wed, 16 Jun 2010 10:41:50 -0700 (PDT) Sender: Richard Henderson Message-ID: <4C190CC6.9090400@twiddle.net> Date: Wed, 16 Jun 2010 10:41:26 -0700 From: Richard Henderson MIME-Version: 1.0 Subject: Re: [Qemu-devel] VLIW? References: <2CEA5ECB5C60A7469530D1EA92A1ABBB04C9A46216@NASANEXMB07.na.qualcomm.com> In-Reply-To: <2CEA5ECB5C60A7469530D1EA92A1ABBB04C9A46216@NASANEXMB07.na.qualcomm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gibbons, Scott" Cc: "qemu-devel@nongnu.org" 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~