On Fri, 26 May 2000, David Brownlee wrote:

> On Wed, 24 May 2000, Ben Harris wrote:
> 
> > 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).
> > 
> 	It just seems an odd thing to ship in binary form.

Indeed.  I think that's where we started.

>       Maybe TestFloat
> 	with the full library should all be in regress?

I think I shall make it so that the sources can be built into the normal
library, but aren't by default, and then have TestFloat (in regress) build
it like that and use it.

> 	I still have a vauge feeling that maybe the regress tests should
> 	use FLOAT64_{,DE}MANGLE, but I could buy either way.

Erm, they do, in order to make the system floating-point routines look
like the normal SoftFloat ones.  So systfloat.c contains things like:

float64 syst_float64_add( float64 a, float64 b )
{
    float64 z;

    a = FLOAT64_MANGLE(a);
    b = FLOAT64_MANGLE(b);
    *( (double *) &z ) = *( (double *) &a ) + *( (double *) &b );
    return FLOAT64_DEMANGLE(z);

}

> > 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>
> > 
> 	That isn't helped by shared libraries on NetBSD/mips being, um,
> 	somewhat crippled by having to comply with the MIPS ELF ABI, which
> 	is done (IIRC) by a bunch of assembler jammed in around each call
> 	(which does not get any pipelining or similar optimisations from
> 	the compiler). Static code also suffers on MIPS.
> 
> 	I'd definitely benchmark in on arm26 :)

OK.  Once I've got a dynamic linker...

> > > >  - 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.

Hmm.  I suspect that teasing apart the float32 and float64 parts of the
library might be feasible, and printf only uses doubles, so that would
probably be a worthwhile thing to do.  Later.

> 	Didn't RiscIX have some strange compression technique for on disk
> 	filesm - not aligning sectoins on page boundaries?

Something like that.  There's a program called "squeeze" which reduces the
amount of disc space used by an executable without changing its size as
seen by "ls".  I've no idea how it works yet.

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