How to build glibc for ppc variant w/o floating point?

Kai Ruottu kai.ruottu@luukku.com
Tue Jun 19 01:12:00 GMT 2001


Peter Barada wrote:
> 
> I'm trying to put together glibc-2.2.2 for a ppc variant w/o floating
> point, and I'm not getting very far...
> 
> I've used the build-crossgcc.sh script to build the univers and that
> succeeds fine.  I've used the resultant powerpc-linux-* tools to build
> Linux kernels and they boot up fine, at least until they launch
> /bin/init.
>
> Unfortunately I don't have an FPU on my powerpc variant, and I don't
> want to emulate an FPU in the kernel.  So I thought that if I build
> glibc with out floating poing, I could get past the call the
> __setfpucw() and see where it dies next.

 Very good questions indeed...

 Using the '-msoft-float' in the CFLAGS should be the expected method...
When I look at my 'ppc-linux-gnu' targeted gcc-2.95.3, there is that
'nof' subdir in the '/usr/local/lib/gcc-lib/ppc-linux-gnu/2.95.3', so
the version-dependent 'libgcc.a', 'libiberty.a', 'libstdc++.a' etc.
were built for '-msoft-float' too...

 But building glibc-2.2.2 didn't produce the 'nof' subdir...

 I would expect this kind of basic issue mentioned somewhere, but
perhaps it just has been left to the glibc-builder to either build
the default FPU-enabled C-library, or to build a msoft-float-enabled
C-library. The C-libray files take quite a lot space when using
glibc, so producing only one variant for glibc may be somehow sane...

 Newlib will automatically be built for all 'multilib'-variants in
the compiling GCC.

> I notice that there's no '-msoft-float' argument to
> powercp-linux-gcc, so I don't think that --nfp(or --without-fp) works
> very well.
> 
> Does anybody have an idea if/how to buld glibc(and applications)
> without using FPU instructions?

 If the toolset isn't 'generic' but for some specific PowerPC-variant,
using the specific '-mcpu=' etc. options for glibc is then also
possible, just as for 'libgcc.a', 'libiberty.a', 'libstdc++.a' etc.
while producing the extra libraries coming with GCC... Putting all
the needed options as defaults ('MULTILIB_DEFAULTS') for the produced
GCC in the configuration may then be motivated. Only the '-mbig' and
'-mcall-linux' are there (in 'gcc/config/rs6000/linux.h') as default.

 In this case adding the "msoft-float" there would be sane, then the
resulted GCC would produce the 'nof' binaries as default and the
'fpu' binaries only with the '-mhard-float'. The 't-ppc' must anyhow
be edited to be something like:

-------------------------- clip ------------------------------------
# PowerPC support without gas

# Build libgcc.a with different options.  If no gas support, don't build
# explicit little endian or big endian libraries, since it depends on the
# -mbig/-mlittle switches passed to gas.  The -mrelocatable support also needs
# -mrelocatable passed to gas, so don't use it either.

MULTILIB_OPTIONS        = mhard-float/msoft-float
MULTILIB_DIRNAMES       = fpu nof
MULTILIB_EXCEPTIONS     =
MULTILIB_EXTRA_OPTS     = mstrict-align
MULTILIB_MATCHES        = ${MULTILIB_MATCHES_FLOAT}
-------------------------- clip ------------------------------------

 Of course the name for the subdir for the '-mhard-float'-stuff can
be anything one likes, not necessarily the 'fpu'...
 
 So I would expect using the '-msoft-float' being the solution.
I remember a case in this list with the 'mips-linux-gnu' and with a
no-FPU R3000 variant (r3904 ?) and using it was reported to work...

 In the Linux/x86-world the 'x87'-emulator in the kernel handling
the FPU-exceptions seems to be the standard, but what is the case
with PPC/MIPS/m68k/SH etc., do they all have an emulator in the
Linux kernel sources?  I don't remember the emulator-possibility
being mentioned in the MIPS-case, as if there weren't anything
yet for this purpose. The 'arch/mips/kernel/softfp.S' exists though
for MIPS, just as the 'arch/ppc/math-emu' (in the linux-2.4.3 sources)
seems to exist for PPC...

 If the FPU-emulator stuff in the Linux-kernel would be faster than
the '-msoft-float' routines coming with GCC, why we still use the
generic slow 'fp-bit.c/dp-bit.c' in 'libgcc.a'?  Perhaps the 32-bit
CPUs are fast enough, but for the 16-bit CPUs the 'fp-bit/dp-bit' is
very slow, in the H8/300[HS]-case the alternative 'ieeelib.c' package
(donated to the GNU project by Swox AB, Sweden) is two times quicker.
The message from Torbjorn Granlund in egcs-maillist from 15 Jul 1999,
"New IEEE P854 emulation library", claims it to be "3 to 15 times
faster, depending on the operands, host and operation". Also claims
about being smaller and very accurate are mentioned...

 Using the '-msoft-float' or having it as default so enables one to
choose the soft-float-package, trying the default fp-bit/dp-bit coming
with GCC first has its reason, but if more speed is needed, there may
be alternatives...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com



More information about the crossgcc mailing list