| Message ID | 1298040557-6342-3-git-send-email-christophe.lyon@st.com |
|---|---|
| State | New |
| Headers | show |
On Fri, Feb 18, 2011 at 03:49:15PM +0100, Christophe Lyon wrote: > These constants and utility function are needed to implement some > helpers. Defining constants avoids the need to re-compute them at > runtime. > > Signed-off-by: Christophe Lyon <christophe.lyon@st.com> > --- > fpu/softfloat.h | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/fpu/softfloat.h b/fpu/softfloat.h > index f34a938..9bd4a50 100644 > --- a/fpu/softfloat.h > +++ b/fpu/softfloat.h > @@ -379,9 +379,15 @@ INLINE int float32_is_zero_or_denormal(float32 a) > return (float32_val(a) & 0x7f800000) == 0; > } > > +INLINE float32 float32_set_sign(float32 a, int sign) > +{ > + return make_float32((float32_val(a) & 0x7fffffff) | (sign << 31)); > +} > + > #define float32_zero make_float32(0) > #define float32_one make_float32(0x3f800000) > #define float32_ln2 make_float32(0x3f317218) > +#define float32_infinity make_float32(0x7f800000) > > > /*---------------------------------------------------------------------------- > @@ -482,6 +488,9 @@ INLINE int float64_is_any_nan(float64 a) > #define float64_zero make_float64(0) > #define float64_one make_float64(0x3ff0000000000000LL) > #define float64_ln2 make_float64(0x3fe62e42fefa39efLL) > +#define float64_half make_float64(0x3fe0000000000000LL) > +#define float64_256 make_float64(0x4070000000000000LL) > +#define float64_512 make_float64(0x4080000000000000LL) > > /*---------------------------------------------------------------------------- > | The pattern for a default generated double-precision NaN. While it's probably a good idea to define the commonly used values in softfloat.h, I don't think we should have all the values used by the different targets here. Infinity, one, half, two probably have their place here, I don't think it's the case of 256 and 512. It should be better to defined them at the target level. Also for consistency, I think it's better to define these value for all float size, or at least for all the common ones (32, 64, maybe 16).
On 20 February 2011 21:52, Aurelien Jarno <aurelien@aurel32.net> wrote: > On Fri, Feb 18, 2011 at 03:49:15PM +0100, Christophe Lyon wrote: >> +#define float64_half make_float64(0x3fe0000000000000LL) >> +#define float64_256 make_float64(0x4070000000000000LL) >> +#define float64_512 make_float64(0x4080000000000000LL) >> >> /*---------------------------------------------------------------------------- >> | The pattern for a default generated double-precision NaN. > > While it's probably a good idea to define the commonly used values in > softfloat.h, I don't think we should have all the values used by the > different targets here. Infinity, one, half, two probably have their > place here, I don't think it's the case of 256 and 512. It should be > better to defined them at the target level. Are you happy with targets just doing make_float*() on a bit pattern? I guess that's the most straightforward thing, although at the moment the target-arm code seems to prefer float32 three = int32_to_float32(3, s); I don't care very much personally as long as we're not doing a runtime division to get a constant 0.5 :-) Incidentally, if you're up for some target-mips cleanup: target-mips/op_helper.c:#define FLOAT_ONE32 make_float32(0x3f8 << 20) could be using float32_one instead. (ditto for float64). > Also for consistency, I > think it's better to define these value for all float size, or at least > for all the common ones (32, 64, maybe 16). I wouldn't bother with 16, only ARM uses that and only for conversions to other formats. -- PMM
On Sun, Feb 20, 2011 at 10:09:46PM +0000, Peter Maydell wrote: > On 20 February 2011 21:52, Aurelien Jarno <aurelien@aurel32.net> wrote: > > On Fri, Feb 18, 2011 at 03:49:15PM +0100, Christophe Lyon wrote: > > >> +#define float64_half make_float64(0x3fe0000000000000LL) > >> +#define float64_256 make_float64(0x4070000000000000LL) > >> +#define float64_512 make_float64(0x4080000000000000LL) > >> > >> /*---------------------------------------------------------------------------- > >> | The pattern for a default generated double-precision NaN. > > > > While it's probably a good idea to define the commonly used values in > > softfloat.h, I don't think we should have all the values used by the > > different targets here. Infinity, one, half, two probably have their > > place here, I don't think it's the case of 256 and 512. It should be > > better to defined them at the target level. > > Are you happy with targets just doing make_float*() on a > bit pattern? I guess that's the most straightforward thing, Yes, I think it is the way to go. > although at the moment the target-arm code seems to prefer > float32 three = int32_to_float32(3, s); > I don't care very much personally as long as we're not doing > a runtime division to get a constant 0.5 :-) Doing that at runtime is clearly not a good solution. > Incidentally, if you're up for some target-mips cleanup: > target-mips/op_helper.c:#define FLOAT_ONE32 make_float32(0x3f8 << 20) > > could be using float32_one instead. (ditto for float64). Yes, one is a really common value among target, and in my opinion we should keep it in softfloat.h. I have a local patch that does this cleanup and also moves the constant 2 to softfloat.h. I'll submit it one day with other mips softfloat cleanup. > > Also for consistency, I > > think it's better to define these value for all float size, or at least > > for all the common ones (32, 64, maybe 16). > > I wouldn't bother with 16, only ARM uses that and only for > conversions to other formats. > That's true, so let's do it float 32 and 64.
On 20.02.2011 23:20, Aurelien Jarno wrote: > On Sun, Feb 20, 2011 at 10:09:46PM +0000, Peter Maydell wrote: >> On 20 February 2011 21:52, Aurelien Jarno <aurelien@aurel32.net> wrote: >>> While it's probably a good idea to define the commonly used values in >>> softfloat.h, I don't think we should have all the values used by the >>> different targets here. Infinity, one, half, two probably have their >>> place here, I don't think it's the case of 256 and 512. It should be >>> better to defined them at the target level. >> >> Are you happy with targets just doing make_float*() on a >> bit pattern? I guess that's the most straightforward thing, > > Yes, I think it is the way to go. > OK I will change that. >>> Also for consistency, I >>> think it's better to define these value for all float size, or at least >>> for all the common ones (32, 64, maybe 16). >> >> I wouldn't bother with 16, only ARM uses that and only for >> conversions to other formats. >> > > That's true, so let's do it float 32 and 64. > I will add these too. Christophe.
diff --git a/fpu/softfloat.h b/fpu/softfloat.h index f34a938..9bd4a50 100644 --- a/fpu/softfloat.h +++ b/fpu/softfloat.h @@ -379,9 +379,15 @@ INLINE int float32_is_zero_or_denormal(float32 a) return (float32_val(a) & 0x7f800000) == 0; } +INLINE float32 float32_set_sign(float32 a, int sign) +{ + return make_float32((float32_val(a) & 0x7fffffff) | (sign << 31)); +} + #define float32_zero make_float32(0) #define float32_one make_float32(0x3f800000) #define float32_ln2 make_float32(0x3f317218) +#define float32_infinity make_float32(0x7f800000) /*---------------------------------------------------------------------------- @@ -482,6 +488,9 @@ INLINE int float64_is_any_nan(float64 a) #define float64_zero make_float64(0) #define float64_one make_float64(0x3ff0000000000000LL) #define float64_ln2 make_float64(0x3fe62e42fefa39efLL) +#define float64_half make_float64(0x3fe0000000000000LL) +#define float64_256 make_float64(0x4070000000000000LL) +#define float64_512 make_float64(0x4080000000000000LL) /*---------------------------------------------------------------------------- | The pattern for a default generated double-precision NaN.
These constants and utility function are needed to implement some helpers. Defining constants avoids the need to re-compute them at runtime. Signed-off-by: Christophe Lyon <christophe.lyon@st.com> --- fpu/softfloat.h | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)