Messages in this thread Patch in this message |  | | | From | "Adam J. Richter" <> | | Date | Sat, 6 Jun 1998 23:12:43 -0700 | | Subject | Re: Compatible with i386/UP but optimised for i686/SMP |
| |
Alan Cox wrote: >Actually the FPU module isnt ideal. For glibc at least I seem to get >insmod using FPU which might be a bit fatal. Better would be to create >an __fpucode __fpudata linked before the __initcode/__initdata and discard >more if an FPU is not needed - have you look at that Adam btw ?
Using the patch to glibc-2.0.7pre3 attached below, I can now boot a non-FPU kernel running on a non-FPU machine that does not gratuitously load the FPU module for programs that do not appear to use floating point.
The reason that all glibc2 and Linux libc5 programs were executing a floating point instructions was because during initialization they want to set the floating point control word to a known value. Well, in Linux ,the kernel already does this when it traps the first floating point instruction that a process executes. I have a patch that avoids these floating point instructions when the meaningful bits of glibc's desired initial FP control word are the same as those of the kernel's default initial FP control word.
Be warned that Ulrich Drepper (the glibc mainainter) is championing a slightly different approach. My approach is to declare that an initial floating point control word value of 0x37f on an x86 is part of the semantics of the "_personality(PER_LINUX)" system call that all glibc programs execute at initialization. If the default initial floating point control word for a process changes at some point in the future, PER_LINUX must be definied to a new number, so that old programs that execute _personality(0) (0 is the current value of PER_LINUX) will continue to get an initial floating point control word of 0x37f.
Ulrich, instead, advocates passing a new word of auxilliary data to all ELF executables that contains the value the kernel intends to use as the initial floating point control word. Programs wishing to default to a different FPU control word would then execute the floating point instructions to set the initial floating point control word at initialization.
The advantages of my approach are:
1. If the FPU control word ever changes, old non-FPU programs will remain non-FPU programs. For example, ibcs2 programs already use a different initial FPU control word, so non-FPU ibcs2 programs would be impossible under Ulrich's scheme unless you want to make all current Linux executables FPU programs. 2. My approach is not ELF specific 3. As simple and fast as Ulrich's approach is, mine is simpler and faster.
Anyhow, I have attached the patch below. A similar patch should be possible for Linux libc5. Since this is a patch to the shared C library, all you have to do is rebuild and reinstall glibc to have all of your non-floating-point programs stop executing this unnecessary FPU instructions.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205 adam@yggdrasil.com \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." ------------------------------ CUT HERE ------------------------------ --- /tmp/glibc-2.0.7/sysdeps/unix/sysv/linux/init-first.c Sun Feb 9 19:19:42 1997 +++ glibc/sysdeps/unix/sysv/linux/init-first.c Thu May 28 15:25:34 1998 @@ -45,6 +45,9 @@ /* We often need the PID. Cache this value. */ pid_t __libc_pid; +#ifndef _KERNEL_FPU_DEFAULT +# define _KERNEL_FPU_DEFAULT _FPU_DEFAULT +#endif static void init (int argc, char **argv, char **envp) @@ -62,8 +65,11 @@ the executable format. */ __personality (PER_LINUX); - /* Set the FPU control word to the proper default value. */ - __setfpucw (__fpu_control); + if ((__fpu_control & ~_FPU_RESERVED) != + (_KERNEL_FPU_DEFAULT & ~_FPU_RESERVED)) { + /* Set the FPU control word to the proper default value. */ + __setfpucw (__fpu_control); + } } /* Save the command-line arguments. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
|  |