On Wed, 24 May 2000, David Brownlee wrote:

> On Mon, 22 May 2000, Ben Harris wrote:
[ shipping softfloat.o ]
> 	It might make more sense to have the full library available via
> 	pkgsrc?

Probably, though it'd be a bit odd given the source will be in the tree
(and it has to be built if you want TestFloat to work).

> >  - The ARM is strange and stores the words of a double in big-endian order
> > despite being mostly little-endian.  I've hacked SoftFloat into workking
> > with this by inserting FLOAT64_MANGLE and FLOAT64_DEMANGLE (appropriately
> > defined) where necessary, but this is an ugly hack.  When not building as
> > part of libc, this is disabled, so TestFloat can check I've got this right
> > (I seem to have now).
> > 
> 	Sorry for missing something here - but would it make sense to 
> 	'adjust' TestFloat on arm to perform the same dance?

Erm, I don't think so, but I suspect there's some misunderstanding here.

TestFloat contains three floating-point implementations.  slowfloat is the
slow, but probably correct software implementation.  softfloat is the
SoftFloat library built standalone.  systfloat is a wrapper around the
system's floating-point implementation.  I've compiled slowfloat and
softfloat with floating-point numbers in the sane endianness, and then
made systfloat munge them before and after using passing them to and from
the version of softfloat in libc.  This has two advantages:

 - I end up testing an un-munged SoftFloat against a munged one, and hence
   can check the munging is correct.
 - I don't have to apply the munging to slowfloat.

> >  - The archives of this list seem to indicate that dynamically linking
> > against SoftFloat causes a huge performance hit.  This might make it worth
> > building it as a static library like libgcc.a.
> > 
> 	Presuambly a dynamically linked function incurs an extra lookup
> 	and redirection on each call. I can imagine this would give
> 	a measurable hit, but I would have expected enough to be happening
> 	in each function that it would not be overwhelming... ?

I'd expect that too, but Jason reported a factor of two on MIPS.
<URL:http://mail-index.netbsd.org/port-mips/2000/03/04/0001.html>

> >  - SoftFloat currently ends up as one big object file, plus a couple of
> > files of glue.  It might be helpful if it were split up, but the number of
> > shared internal functions would make this an interesting exercise.  Is 17k
> > off every static executable that calls printf a big deal anyway?
> > 
> 	Quite possibly - given the root filesystem is all statically
> 	linked and the size of many disks in arm26 systems.

True, though the overhead of everything rounding up to the 32k page size
is rather worse.

> >  - TestFloat should probably be integrated into the tree somewhere.
> > 
> 	src/regress would seem to be the obvious location...

Indeed.  I'd probably put it under regress/lib/libc, though it doesn't
only test libc.

> 	Just curious, but is there scope for the few arm machines with
> 	real FPUs? Possibly via a compile time option.

Well, -mhard-float should work, but we'd need kernel support for (a)
floating-point context-switching and (b) handling instructions the FPA
doesn't implement.  They're currently at the bottom of my TODO list.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>