On Mon, 22 May 2000, Ben Harris wrote:

> I've spent the last couple of weeks (when not doing Real Work or mending
> laser printers) hammering the current version of SoftFloat into working
> with NetBSD/arm26 and trying to work out how to import it sensibly into
> NetBSD in a machine-independent manner.  The following issues are
> currently worrying me:
> 
>  - It's been suggested that SoftFloat should be available as a library in
> its own right, as well as being built into the guts of libc.  This seems
> vaguely sensible (the libc version is a stripped-down and rather mangled
> version of the real thing), but it seems like an odd thing to ship with an
> OS.
> 
	It might make more sense to have the full library available via
	pkgsrc?

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

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

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

>  - At present on arm{32,26}, fpsetsticky and friends are defined in terms
> of sfp_setsticky etc, which in turn look at SoftFloat's internal
> variables.  I think the sfp_* versions should be renamed out of the user's
> namespace, and probably dispensed with altogether.
> 
	Sounds sensible to me (but who am I to say :)

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

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

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