Subject: possible arm32 fp tuning project.
To: None <port-arm32@netbsd.org>
From: Todd Whitesel <toddpw@best.com>
List: port-arm32
Date: 10/09/1998 03:19:33
(This is mostly directed at Mark B. and Todd V., but anyone else with info
is welcome to jump in.)

I've been looking at the arm32 FP lib code with an eye towards tuning it.

But before I start ripping it up, I figured I'd better do some reality checks.

Is the software floating point provided by EGCS sufficiently crappier that
we should not try to use it?

Would it cause problems if I were to split up the FP library into lots of
little .o's so that only the actually used functions are linked in?

Is there a provision for machine-dependent versions of math.h so I could
stuff in some inline functions if that made sense?

What is our policy on GCC changes? I have access to formidable GNU help at
work (and my day job is maintaining a local edition of GDB), so this is not
an idle threat. :) I could beef up the ARM machine description if it made
sense to do that. Though I would have to watch out for hardware FP support.

Speaking of which, do we use the same wacky storage format as the ARM
hardware floating point unit, or are our doubles fully little endian?

And most importantly, are there known testsuites that the current code
passes that I should use for regression checking?

(I plan to use at least paranoia and whatever else I can find on the net.)

Todd Whitesel
toddpw @ best.com