This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |