From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49075)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <viro@ftp.linux.org.uk>) id 1WzYCz-0003IO-98
	for qemu-devel@nongnu.org; Tue, 24 Jun 2014 17:24:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <viro@ftp.linux.org.uk>) id 1WzYCy-0004A0-D9
	for qemu-devel@nongnu.org; Tue, 24 Jun 2014 17:24:53 -0400
Received: from zeniv.linux.org.uk ([2002:c35c:fd02::1]:39031)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <viro@ftp.linux.org.uk>) id 1WzYCy-00049r-6u
	for qemu-devel@nongnu.org; Tue, 24 Jun 2014 17:24:52 -0400
Date: Tue, 24 Jun 2014 22:24:50 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
Message-ID: <20140624212450.GB18016@ZenIV.linux.org.uk>
References: <20140624043423.GX18016@ZenIV.linux.org.uk>
	<20140624165244.GY18016@ZenIV.linux.org.uk>
	<53A9C47C.2050002@twiddle.net>
	<20140624203244.GZ18016@ZenIV.linux.org.uk>
	<53A9E650.2020709@twiddle.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53A9E650.2020709@twiddle.net>
Sender: Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: qemu-devel@nongnu.org

On Tue, Jun 24, 2014 at 01:57:52PM -0700, Richard Henderson wrote:
> On 06/24/2014 01:32 PM, Al Viro wrote:
> > If you have any ideas for testing, I do have working hw (the box that is
> > currently alive is ev45, though; I _can_ try to boot a UP1000 one, but
> > I make no promises regarding its fans, both in PSU and in CPU module ;-/)
> 
> Ah.  Gotta be careful with ev4/45... half of the fpu is unimplemented, and so
> if you're not careful all you're testing is the kernel emulation behaviour.

*nod*

> > Um?  No, I mean having gen_fp_exc_raise() generate a call of one of the 8
> > helpers; gen_ieee_arith3() and friends would remain as-is.  It's just that
> > instead of generating load to exc, andi, call of helper_fp_exc_raise_s or
> > call of helper_fp_exc_raise we would generate a call of one of the
> > helper_fp_exc_raise{,_u,_v,_s,_su,_sui,_sv,_svi} and let that sucker deal
> > with loading exc, updating ->fpcr_exc_status and generating traps.
> 
> Ah, I getcha.  Yes, that makes sense.

FWIW, the crudest version of that is simply
+    env->fpcr_exc_status |= (uint8_t)env->fp_status.float_exception_flags;
in the very beginning of helper_fp_exc_raise_s().  And yes, it recovers
math/tests-misc.c, even though it's obviously not a good final fix.

Al, off to figure out the black magic TCG is using to generate calls...