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. Maybe TestFloat
	with the full library should all be in regress?

> > >  - 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.
> 
	I still have a vauge feeling that maybe the regress tests should
	use FLOAT64_{,DE}MANGLE, but I could buy either way.

> > >  - 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>
> 
	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 :)

> > >  - 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.
> 
	The filesystem is usually in 8K/1K blocks.
	Adding 17K to each executable has ~50% chance of taking an extra
	precious 32k page if all paged in (though the odds on it needing
	to page it in may be a little lower).

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

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

	Thats seems a very reasonable place to have it :)


		David/absolute
				       -- www.netbsd.org: No hype required --