From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJ1IG-0003mS-3u for qemu-devel@nongnu.org; Sun, 08 May 2011 06:32:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QJ1IE-0000IS-W3 for qemu-devel@nongnu.org; Sun, 08 May 2011 06:32:56 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:36816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJ1IE-0000IM-To for qemu-devel@nongnu.org; Sun, 08 May 2011 06:32:54 -0400 Received: by qyk10 with SMTP id 10so3580287qyk.4 for ; Sun, 08 May 2011 03:32:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <201105061738.09777.paul@codesourcery.com> References: <1304686095-30265-1-git-send-email-peter.maydell@linaro.org> <201105061509.37212.paul@codesourcery.com> <201105061738.09777.paul@codesourcery.com> From: Blue Swirl Date: Sun, 8 May 2011 13:32:34 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 4/7] target-arm: Refactor int-float conversions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Peter Maydell , qemu-devel@nongnu.org, patches@linaro.org On Fri, May 6, 2011 at 7:38 PM, Paul Brook wrote: >> On Fri, May 6, 2011 at 5:09 PM, Paul Brook wrote= : >> >> The Neon versions of int-float conversions need their own helper >> >> routines because they must use the "standard FPSCR" rather than the >> >> default one. Refactor the helper functions to make it easy to add the >> >> neon versions. While we're touching the code, move the helpers to >> >> op_helper.c so that we can use the global env variable rather than >> >> passing it as a parameter. >> > >> > IMO this is going in the wrong direction. =C2=A0We should in aiming fo= r less >> > implicit accesses to cpu state, not more. >> >> Performance wise global env variable is faster and the register is >> always available. > > Not entirely true. =C2=A0Reserving the global env variable has significan= t cost, > especially on hosts with limited register sets (i.e. x86). =C2=A0It's als= o a rather > fragile hack. =C2=A0There's a fairly long history of nasy hacks and thing= s that > just don't work in this context. =C2=A0For example you can't reliably inc= lude > stdio.h from these files, and they often break if you turn optimization o= ff, > which makes debugging much harder than it should be. Even if we don't reserve the register, in many cases a corresponding pointer to CPUState will be needed. But there will still be the advantage that this temporary pointer can be discarded while the globally reserved register is reserved forever. >> Do you mean that we should aim to get rid of special >> status of global env, so that if no op uses it, it could be discarded >> to free a register? > > That's already true for most of qemu. =C2=A0IMO more interesting is being= able to > tell TCG that helpers don't mess with cpu state in opaque ways. =C2=A0In = theory > it's already possible to do that manually. However that tends to be somew= hat > fragile, relying on careful maintenance and code code auditing, with mist= akes > triggering subtle hard-to-debug failures. =C2=A0Much better to avoid the = implicit > global interface and make all helper arguments explicit. OK. This will be a major refactoring, but given the expected performance increase, it should be done. >> > Maybe better would be to explicitly pass a pointer the fp status. That >> > way you don't even need separate VFP and NEON variants of these >> > routines. >> >> It would be nice to have generic float functions callable directly as >> TCG helper. > > Possibly. =C2=A0I'd have to look quite a bit closer to determine whether = exposing > the generic float functions is useful in practice, or if you still end up > needing wrappers in most cases for most targets. =C2=A0Adding "native" fl= oating > point support to the TCG interface is also a possibility. =C2=A0In practi= ce this > might end up as wrappers around helper functions, but might provide a nic= er > programming interface. > > Paul >