All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] softfloat breaks cocoa.m
@ 2011-08-28 12:09 Andreas Färber
  2011-08-28 13:02 ` Alexander Graf
  0 siblings, 1 reply; 17+ messages in thread
From: Andreas Färber @ 2011-08-28 12:09 UTC (permalink / raw)
  To: Aurelien Jarno, Paolo Bonzini
  Cc: Peter Maydell, Anthony Liguori, QEMU Developers, Alexander Graf

Hello,

The unresolved softfloat uint* conversion business bites us again:  
This time, the previously working Cocoa frontend stopped compiling:

In file included from /Users/andreas/QEMU/qemu/bswap.h:14,
                  from /Users/andreas/QEMU/qemu/qemu-common.h:103,
                  from /Users/andreas/QEMU/qemu/ui/cocoa.m:28:
/Users/andreas/QEMU/qemu/fpu/softfloat.h:60: error: conflicting types  
for ‘uint16’
/System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:68:  
error: previous declaration of ‘uint16’ was here
make: *** [ui/cocoa.o] Error 1

Since commit cbbab9226da9572346837466a8770c117e7e65a2 (move unaligned  
memory access functions to bswap.h) softfloat.h is being #included in  
bswap.h, which gets pulled into cocoa.m through qemu-common.h. I  
thought Alex had set up a Darwin buildbot to catch such breakages...

Any thoughts on how to proceed? My previous approach for Haiku, to  
replace non-standard uint16 with POSIX uint_fast16_t etc., was  
rejected to avoid system-dependent widths. I'd really like to get rid  
of the annoyingly conflicting naming though (int vs. long for 32, int  
vs. short for 16, ...).

A fragile and ugly workaround is to suppress all softfloat usage  
within bswap.h (below).

Andreas


diff --git a/bswap.h b/bswap.h
index f41bebe..ddef453 100644
--- a/bswap.h
+++ b/bswap.h
@@ -11,7 +11,9 @@
  #include <machine/bswap.h>
  #else

+#ifndef NO_SOFTFLOAT_H
  #include "softfloat.h"
+#endif

  #ifdef CONFIG_BYTESWAP_H
  #include <byteswap.h>
@@ -239,6 +241,7 @@ static inline uint32_t qemu_bswap_len(uint32_t  
value, int len)
      return bswap32(value) >> (32 - 8 * len);
  }

+#ifndef NO_SOFTFLOAT_H
  typedef union {
      float32 f;
      uint32_t l;
@@ -294,6 +297,7 @@ typedef union {
      } ll;
  #endif
  } CPU_QuadU;
+#endif

  /* unaligned/endian-independent pointer access */

@@ -423,6 +427,7 @@ static inline void stq_le_p(void *ptr, uint64_t v)
      stl_le_p(p + 4, v >> 32);
  }

+#ifndef NO_SOFTFLOAT_H
  /* float access */

  static inline float32 ldfl_le_p(const void *ptr)
@@ -461,6 +466,8 @@ static inline void stfq_le_p(void *ptr, float64 v)
      stl_le_p(ptr + 4, u.l.upper);
  }

+#endif
+
  #else

  static inline int lduw_le_p(const void *ptr)
@@ -498,6 +505,7 @@ static inline void stq_le_p(void *ptr, uint64_t v)
      *(uint64_t *)ptr = v;
  }

+#ifndef NO_SOFTFLOAT_H
  /* float access */

  static inline float32 ldfl_le_p(const void *ptr)
@@ -520,6 +528,7 @@ static inline void stfq_le_p(void *ptr, float64 v)
      *(float64 *)ptr = v;
  }
  #endif
+#endif

  #if !defined(HOST_WORDS_BIGENDIAN) || defined(WORDS_ALIGNED)

@@ -612,6 +621,7 @@ static inline void stq_be_p(void *ptr, uint64_t v)
      stl_be_p((uint8_t *)ptr + 4, v);
  }

+#ifndef NO_SOFTFLOAT_H
  /* float access */

  static inline float32 ldfl_be_p(const void *ptr)
@@ -650,6 +660,8 @@ static inline void stfq_be_p(void *ptr, float64 v)
      stl_be_p((uint8_t *)ptr + 4, u.l.lower);
  }

+#endif
+
  #else

  static inline int lduw_be_p(const void *ptr)
@@ -687,6 +699,7 @@ static inline void stq_be_p(void *ptr, uint64_t v)
      *(uint64_t *)ptr = v;
  }

+#ifndef NO_SOFTFLOAT_H
  /* float access */

  static inline float32 ldfl_be_p(const void *ptr)
@@ -711,4 +724,6 @@ static inline void stfq_be_p(void *ptr, float64 v)

  #endif

+#endif
+
  #endif /* BSWAP_H */
diff --git a/ui/cocoa.m b/ui/cocoa.m
index d9e4e3d..4bd0346 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -25,6 +25,7 @@
  #import <Cocoa/Cocoa.h>
  #include <crt_externs.h>

+#define NO_SOFTFLOAT_H
  #include "qemu-common.h"
  #include "console.h"
  #include "sysemu.h"

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] softfloat breaks cocoa.m
  2011-08-28 12:09 [Qemu-devel] softfloat breaks cocoa.m Andreas Färber
@ 2011-08-28 13:02 ` Alexander Graf
  2011-08-28 13:32   ` Peter Maydell
  2011-08-28 13:34   ` Andreas Färber
  0 siblings, 2 replies; 17+ messages in thread
