From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=49108 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PnwaA-0001Kx-Fo
	for qemu-devel@nongnu.org; Fri, 11 Feb 2011 12:14:59 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <froydnj@codesourcery.com>) id 1Pnwa9-0006JA-63
	for qemu-devel@nongnu.org; Fri, 11 Feb 2011 12:14:58 -0500
Received: from mail.codesourcery.com ([38.113.113.100]:37068)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <froydnj@codesourcery.com>) id 1Pnwa8-0006J2-Pt
	for qemu-devel@nongnu.org; Fri, 11 Feb 2011 12:14:56 -0500
Date: Fri, 11 Feb 2011 09:14:54 -0800
From: Nathan Froyd <froydnj@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] target-arm: Move Neon VUZP to a
	helper function
Message-ID: <20110211171454.GQ6247@codesourcery.com>
References: <1297440841-17979-1-git-send-email-peter.maydell@linaro.org>
	<1297440841-17979-2-git-send-email-peter.maydell@linaro.org>
	<AANLkTimJwF2+be=TVTDSkjp0=X14oam1kwF2d_zCFcGH@mail.gmail.com>
	<20110211170346.GP6247@codesourcery.com>
	<AANLkTinSMVtohnyApqmAcZ1t5AYGJmx_8H2tU49oxXME@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTinSMVtohnyApqmAcZ1t5AYGJmx_8H2tU49oxXME@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 Fri, Feb 11, 2011 at 05:12:32PM +0000, Peter Maydell wrote:
> On 11 February 2011 17:03, Nathan Froyd <froydnj@codesourcery.com> wrote:
> > I do think the preferred way would be to extract rd, rm, size, and Q
> > up-front, rather than having the helper twiddle instruction bits.
> 
> OK. You're happy to still have the helper do the reading and
> writing of env->vfp.regs[] directly, though?

I think you can make a case either way, but you're passing enough values
already that accessing env->vfp.regs directly in the helper seems
reasonable.

-Nathan