This is the mail archive of the
mailing list for the GCC project.
Re: Preprocessor arithmetic
On Wed, Nov 15, 2000 at 03:30:20PM +0100, Hans-Peter Nilsson wrote:
> > Date: Wed, 15 Nov 2000 01:01:49 -0800
> > From: "Zack Weinberg" <zackw@Stanford.EDU>
> > I dimly remember someone offering us a complete replacement for
> > fp-bit.c, which got ignored by the mailing list. I may have
> > hallucinated this - casual search of the archive doesn't show it. If
> > it happened, it would've been in early 1999.
> A search for "tege floating point" turned up this as #1:
> Would be nice if fp-bit was replaced. It is 3 times slower than
> the (older, less correct) floatlib.c for CRIS.
> What were the issues with that new library? Is there any reason
> why it isn't used, besides common inertia and lack of time to
> check it? I haven't tried it, though, but I take Tege's word
> for it (until I get time to test it).
Hard to say when no one said anything about it. I imagine floating
point emulation isn't important to most developers, who work on chips
with hardware FPUs.
I'm prepared to take Tege's word for the functionality. It'd need a
bit of work to fit into the current framework; fp-bit currently gets
split up with #ifdefs so that we get only one routine per object file,
and the embedded people won't want to lose that. Shouldn't be hard
As Tege suggested downthread, I think replacing real.c with ieeelib.c
might be interesting. For one thing, if it were fast enough that we
could use it all the time, we could stop worrying about trapping
SIGFPE and attempting to recover. And real.c is a crawling horror
I'd like to see the code at least checked into the tree; then we can
convert over incrementally.