From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NlmLJ-0000MX-Vp for qemu-devel@nongnu.org; Sun, 28 Feb 2010 11:50:10 -0500 Received: from [199.232.76.173] (port=33908 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NlmLJ-0000MG-Be for qemu-devel@nongnu.org; Sun, 28 Feb 2010 11:50:09 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NlmLH-0004yZ-OA for qemu-devel@nongnu.org; Sun, 28 Feb 2010 11:50:09 -0500 Received: from hall.aurel32.net ([88.191.82.174]:51398) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NlmLH-0004yC-En for qemu-devel@nongnu.org; Sun, 28 Feb 2010 11:50:07 -0500 Date: Sun, 28 Feb 2010 17:49:57 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH 0/6] target-alpha: fpu qualifiers, round 2 Message-ID: <20100228164957.GL10291@volta.aurel32.net> References: <4B2BFD85.6070702@twiddle.net> <20100223225825.GS10348@hall.aurel32.net> <4B850C87.8060101@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <4B850C87.8060101@twiddle.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: laurent.desnogues@gmail.com, qemu-devel@nongnu.org On Wed, Feb 24, 2010 at 12:24:55PM +0100, Richard Henderson wrote: > On 02/23/2010 02:58 PM, Aurelien Jarno wrote: > >>I have totally rewritten the patch to be more along the line > >>that Laurent was suggesting, in that the rounding mode and other > >>qualifiers are totally parsed within the translator. I no longer > >>pass the FN11 field to the helper functions. > > > >What's the benefit of doing that? I don't say it's wrong, I just want > >to understand. Otherwise the patch looks good, so it can probably be > >applied without any change. > > I seem to recall Laurent opining that doing the interpretation > of the opcode in two different places was less than clean, and > in the end I agree with him. > > FWIW, this configuration would also be compatible with a > future TCG enhancement to generate fp code, whereas the first > config would not. I have applied the patch, but in order to avoid doing the same for all targets, it might be a good idea to directly provide TCG functions to modify FP_STATUS instead of using the interface from softfloat.h. This would also have the advantage of clearly defining this interface, and make sure that the alpha target is not broken by a change in softfloat.h. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net