From: Alexander Graf @ 2011-08-28 13:02 UTC (permalink / raw)
  To: Andreas Färber
  Cc: Peter Maydell, Anthony Liguori, QEMU Developers, Blue Swirl,
	Paolo Bonzini, Aurelien Jarno


On 28.08.2011, at 07:09, Andreas Färber wrote:

> Hello,
> 
> The unresolved softfloat uint* conversion business bites us again: This time, the previously working Cocoa frontend stopped compiling:
> 
> In file included from /Users/andreas/QEMU/qemu/bswap.h:14,
>                 from /Users/andreas/QEMU/qemu/qemu-common.h:103,
>                 from /Users/andreas/QEMU/qemu/ui/cocoa.m:28:
> /Users/andreas/QEMU/qemu/fpu/softfloat.h:60: error: conflicting types for ‘uint16’
> /System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:68: error: previous declaration of ‘uint16’ was here
> make: *** [ui/cocoa.o] Error 1
> 
> Since commit cbbab9226da9572346837466a8770c117e7e65a2 (move unaligned memory access functions to bswap.h) softfloat.h is being #included in bswap.h, which gets pulled into cocoa.m through qemu-common.h. I thought Alex had set up a Darwin buildbot to catch such breakages...

No, that was only an idea so far. I don't have a spare Mac I could use for that atm :(.


> Any thoughts on how to proceed? My previous approach for Haiku, to replace non-standard uint16 with POSIX uint_fast16_t etc., was rejected to avoid system-dependent widths. I'd really like to get rid of the annoyingly conflicting naming though (int vs. long for 32, int vs. short for 16, ...).

I'm not sure what you mean by system-dependent widths? This is only a naming collision issue, right? Can't we just name the types something more qemu specific?


Alex

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] softfloat breaks cocoa.m
  2011-08-28 13:02 ` Alexander Graf
@ 2011-08-28 13:32   ` Peter Maydell
  2011-09-02 16:38     ` Peter Maydell
  2011-08-28 13:34   ` Andreas Färber
  1 sibling, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2011-08-28 13:32 UTC (permalink / raw)
  To: Alexander Graf
  Cc: Anthony Liguori, QEMU Developers, Blue Swirl,
	Andreas Färber, Paolo Bonzini, Aurelien Jarno

On 28 August 2011 14:02, Alexander Graf <agraf@suse.de> wrote:
> On 28.08.2011, at 07:09, Andreas Färber wrote:
>> Any thoughts on how to proceed? My previous approach for Haiku,
>> to replace non-standard uint16 with POSIX uint_fast16_t etc.,
>> was rejected to avoid system-dependent widths. I'd really like
>> to get rid of the annoyingly conflicting naming though (int vs.
>> long for 32, int vs. short for 16, ...).
>
> I'm not sure what you mean by system-dependent widths? This is
> only a naming collision issue, right? Can't we just name the types
> something more qemu specific?

If I recall the previous discussions correctly:

At the moment softfloat has its own typedefs (int16 etc) which
it uses to mean "an int which must be at least 16 bits wide but
may be larger"; the POSIX names for these (as Andreas says) are
int_fast16_t &c. (We've already converted softfloat's custom
typedefs for "int which must be exactly 16 bits" &c to use the
posix int16_t &c, so those are not a problem any more.)

There are two ways we can fix the naming clash here:

(1) change int16 -> int_fast16_t. This was argued against because
it means that the type might have a different width depending on
the host system, which means that where softfloat buggily makes
assumptions about the typewidth this would surface only on the
minority of systems where (eg) int_fast16_t wasn't 32 bits.
(In theory this is just preserving current behaviour but in fact
the set of typedefs in softfloat.h doesn't take advantage of the
"may be bigger" leeway; for example we 'typedef int8_t int8' even
though the comment above specifically suggests that int8 should
be typedef'd as an int.)

(2) change int16 -> int16_t. This was argued against because it
would be dropping the information in the current softfloat code
about where we require a 16 bit type for correctness and where
we are happy for the type to be larger if it's more efficient.

Unfortunately we didn't manage to come to a consensus on one
of these two approaches, which is why we haven't renamed the
offending types yet...

[Personally I prefer (2).]

-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] softfloat breaks cocoa.m
  2011-08-28 13:02 ` Alexander Graf
  2011-08-28 13:32   ` Peter Maydell
