Programmingkid <programmingk...@gmail.com> 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 <programmingk...@gmail.com> 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
