From owner-freebsd-sparc64@FreeBSD.ORG Wed Mar 10 20:05:05 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E44C81065674 for ; Wed, 10 Mar 2010 20:05:05 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 56A6A8FC1A for ; Wed, 10 Mar 2010 20:05:04 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o2AK51Jo062067; Wed, 10 Mar 2010 21:05:02 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o2AK505e062063; Wed, 10 Mar 2010 21:05:00 +0100 (CET) (envelope-from marius) Date: Wed, 10 Mar 2010 21:05:00 +0100 From: Marius Strobl To: Peter Jeremy Message-ID: <20100310200500.GD18466@alchemy.franken.de> References: <20100228192329.GA68252@server.vk2pj.dyndns.org> <20100308190301.GA69938@server.vk2pj.dyndns.org> <20100309102753.GC3978@server.vk2pj.dyndns.org> <20100309205048.GB18466@alchemy.franken.de> <20100309211807.GA34125@server.vk2pj.dyndns.org> <20100310101420.GB37825@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100310101420.GB37825@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: gcc code generation problems X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 20:05:06 -0000 On Wed, Mar 10, 2010 at 09:14:20PM +1100, Peter Jeremy wrote: > On 2010-Mar-10 08:18:07 +1100, Peter Jeremy wrote: > >My patch to fix all three problems is attached - it's slightly > >different to yours (and doesn't include any of the constification). > >We both seem to basically agree. I think my approach to RN_DECODE() > >should be somewhat faster (since it does less testing), though it > >meant re-defining FTYPE_LNG. > > I've revised my previous patch to remove two now-unused variables as > well as include the constification in your patch. Thanks, I've committed a merged version. > > After rebuilding libc, the eval.s program I posted a few days ago now > works correctly as posted and with the following modifications to the > two !!! blocks: > ((1 << 53) - 1) => %f34; fxtos %f34,%f20 > ((1 << 53) - 1) => %f34; fxtod %f34,%f40 > ((1 << 53) - 1) => %f34; fxtoq %f34,%f40 > 0x5a000000 => %f31; fstox %f31,%f32 > 0x433fffffffffffff => %f34; fdtox %f34,%f40 > (The above are all emulated according to the US-IIIi databook). > > Unfortunately, the following code: > 0x4033ffffffffffff => %f40; 0xf000000000000000 => %f42; fqtox %f40,%f30 > gives a result of 0x001ffffffffffff0 instead of 0x001fffffffffffff. > The low order bits (those in %f42) appear to be ignored. A similar > problem occurs with fqtod. faddq %f40,%f40,%f32 has the low > destination (%f34) shifted one bit right - which implies that the low > order register is ignored in only one argument. I don't see any > obvious issue anywhere and have elected to leave this problem for now. > fmovq does work but uses a different code-path. > > > (and have been > >thinking about how to create regression tests for the emulator). > > Two possibilities here are UCBTEST and TestFloat (note that SoftFloat > is already in the FreeBSD tree). I have copies of both but haven't > actually converted either into a suitable test harness. > FYI, the OpenSolaris source also includes a SPARC centric test suite in src/cmd/fps/fptest. Marius