Date: Wed, 10 Mar 2010 21:05:00 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Peter Jeremy <peterjeremy@acm.org> Cc: freebsd-sparc64@freebsd.org Subject: Re: gcc code generation problems Message-ID: <20100310200500.GD18466@alchemy.franken.de> In-Reply-To: <20100310101420.GB37825@server.vk2pj.dyndns.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 10, 2010 at 09:14:20PM +1100, Peter Jeremy wrote: > On 2010-Mar-10 08:18:07 +1100, Peter Jeremy <peterjeremy@acm.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100310200500.GD18466>