From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpfvl-0007Ne-Bh for qemu-devel@nongnu.org; Thu, 29 Sep 2016 14:19:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpfvg-0004sW-9v for qemu-devel@nongnu.org; Thu, 29 Sep 2016 14:19:37 -0400 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:35840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpfvg-0004sI-1s for qemu-devel@nongnu.org; Thu, 29 Sep 2016 14:19:32 -0400 Received: by mail-wm0-x229.google.com with SMTP id w72so373580wmf.1 for ; Thu, 29 Sep 2016 11:19:31 -0700 (PDT) References: <34249C6D-327A-4ED4-BB2D-8E2F532A5720@gmail.com> <7e2274fa-f649-887c-c78e-7f5b09749450@redhat.com> <73DBF468-DE5E-4EF0-A54E-91AD38C74C1D@gmail.com> <20160929041750.GN8390@umbus.fritz.box> <340861B2-66E5-4A09-A96A-3C3516DEBD39@gmail.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <340861B2-66E5-4A09-A96A-3C3516DEBD39@gmail.com> Date: Thu, 29 Sep 2016 19:19:29 +0100 Message-ID: <87wphuvaa6.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [Qemu-ppc] How to add my implementation of the fmadds instruction to QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: David Gibson , Peter Maydell , "list@suse.de:PowerPC list:PowerPC" , qemu-devel qemu-devel Programmingkid writes: > On Sep 29, 2016, at 12:17 AM, David Gibson wrote: > >> On Tue, Sep 27, 2016 at 09:58:02AM -0700, Peter Maydell wrote: >>> On 27 September 2016 at 09:51, G 3 wrote: >>>> The problem with your reasoning is you assume this instruction has to be >>>> 100% correctly implemented. That every single "corner-case" has to be >>>> accounted for. >>> >>> For upstream QEMU we've already made this design decision -- >>> emulation accuracy comes first, and speed is secondary. >>> That's why we implement this the way we do. >> >> I think there is a way you could get both speed and accuracy, but it's >> a huge project: >> >> You'd need to add full float awareness to TCG - so floating point TCG >> values and floating point operations as tcp micro-ops, defined >> according to IEEE semantics. Then you'd need to rewrite the TCG >> frontends in terms of those new ops, at least for target CPUs close >> enough to IEEE semantics for that to work. And you'd need to rewrite >> the TCG backends to implement those fp ops in terms of host cpu fp >> instructions .. at least when the host has fp behaviour close enough >> to IEEE to make that work, with a fallback to soft float when that's >> not the case. > > Interesting idea. Do you think we would see a large enough increase in speed > to justify this project? It really depends on workload. If you want to run lots of encoding/audio workloads in TCG guests it is certainly something that could be improved. As others have pointed out however it is a fairly big project. -- Alex Bennée