From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzXOZ-0006Wf-DT for qemu-devel@nongnu.org; Tue, 24 Jun 2014 16:32:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzXOY-0004tH-GW for qemu-devel@nongnu.org; Tue, 24 Jun 2014 16:32:47 -0400 Received: from zeniv.linux.org.uk ([2002:c35c:fd02::1]:38979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzXOY-0004sx-9T for qemu-devel@nongnu.org; Tue, 24 Jun 2014 16:32:46 -0400 Date: Tue, 24 Jun 2014 21:32:44 +0100 From: Al Viro Message-ID: <20140624203244.GZ18016@ZenIV.linux.org.uk> References: <20140624043423.GX18016@ZenIV.linux.org.uk> <20140624165244.GY18016@ZenIV.linux.org.uk> <53A9C47C.2050002@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A9C47C.2050002@twiddle.net> Sender: Al Viro Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org On Tue, Jun 24, 2014 at 11:33:32AM -0700, Richard Henderson wrote: > > return (unsigned long)x; // SVCTQ/SVC CVTTQ/SVC, of course... > Clearly a gross misunderstanding of what bits are actually computed, never mind > what gets signaled. > > Thanks for the test. I've not had working hardware for a couple of years to > validate what's supposed to get set and what isn't. 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 ;-/) > > Can't we simply have separate helpers for various trap suffices, with > > all this work on getting exc, etc. taken inside them? It's not as if > > we distinguished many variants, after all... Right now we have: > > plain, /U, /V > > /S, /SU > > /SUI > > /SV > > /SVI > > We used to have separate helpers... at least for the modes that had been > implemented at the time. The combinatorial explosion ugly though -- 4 > different versions of add, sub, etc. I thought the partial inlining was a > decent solution, as far as maintainability, but it's not unreasonable to disagree. 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. > > Another thing: shouldn't arithmetics on denorms without /S raise EXC_M_INV, > > rather than EXC_M_UNF? > > No idea. Should they? They seem to - both from the arch.manual and from direct experiment... And they do set FPCR.INV at the same time, not just trigger the trap.