From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1gUd-0008G0-1t for qemu-devel@nongnu.org; Mon, 30 Jun 2014 14:40:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1gUX-0008Vj-FH for qemu-devel@nongnu.org; Mon, 30 Jun 2014 14:39:54 -0400 Received: from mail-pd0-x235.google.com ([2607:f8b0:400e:c02::235]:63161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1gUX-0008VP-5M for qemu-devel@nongnu.org; Mon, 30 Jun 2014 14:39:49 -0400 Received: by mail-pd0-f181.google.com with SMTP id v10so8676727pde.12 for ; Mon, 30 Jun 2014 11:39:47 -0700 (PDT) Sender: Richard Henderson Message-ID: <53B1AEEF.8010108@twiddle.net> Date: Mon, 30 Jun 2014 11:39:43 -0700 From: Richard Henderson MIME-Version: 1.0 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> <20140624212450.GB18016@ZenIV.linux.org.uk> <53A9EE7E.4020802@twiddle.net> <20140625070117.GD18016@ZenIV.linux.org.uk> <20140626055541.GF18016@ZenIV.linux.org.uk> In-Reply-To: <20140626055541.GF18016@ZenIV.linux.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Al Viro Cc: qemu-devel@nongnu.org On 06/25/2014 10:55 PM, Al Viro wrote: > On Wed, Jun 25, 2014 at 08:01:17AM +0100, Al Viro wrote: >> On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote: >>> On 06/24/2014 02:24 PM, Al Viro wrote: >>>> Al, off to figure out the black magic TCG is using to generate calls... >>> >>> If you've a helper >>> >>> DEF_HELPER_1(halt, void, i64) >>> >>> then >>> >>> gen_helper_halt(...) >>> >>> will generate the tcg ops that result in the call. >> >> Another fun issue: >> >> CVTTQ is both underreporting the overflow *AND* reports the wrong kind - FOV >> instead of IOV. >> >> * it misses reporting overflows for case when it *knows* that >> overflow will happen - the need to shift up by more than 63 bits. >> Trivially fixed, of course. There overflow cases leave wrong >> result as well - should be 0. >> * it also misses reporting overflows for case when value is in >> ranges 2^63..2^64-1 and -2^64+1..-2^63-1. And yes, it's >> asymmetric - 2^63 is an overflow, -2^63 isn't. >> * overflow is reported by float_raise(float_flag_overflow, &FP_STATUS). >> Wrong flag - it should be IOV, not FOV. And it should be set >> in FPCR regardless of the trap modifier (IOV, this VI thing is >> wrong - we should deal with that only when we generate a trap). >> * All overflow cases should raise INE as well. >> >> Could we steal bit 1 in float_exception_flags for IOV? It is (currently?) >> unused - >> enum { >> float_flag_invalid = 1, >> float_flag_divbyzero = 4, >> float_flag_overflow = 8, >> float_flag_underflow = 16, >> float_flag_inexact = 32, >> float_flag_input_denormal = 64, >> float_flag_output_denormal = 128 >> }; >> >> That would allow to deal with that crap nicely - we could have it raise >> the new flag, then have helper_fp_exc_raise_... for default trap mode >> mask it out (and yes, we need to set FPCR flags in default mode, as well >> as /U and /V - confirmed by direct experiment *and* by TFM). > > OK, I've managed to resurrect UP1000 box (FSVO resurrect - the southbridge > DMA controller has always been buggered, with intermittent noise on one of > the data lines; fans in CPU module are FUBAR as well - 17 and 20 RPM resp., > so I don't risk keeping it running for long, etc.) > > Still, that allows to test EV67 and I hope to resurrect a DS10 box as well, > which will allow for saner testing environment. > > Current delta follows, fixing gcc and libc testcases *and* AFAICS getting > CVTTQ handling in line with what actual EV67 is doing. It's a dirty hack > wrt float_raise() - relies on bit 1 never being raised by softfpu.c. I'll > look into separating that bit, but it'll probably have non-zero costs ;-/ > We need two flags - "has IOV been raised during this insn" (in this patch > it's bit 1 of fp_status.float_exception_flags, cleaned along with those) > and something to keep FPCR.IOV in (in this patch - bit 1 of fpcr_exc_status). > Sure, we can add another uint8_t or two in struct CPUAlphaState, but that'll > mean extra PITA in code and extra memory accesses... > > Review would be welcome. Looks good. I've split it up into a couple of smaller patches, made some sylistic tweaks and pushed it to git://github.com/rth7680/qemu.git axp-next I'm starting to do some testing now, but a glance though would be helpful. Especially to see if I didn't make some silly mistake in the process. r~