Re: [Qemu-devel] [PATCH 4/7] target-arm: Refactor int-float conversions

[Paul Brook <paul@codesourcery.com>]

> On Fri, May 6, 2011 at 5:09 PM, Paul Brook <paul@codesourcery.com> 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.  We should in aiming for less
> > implicit accesses to cpu state, not more.
> 
> Performance wise global env variable is faster and the register is
> always available. 

Not entirely true.  Reserving the global env variable has significant cost, 
especially on hosts with limited register sets (i.e. x86).  It's also a rather 
fragile hack.  There's a fairly long history of nasy hacks and things that 
just don't work in this context.  For example you can't reliably include 
stdio.h from these files, and they often break if you turn optimization off, 
which makes debugging much harder than it should be.

> 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.  IMO more interesting is being able to 
tell TCG that helpers don't mess with cpu state in opaque ways.  In theory 
it's already possible to do that manually. However that tends to be somewhat 
fragile, relying on careful maintenance and code code auditing, with mistakes 
triggering subtle hard-to-debug failures.  Much better to avoid the implicit 
global interface and make all helper arguments explicit.

> > 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.  I'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.  Adding "native" floating 
point support to the TCG interface is also a possibility.  In practice this 
might end up as wrappers around helper functions, but might provide a nicer 
programming interface.

Paul