From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=58148 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q1fnQ-0002yI-TW
	for qemu-devel@nongnu.org; Mon, 21 Mar 2011 10:09:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <froydnj@codesourcery.com>) id 1Q1fnP-0003BI-Ar
	for qemu-devel@nongnu.org; Mon, 21 Mar 2011 10:09:24 -0400
Received: from mail.codesourcery.com ([38.113.113.100]:40030)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <froydnj@codesourcery.com>) id 1Q1fnP-0003B7-1w
	for qemu-devel@nongnu.org; Mon, 21 Mar 2011 10:09:23 -0400
Date: Mon, 21 Mar 2011 07:09:21 -0700
From: Nathan Froyd <froydnj@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] target-arm/helper.c: For float-int
	conversion helpers pass ints as ints
Message-ID: <20110321140921.GL30619@codesourcery.com>
References: <1300123391-27275-1-git-send-email-peter.maydell@linaro.org>
	<20110321134808.GG30619@codesourcery.com>
	<AANLkTin__xQYUSwrRTcumXkeF+aPwy1kA_Cagy=bZaF3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTin__xQYUSwrRTcumXkeF+aPwy1kA_Cagy=bZaF3@mail.gmail.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, patches@linaro.org

On Mon, Mar 21, 2011 at 02:04:31PM +0000, Peter Maydell wrote:
> On 21 March 2011 13:48, Nathan Froyd <froydnj@codesourcery.com> wrote:
> > I like the direction this patch goes; you aren't by any chance going to
> > convert the passing/returning of float* to their appropriate int* types
> > too, are you?
> 
> Nope -- I think that where we're passing or returning an actual
> IEEE single/double to a helper function "float*" is a better type
> than uint32_t: it gives information about what the helper's argument
> semantically is, and it means we don't have every helper that takes
> or returns a float have to include ugly calls to the boxing/unboxing
> macros.

I'm just concerned about what would happen if we turned on softfloat's
"float types are structure types" bit; I'm pretty sure everything would
break horribly on targets that don't pass small structures in
registers.  Admittedly, several targets would be broken by doing so, so
it's not particularly urgent.

-Nathan