@ 2011-08-28 13:34   ` Andreas Färber
  2011-08-28 13:47     ` Alexander Graf
  2011-08-28 18:24     ` [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently Andreas Färber
  1 sibling, 2 replies; 17+ messages in thread
From: Andreas Färber @ 2011-08-28 13:34 UTC (permalink / raw)
  To: Alexander Graf
  Cc: Peter Maydell, Anthony Liguori, QEMU Developers, Blue Swirl,
	Paolo Bonzini, Aurelien Jarno

Am 28.08.2011 um 15:02 schrieb Alexander Graf:

> On 28.08.2011, at 07:09, Andreas Färber wrote:
>
>> Any thoughts on how to proceed? My previous approach for Haiku, to  
>> replace non-standard uint16 with POSIX uint_fast16_t etc., was  
>> rejected to avoid system-dependent widths. I'd really like to get  
>> rid of the annoyingly conflicting naming though (int vs. long for  
>> 32, int vs. short for 16, ...).
>
> I'm not sure what you mean by system-dependent widths?

The core issue is this: uint16 in fpu/ does not mean uint16_t but "at  
least 16 bits wide" (int). Apart from the BeOS/Haiku i386 ABI being  
strange in using long for uint32, most uses of uint16 elsewhere mean  
"exactly 16 bits wide", leading to type conflicts.

POSIX has two types for such least-width semantics: uint_least16_t and  
uint_fast16_t. We ran into the issue that a patch compiled on Darwin/ 
ppc64 but broke on Linux/x86_64 or i386, so Aurelien considered it too  
risky to use types whose actual width depends on the host system  
within my series.

> This is only a naming collision issue, right? Can't we just name the  
> types something more qemu specific?

We could, sure. I you agree on a replacement type, I'll happily supply  
patches to do the conversion.

Part of the problem was that, e.g., uint16 and int are being used  
interchangably in declaration and implementation.
I'll look into introducing matching uint16 etc. where necessary, so  
that the actual conversion can be done by regex.

Andreas

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] softfloat breaks cocoa.m
  2011-08-28 13:34   ` Andreas Färber
@ 2011-08-28 13:47     ` Alexander Graf
  2011-08-28 14:08       ` Peter Maydell
  2011-08-28 18:24     ` [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently Andreas Färber
  1 sibling, 1 reply; 17+ messages in thread
From: Alexander Graf @ 2011-08-28 13:47 UTC (permalink / raw)
  To: Andreas Färber
  Cc: Peter Maydell, Anthony Liguori, QEMU Developers, Blue Swirl,
	Paolo Bonzini, Aurelien Jarno


On 28.08.2011, at 08:34, Andreas Färber wrote:

> Am 28.08.2011 um 15:02 schrieb Alexander Graf:
> 
>> On 28.08.2011, at 07:09, Andreas Färber wrote:
>> 
>>> Any thoughts on how to proceed? My previous approach for Haiku, to replace non-standard uint16 with POSIX uint_fast16_t etc., was rejected to avoid system-dependent widths. I'd really like to get rid of the annoyingly conflicting naming though (int vs. long for 32, int vs. short for 16, ...).
>> 
>> I'm not sure what you mean by system-dependent widths?
> 
> The core issue is this: uint16 in fpu/ does not mean uint16_t but "at least 16 bits wide" (int). Apart from the BeOS/Haiku i386 ABI being strange in using long for uint32, most uses of uint16 elsewhere mean "exactly 16 bits wide", leading to type conflicts.
> 
> POSIX has two types for such least-width semantics: uint_least16_t and uint_fast16_t. We ran into the issue that a patch compiled on Darwin/ppc64 but broke on Linux/x86_64 or i386, so Aurelien considered it too risky to use types whose actual width depends on the host system within my series.

Well, if we want host machine dependent types we should use host dependent types. If not, why can't we just typedef them to uint32_t or uint64_t and call it a day? Apparently uint16 is expected to be uint32_t in the code IIUC.


Alex

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] softfloat breaks cocoa.m
  2011-08-28 13:47     ` Alexander Graf
@ 2011-08-28 14:08       ` Peter Maydell
  2011-08-28 16:10         ` Alexander Graf
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2011-08-28 14:08 UTC (permalink / raw)
  To: Alexander Graf
  Cc: Anthony Liguori, QEMU Developers, Blue Swirl,
	Andreas Färber, Paolo Bonzini, Aurelien Jarno

On 28 August 2011 14:47, Alexander Graf <agraf@suse.de> wrote:
> Well, if we want host machine dependent types we should use host
> dependent types.

...we couldn't decide what we wanted :-)

>Apparently uint16 is expected to be uint32_t in the code IIUC.

