qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 3/7] softfloat: Convert `*_default_nan' varia


From: Maciej W. Rozycki
Subject: Re: [Qemu-devel] [PATCH v2 3/7] softfloat: Convert `*_default_nan' variables into inline functions
Date: Sat, 31 Jan 2015 14:58:46 +0000 (GMT)
User-agent: Alpine 2.11 (LFD 23 2013-08-11)

On Sat, 31 Jan 2015, Peter Maydell wrote:

> >> >  Hmm, so perhaps my idea for a later improvement:
> >> >
> >> >>  Eventually we might want to move the new inline functions into a
> >> >> separate header to be included from softfloat.h instead of softfloat.c,
> >> >> but let's make changes one step at a time.
> >> >
> >> > will actually have to be made right away.  I suspect GCC is more liberal
> >> > here due to its convoluted extern/static/inline semantics history.
> >> > Sigh...
> >>
> >> I would suggest just using "static inline", as we do elsewhere
> >> for little utility functions.
> >
> >  Yes, that's exactly what they'd have to be moved into a separate header
> > for.
> 
> Why do they need to be moved into a different header to do this?
> I must be missing something...

 This is because fpu/softfloat-specialize.h is an implementation header 
private to SoftFloat and therefore such inline definitions won't be seen 
by users outside SoftFloat, such as target-mips/msa_helper.c.  And IMO 
they shouldn't be moved into include/fpu/softfloat.h itself as this header 
contains generic stuff and is supposed to have no TARGET_foo stuff, as 
observed by current usage and inferred from comments in fpu/softfloat.c.

 So ultimately I think the newly converted `*_default_nan' inline 
functions will need to go into include/fpu/softfloat-public-specialize.h 
or suchlike, which will be pulled from include/fpu/softfloat.h for general 
availability.

 Overall I think the whole arrangement in fpu/softfloat-specialize.h has a 
potential to being cleaned up by removing all the chains of #ifdef's and 
splitting the conditional bits into separate headers matching the current 
variants.  E.g. the presence of this construct:

#if defined(TARGET_SPARC)
const float64 float64_default_nan = const_float64(LIT64( 0x7FFFFFFFFFFFFFFF ));
#elif defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_ALPHA)
const float64 float64_default_nan = const_float64(LIT64( 0x7FF8000000000000 ));
#elif SNAN_BIT_IS_ONE
const float64 float64_default_nan = const_float64(LIT64( 0x7FF7FFFFFFFFFFFF ));
#else
const float64 float64_default_nan = const_float64(LIT64( 0xFFF8000000000000 ));
#endif

asks for 4 independent headers defining the 4 bit pattern styles used by 
targets for symbolic FP data, one each -- perhaps even pulled indirectly 
via target headers rather than copying the chain of #ifdef's above around 
#include's from wherever they'll be pulled.

 Please correct me if I am wrong, but it appears to me possible right away 
by removing fpu/softfloat-specialize.h and instead creating individual 
target-*/softfloat-specialize.h headers that'll pull the right variant 
each target requires from a pool of templates made available in fpu/.  
Then include/fpu/softfloat.h could do the same for the public stuff (i.e. 
these NaN bits concerned here) placed similarly in include/fpu/.

 FWIW,

  Maciej



reply via email to

[Prev in Thread] Current Thread [Next in Thread]