So, when I implemented the soft-float code (now a very long time ago), it
came in several rounds:
	- A custom written (but v. slow, single precision) FPEmulator
	  for the kernel (fpe-sp, for those that remember it)
	- A version of ARM's FPEmulator for the kernel
	- A version of ARM's FP library (which ARM hacked out the FPE :) )
	  for user space
	- A version of the 'softfloat' C code for user space
The last option was decided as the best choice; the two in-kernel FP
emulators were desirable to move away from because of the performance
problems associated with instruction set decode and exit. The ARM FP
library, while very fast, suffered a number of IEEE compliance problems at
the time (which hit during trying to get the suite to pass the 'JCK" Java
conformance test---large amounts of time spent on this made us realise
that any library that isn't IEEE compliant causes more trouble that it's
worth in the long term) while softfloat was pretty damn close to full IEEE
and was very easy to modify (the ARM code was harer to modify because I
had to bulid it under RiscOS at the time). Also, a lot of macroised
instructions in softfloat headers could have been very easily optimised
and tuned into assembler, but I never yhad time to do this. However, the
glue code for the ARM aws written so that the next version of the library
(v2) could be slotted in *very* easily with almost no effor, however I
never got round to this either. And since then, I decided that the current
FP is fast enough for non-FP tasks (eg X) and if you want ot do FP stuff
(eg povray) you're much better just buying a $300 PC instead.

Regarding where to put the library: The library was under a very free
licence, and we did't want to encumber it (and the changes made) by
putting it under the GPL. Also, we originally put it into a separate
library but that also made it very difficult to link with in terms of the
link order dependencies. libm was never an option.

I hope this explains some of the reasoning behind the choices made.

	Regards,

	Neil