If the softfloat code relies on uint16 being exactly 32 bits
(or indeed on it being exactly 16 bits) then it has a bug in it.

-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] softfloat breaks cocoa.m
  2011-08-28 14:08       ` Peter Maydell
@ 2011-08-28 16:10         ` Alexander Graf
  0 siblings, 0 replies; 17+ messages in thread
From: Alexander Graf @ 2011-08-28 16:10 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Anthony Liguori, QEMU Developers, Blue Swirl,
	Andreas Färber, Paolo Bonzini, Aurelien Jarno


On 28.08.2011, at 09:08, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 28 August 2011 14:47, Alexander Graf <agraf@suse.de> wrote:
>> Well, if we want host machine dependent types we should use host
>> dependent types.
> 
> ...we couldn't decide what we wanted :-)
> 
>> Apparently uint16 is expected to be uint32_t in the code IIUC.
> 
> If the softfloat code relies on uint16 being exactly 32 bits
> (or indeed on it being exactly 16 bits) then it has a bug in it.

My point is that we can have it either host-dependent or not. Both apparently doesn't work :)

So the agnostic deterministic way would be to always use the same static type on all hosts.


Alex

> 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently
  2011-08-28 13:34   ` Andreas Färber
  2011-08-28 13:47     ` Alexander Graf
