From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36472 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9IkW-0007T6-Q9 for qemu-devel@nongnu.org; Mon, 11 Apr 2011 11:09:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9IkV-00025W-8s for qemu-devel@nongnu.org; Mon, 11 Apr 2011 11:09:56 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:35267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9IkV-00025S-6Z for qemu-devel@nongnu.org; Mon, 11 Apr 2011 11:09:55 -0400 Received: by vws17 with SMTP id 17so4870583vws.4 for ; Mon, 11 Apr 2011 08:09:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110411145502.GY23480@codesourcery.com> References: <1302462785-8672-1-git-send-email-aurelien@aurel32.net> <20110411145502.GY23480@codesourcery.com> Date: Mon, 11 Apr 2011 16:09:53 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: [Qemu-devel] Re: [PATCH] target-sh4: get rid of CPU_{Float, Double}U List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nathan Froyd Cc: qemu-devel@nongnu.org, Aurelien Jarno On 11 April 2011 15:55, Nathan Froyd wrote: > On Sun, Apr 10, 2011 at 09:13:05PM +0200, Aurelien Jarno wrote: >> SH4 is always using softfloat, so it's possible to have helpers directly >> taking float32 or float64 value. This allow to get rid of conversions >> through CPU_{Float,Double}U. > > Eh, I think this punning on i32/f32 and i64/f64 values is not healthy. > But Peter's already said that the floats-as-structs bit of softfloat is > broken, so maybe it's not worth trying to ensure floats-as-structs works > (or even making it the default, to discourage people from bit-twiddling > directly). I guess I should clarify that about the floats-as-structs thing. (1) It does compile cleanly for the ARM target. Some other targets don't compile because they're (buggily) not using the boxing/unboxing macros when they do bit-twiddling of floats; that should be fixed. (2) I think most of the value is in whether it compiles OK or not, rather than trying to actually run with it as a config (which I agree with Nathan is likely to go wrong if you have a host which doesn't pass 32/64 bit structs in registers). The compile test catches cases where the C code is doing bit-twiddling on float32s. (3) If we did say you shouldn't be passing 'float32' etc into helper functions, this would make the def-helper.h support for 'f32' and 'f64' a bit pointless because they could never be used (4) I think you should be able to write a helper function for an add as just float32 HELPER(my_float_add)(float32 a, float32 b) { return float32_add(a, b, status); } and having to add boxing/unboxing macros to this reduces clarity for no real gain. Using the macros should be a sign you're doing something wrong, not that you're doing it right :-) -- PMM