@ 2011-08-28 18:24     ` Andreas Färber
  2011-08-28 18:24       ` [Qemu-devel] [PATCH 2/2] softfloat: Use uint32 consistently Andreas Färber
                         ` (2 more replies)
  1 sibling, 3 replies; 17+ messages in thread
From: Andreas Färber @ 2011-08-28 18:24 UTC (permalink / raw)
  To: qemu-devel; +Cc: Andreas Färber

Prepares for uint16 replacement.

Signed-off-by: Andreas Färber <andreas.faerber@web.de>
---
 fpu/softfloat.c |    8 ++++----
 fpu/softfloat.h |    4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 7951a0e..be1206d 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -6011,10 +6011,10 @@ unsigned int float32_to_uint32_round_to_zero( float32 a STATUS_PARAM )
     return res;
 }
 
-unsigned int float32_to_uint16_round_to_zero( float32 a STATUS_PARAM )
+uint16 float32_to_uint16_round_to_zero( float32 a STATUS_PARAM )
 {
     int64_t v;
-    unsigned int res;
+    uint16 res;
 
     v = float32_to_int64_round_to_zero(a STATUS_VAR);
     if (v < 0) {
@@ -6065,10 +6065,10 @@ unsigned int float64_to_uint32_round_to_zero( float64 a STATUS_PARAM )
     return res;
 }
 
-unsigned int float64_to_uint16_round_to_zero( float64 a STATUS_PARAM )
+uint16 float64_to_uint16_round_to_zero( float64 a STATUS_PARAM )
 {
     int64_t v;
-    unsigned int res;
+    uint16 res;
 
     v = float64_to_int64_round_to_zero(a STATUS_VAR);
     if (v < 0) {
diff --git a/fpu/softfloat.h b/fpu/softfloat.h
index 3bb7d8f..e1bbe01 100644
--- a/fpu/softfloat.h
+++ b/fpu/softfloat.h
@@ -249,7 +249,7 @@ extern const float16 float16_default_nan;
 | Software IEC/IEEE single-precision conversion routines.
 *----------------------------------------------------------------------------*/
 int16 float32_to_int16_round_to_zero( float32 STATUS_PARAM );
-unsigned int float32_to_uint16_round_to_zero( float32 STATUS_PARAM );
+uint16 float32_to_uint16_round_to_zero( float32 STATUS_PARAM );
 int32 float32_to_int32( float32 STATUS_PARAM );
 int32 float32_to_int32_round_to_zero( float32 STATUS_PARAM );
 uint32 float32_to_uint32( float32 STATUS_PARAM );
@@ -352,7 +352,7 @@ extern const float32 float32_default_nan;
 | Software IEC/IEEE double-precision conversion routines.
 *----------------------------------------------------------------------------*/
 int16 float64_to_int16_round_to_zero( float64 STATUS_PARAM );
-unsigned int float64_to_uint16_round_to_zero( float64 STATUS_PARAM );
+uint16 float64_to_uint16_round_to_zero( float64 STATUS_PARAM );
 int32 float64_to_int32( float64 STATUS_PARAM );
 int32 float64_to_int32_round_to_zero( float64 STATUS_PARAM );
 uint32 float64_to_uint32( float64 STATUS_PARAM );
-- 
1.7.5.3

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [Qemu-devel] [PATCH 2/2] softfloat: Use uint32 consistently
  2011-08-28 18:24     ` [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently Andreas Färber
@ 2011-08-28 18:24       ` Andreas Färber
  2011-09-03 14:48         ` Peter Maydell
  2011-09-03 21:13         ` Blue Swirl
  2011-09-03 14:48       ` [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently Peter Maydell
  2011-09-03 21:13       ` Blue Swirl
  2 siblings, 2 replies; 17+ messages in thread
From: Andreas Färber @ 2011-08-28 18:24 UTC (permalink / raw)
  To: qemu-devel; +Cc: Andreas Färber

Prepares for uint32 replacement.

Signed-off-by: Andreas Färber <andreas.faerber@web.de>
---
 fpu/softfloat.c |   20 ++++++++++----------
 fpu/softfloat.h |    4 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index be1206d..2b20085 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -5965,20 +5965,20 @@ int float128_unordered_quiet( float128 a, float128 b STATUS_PARAM )
 }
 
 /* misc functions */
-float32 uint32_to_float32( unsigned int a STATUS_PARAM )
+float32 uint32_to_float32( uint32 a STATUS_PARAM )
 {
     return int64_to_float32(a STATUS_VAR);
 }
 
-float64 uint32_to_float64( unsigned int a STATUS_PARAM )
+float64 uint32_to_float64( uint32 a STATUS_PARAM )
 {
     return int64_to_float64(a STATUS_VAR);
 }
 
-unsigned int float32_to_uint32( float32 a STATUS_PARAM )
+uint32 float32_to_uint32( float32 a STATUS_PARAM )
 {
     int64_t v;
-    unsigned int res;
+    uint32 res;
 
     v = float32_to_int64(a STATUS_VAR);
     if (v < 0) {
@@ -5993,10 +5993,10 @@ unsigned int float32_to_uint32( float32 a STATUS_PARAM )
     return res;
 }
 
-unsigned int float32_to_uint32_round_to_zero( float32 a STATUS_PARAM )
+uint32 float32_to_uint32_round_to_zero( float32 a STATUS_PARAM )
 {
     int64_t v;
-    unsigned int res;
+    uint32 res;
 
     v = float32_to_int64_round_to_zero(a STATUS_VAR);
     if (v < 0) {
@@ -6029,10 +6029,10 @@ uint16 float32_to_uint16_round_to_zero( float32 a STATUS_PARAM )
     return res;
 }
 
-unsigned int float64_to_uint32( float64 a STATUS_PARAM )
+uint32 float64_to_uint32( float64 a STATUS_PARAM )
 {
     int64_t v;
-    unsigned int res;
+    uint32 res;
 
     v = float64_to_int64(a STATUS_VAR);
     if (v < 0) {
@@ -6047,10 +6047,10 @@ unsigned int float64_to_uint32( float64 a STATUS_PARAM )
     return res;
 }
 
-unsigned int float64_to_uint32_round_to_zero( float64 a STATUS_PARAM )
+uint32 float64_to_uint32_round_to_zero( float64 a STATUS_PARAM )
 {
     int64_t v;
-    unsigned int res;
+    uint32 res;
 
     v = float64_to_int64_round_to_zero(a STATUS_VAR);
     if (v < 0) {
diff --git a/fpu/softfloat.h b/fpu/softfloat.h
index e1bbe01..618ddee 100644
--- a/fpu/softfloat.h
+++ b/fpu/softfloat.h
@@ -216,8 +216,8 @@ void float_raise( int8 flags STATUS_PARAM);
 *----------------------------------------------------------------------------*/
 float32 int32_to_float32( int32 STATUS_PARAM );
 float64 int32_to_float64( int32 STATUS_PARAM );
-float32 uint32_to_float32( unsigned int STATUS_PARAM );
-float64 uint32_to_float64( unsigned int STATUS_PARAM );
+float32 uint32_to_float32( uint32 STATUS_PARAM );
+float64 uint32_to_float64( uint32 STATUS_PARAM );
 floatx80 int32_to_floatx80( int32 STATUS_PARAM );
 float128 int32_to_float128( int32 STATUS_PARAM );
 float32 int64_to_float32( int64 STATUS_PARAM );
-- 
1.7.5.3

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] softfloat breaks cocoa.m
  2011-08-28 13:32   ` Peter Maydell
@ 2011-09-02 16:38     ` Peter Maydell
  2011-09-02 18:18       ` Andreas Färber
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2011-09-02 16:38 UTC (permalink / raw)
  To: Alexander Graf
  Cc: Anthony Liguori, QEMU Developers, Blue Swirl,
	Andreas Färber, Paolo Bonzini, Aurelien Jarno

2011/8/28 Peter Maydell <peter.maydell@linaro.org>:
> On 28 August 2011 14:02, Alexander Graf <agraf@suse.de> wrote:
> There are two ways we can fix the naming clash here:
>
> (1) change int16 -> int_fast16_t. This was argued against because
> it means that the type might have a different width depending on
> the host system, which means that where softfloat buggily makes
> assumptions about the typewidth this would surface only on the
> minority of systems where (eg) int_fast16_t wasn't 32 bits.
> (In theory this is just preserving current behaviour but in fact
> the set of typedefs in softfloat.h doesn't take advantage of the
> "may be bigger" leeway; for example we 'typedef int8_t int8' even
> though the comment above specifically suggests that int8 should
> be typedef'd as an int.)
>
> (2) change int16 -> int16_t. This was argued against because it
> would be dropping the information in the current softfloat code
> about where we require a 16 bit type for correctness and where
> we are happy for the type to be larger if it's more efficient.

I think I was the main advocate for (1) here. If somebody felt
like doing a quick benchmark of int*_t vs int_fast*_t (just some
simple floatingpoint benchmark on a linux-user target that uses
TCG and softfloat) that might help break the deadlock one way
or the other. If there's no real difference in speed then I'd
be willing to see us take option (2) instead.

-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] softfloat breaks cocoa.m
  2011-09-02 16:38     ` Peter Maydell
@ 2011-09-02 18:18       ` Andreas Färber
  2011-09-03 14:49         ` Peter Maydell
  0 siblings, 1 reply; 17+ messages in thread
From: Andreas Färber @ 2011-09-02 18:18 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Anthony Liguori, Alexander Graf, QEMU Developers, Blue Swirl,
	Paolo Bonzini, Aurelien Jarno

Am 02.09.2011 um 18:38 schrieb Peter Maydell:

> 2011/8/28 Peter Maydell <peter.maydell@linaro.org>:
>> On 28 August 2011 14:02, Alexander Graf <agraf@suse.de> wrote:
>> There are two ways we can fix the naming clash here:
>>
>> (1) change int16 -> int_fast16_t. This was argued against because
>> it means that the type might have a different width depending on
>> the host system, which means that where softfloat buggily makes
>> assumptions about the typewidth this would surface only on the
>> minority of systems where (eg) int_fast16_t wasn't 32 bits.
>> (In theory this is just preserving current behaviour but in fact
>> the set of typedefs in softfloat.h doesn't take advantage of the
>> "may be bigger" leeway; for example we 'typedef int8_t int8' even
>> though the comment above specifically suggests that int8 should
>> be typedef'd as an int.)
>>
>> (2) change int16 -> int16_t. This was argued against because it
>> would be dropping the information in the current softfloat code
>> about where we require a 16 bit type for correctness and where
>> we are happy for the type to be larger if it's more efficient.
>
> I think I was the main advocate for (1) here. If somebody felt
> like doing a quick benchmark of int*_t vs int_fast*_t (just some
> simple floatingpoint benchmark on a linux-user target that uses
> TCG and softfloat) that might help break the deadlock one way
> or the other. If there's no real difference in speed then I'd
> be willing to see us take option (2) instead.

What about my preparatory patches? Can you ack them?

Andreas

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently
  2011-08-28 18:24     ` [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently Andreas Färber
  2011-08-28 18:24       ` [Qemu-devel] [PATCH 2/2] softfloat: Use uint32 consistently Andreas Färber
@ 2011-09-03 14:48       ` Peter Maydell
  2011-09-03 21:13       ` Blue Swirl
  2 siblings, 0 replies; 17+ messages in thread
From: Peter Maydell @ 2011-09-03 14:48 UTC (permalink / raw)
  To: Andreas Färber; +Cc: qemu-devel

On 28 August 2011 19:24, Andreas Färber <andreas.faerber@web.de> wrote:
> Prepares for uint16 replacement.
>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] [PATCH 2/2] softfloat: Use uint32 consistently
  2011-08-28 18:24       ` [Qemu-devel] [PATCH 2/2] softfloat: Use uint32 consistently Andreas Färber
@ 2011-09-03 14:48         ` Peter Maydell
  2011-09-03 21:13         ` Blue Swirl
  1 sibling, 0 replies; 17+ messages in thread
From: Peter Maydell @ 2011-09-03 14:48 UTC (permalink / raw)
  To: Andreas Färber; +Cc: qemu-devel

On 28 August 2011 19:24, Andreas Färber <andreas.faerber@web.de> wrote:
> Prepares for uint32 replacement.
>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] softfloat breaks cocoa.m
  2011-09-02 18:18       ` Andreas Färber
@ 2011-09-03 14:49         ` Peter Maydell
  0 siblings, 0 replies; 17+ messages in thread
From: Peter Maydell @ 2011-09-03 14:49 UTC (permalink / raw)
  To: Andreas Färber
  Cc: Anthony Liguori, Alexander Graf, QEMU Developers, Blue Swirl,
	Paolo Bonzini, Aurelien Jarno

On 2 September 2011 19:18, Andreas Färber <andreas.faerber@web.de> wrote:
> What about my preparatory patches? Can you ack them?

Sorry, yeah, I'd missed those; that cleanup is worth doing
whatever we decide to do here. Now reviewed.

-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently
  2011-08-28 18:24     ` [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently Andreas Färber
  2011-08-28 18:24       ` [Qemu-devel] [PATCH 2/2] softfloat: Use uint32 consistently Andreas Färber
  2011-09-03 14:48       ` [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently Peter Maydell
@ 2011-09-03 21:13       ` Blue Swirl
  2011-09-21  0:35         ` Gauresh Rane
  2 siblings, 1 reply; 17+ messages in thread
From: Blue Swirl @ 2011-09-03 21:13 UTC (permalink / raw)
  To: Andreas Färber; +Cc: qemu-devel

Thanks, applied.

On Sun, Aug 28, 2011 at 6:24 PM, Andreas Färber <andreas.faerber@web.de> wrote:
> Prepares for uint16 replacement.
>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> ---
>  fpu/softfloat.c |    8 ++++----
>  fpu/softfloat.h |    4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index 7951a0e..be1206d 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -6011,10 +6011,10 @@ unsigned int float32_to_uint32_round_to_zero( float32 a STATUS_PARAM )
>     return res;
>  }
>
> -unsigned int float32_to_uint16_round_to_zero( float32 a STATUS_PARAM )
> +uint16 float32_to_uint16_round_to_zero( float32 a STATUS_PARAM )
>  {
>     int64_t v;
> -    unsigned int res;
> +    uint16 res;
>
>     v = float32_to_int64_round_to_zero(a STATUS_VAR);
>     if (v < 0) {
> @@ -6065,10 +6065,10 @@ unsigned int float64_to_uint32_round_to_zero( float64 a STATUS_PARAM )
>     return res;
>  }
>
> -unsigned int float64_to_uint16_round_to_zero( float64 a STATUS_PARAM )
> +uint16 float64_to_uint16_round_to_zero( float64 a STATUS_PARAM )
>  {
>     int64_t v;
> -    unsigned int res;
> +    uint16 res;
>
>     v = float64_to_int64_round_to_zero(a STATUS_VAR);
>     if (v < 0) {
> diff --git a/fpu/softfloat.h b/fpu/softfloat.h
> index 3bb7d8f..e1bbe01 100644
> --- a/fpu/softfloat.h
> +++ b/fpu/softfloat.h
> @@ -249,7 +249,7 @@ extern const float16 float16_default_nan;
>  | Software IEC/IEEE single-precision conversion routines.
>  *----------------------------------------------------------------------------*/
>  int16 float32_to_int16_round_to_zero( float32 STATUS_PARAM );
> -unsigned int float32_to_uint16_round_to_zero( float32 STATUS_PARAM );
> +uint16 float32_to_uint16_round_to_zero( float32 STATUS_PARAM );
>  int32 float32_to_int32( float32 STATUS_PARAM );
>  int32 float32_to_int32_round_to_zero( float32 STATUS_PARAM );
>  uint32 float32_to_uint32( float32 STATUS_PARAM );
> @@ -352,7 +352,7 @@ extern const float32 float32_default_nan;
>  | Software IEC/IEEE double-precision conversion routines.
>  *----------------------------------------------------------------------------*/
>  int16 float64_to_int16_round_to_zero( float64 STATUS_PARAM );
> -unsigned int float64_to_uint16_round_to_zero( float64 STATUS_PARAM );
> +uint16 float64_to_uint16_round_to_zero( float64 STATUS_PARAM );
>  int32 float64_to_int32( float64 STATUS_PARAM );
>  int32 float64_to_int32_round_to_zero( float64 STATUS_PARAM );
>  uint32 float64_to_uint32( float64 STATUS_PARAM );
> --
> 1.7.5.3
>
>
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] [PATCH 2/2] softfloat: Use uint32 consistently
  2011-08-28 18:24       ` [Qemu-devel] [PATCH 2/2] softfloat: Use uint32 consistently Andreas Färber
  2011-09-03 14:48         ` Peter Maydell
@ 2011-09-03 21:13         ` Blue Swirl
  1 sibling, 0 replies; 17+ messages in thread
From: Blue Swirl @ 2011-09-03 21:13 UTC (permalink / raw)
  To: Andreas Färber; +Cc: qemu-devel

Thanks, applied.

On Sun, Aug 28, 2011 at 6:24 PM, Andreas Färber <andreas.faerber@web.de> wrote:
> Prepares for uint32 replacement.
>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> ---
>  fpu/softfloat.c |   20 ++++++++++----------
>  fpu/softfloat.h |    4 ++--
>  2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index be1206d..2b20085 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -5965,20 +5965,20 @@ int float128_unordered_quiet( float128 a, float128 b STATUS_PARAM )
>  }
>
>  /* misc functions */
> -float32 uint32_to_float32( unsigned int a STATUS_PARAM )
> +float32 uint32_to_float32( uint32 a STATUS_PARAM )
>  {
>     return int64_to_float32(a STATUS_VAR);
>  }
>
> -float64 uint32_to_float64( unsigned int a STATUS_PARAM )
> +float64 uint32_to_float64( uint32 a STATUS_PARAM )
>  {
>     return int64_to_float64(a STATUS_VAR);
>  }
>
> -unsigned int float32_to_uint32( float32 a STATUS_PARAM )
> +uint32 float32_to_uint32( float32 a STATUS_PARAM )
>  {
>     int64_t v;
> -    unsigned int res;
> +    uint32 res;
>
>     v = float32_to_int64(a STATUS_VAR);
>     if (v < 0) {
> @@ -5993,10 +5993,10 @@ unsigned int float32_to_uint32( float32 a STATUS_PARAM )
>     return res;
>  }
>
> -unsigned int float32_to_uint32_round_to_zero( float32 a STATUS_PARAM )
> +uint32 float32_to_uint32_round_to_zero( float32 a STATUS_PARAM )
>  {
>     int64_t v;
> -    unsigned int res;
> +    uint32 res;
>
>     v = float32_to_int64_round_to_zero(a STATUS_VAR);
>     if (v < 0) {
> @@ -6029,10 +6029,10 @@ uint16 float32_to_uint16_round_to_zero( float32 a STATUS_PARAM )
>     return res;
>  }
>
> -unsigned int float64_to_uint32( float64 a STATUS_PARAM )
> +uint32 float64_to_uint32( float64 a STATUS_PARAM )
>  {
>     int64_t v;
> -    unsigned int res;
> +    uint32 res;
>
>     v = float64_to_int64(a STATUS_VAR);
>     if (v < 0) {
> @@ -6047,10 +6047,10 @@ unsigned int float64_to_uint32( float64 a STATUS_PARAM )
>     return res;
>  }
>
> -unsigned int float64_to_uint32_round_to_zero( float64 a STATUS_PARAM )
> +uint32 float64_to_uint32_round_to_zero( float64 a STATUS_PARAM )
>  {
>     int64_t v;
> -    unsigned int res;
> +    uint32 res;
>
>     v = float64_to_int64_round_to_zero(a STATUS_VAR);
>     if (v < 0) {
> diff --git a/fpu/softfloat.h b/fpu/softfloat.h
> index e1bbe01..618ddee 100644
> --- a/fpu/softfloat.h
> +++ b/fpu/softfloat.h
> @@ -216,8 +216,8 @@ void float_raise( int8 flags STATUS_PARAM);
>  *----------------------------------------------------------------------------*/
>  float32 int32_to_float32( int32 STATUS_PARAM );
>  float64 int32_to_float64( int32 STATUS_PARAM );
> -float32 uint32_to_float32( unsigned int STATUS_PARAM );
> -float64 uint32_to_float64( unsigned int STATUS_PARAM );
> +float32 uint32_to_float32( uint32 STATUS_PARAM );
> +float64 uint32_to_float64( uint32 STATUS_PARAM );
>  floatx80 int32_to_floatx80( int32 STATUS_PARAM );
>  float128 int32_to_float128( int32 STATUS_PARAM );
>  float32 int64_to_float32( int64 STATUS_PARAM );
> --
> 1.7.5.3
>
>
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently
  2011-09-03 21:13       ` Blue Swirl
@ 2011-09-21  0:35         ` Gauresh Rane
  0 siblings, 0 replies; 17+ messages in thread
From: Gauresh Rane @ 2011-09-21  0:35 UTC (permalink / raw)
  To: qemu-devel

I am still not able to compile this with these changes.

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2011-09-21  5:40 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-28 12:09 [Qemu-devel] softfloat breaks cocoa.m Andreas Färber
2011-08-28 13:02 ` Alexander Graf
2011-08-28 13:32   ` Peter Maydell
2011-09-02 16:38     ` Peter Maydell
2011-09-02 18:18       ` Andreas Färber
2011-09-03 14:49         ` Peter Maydell
2011-08-28 13:34   ` Andreas Färber
2011-08-28 13:47     ` Alexander Graf
2011-08-28 14:08       ` Peter Maydell
2011-08-28 16:10         ` Alexander Graf
2011-08-28 18:24     ` [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently Andreas Färber
2011-08-28 18:24       ` [Qemu-devel] [PATCH 2/2] softfloat: Use uint32 consistently Andreas Färber
2011-09-03 14:48         ` Peter Maydell
2011-09-03 21:13         ` Blue Swirl
2011-09-03 14:48       ` [Qemu-devel] [PATCH 1/2] softfloat: Use uint16 consistently Peter Maydell
2011-09-03 21:13       ` Blue Swirl
2011-09-21  0:35         ` Gauresh Rane

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.