The netBook's ARM cpu does not have hardware floating point capabilities, so floating point must be emulated. This emulation can be done in a number of ways. These are some enlightening notes about this subject I gleened off the web. The conclusion is that we would be better off with software, rather than kernel, floating point emulation, but it is difficult to assemble such a system. In the answers, "np" is Nicolas Pitre who is one of the experts on ARM floating point emulation. NWFPE is "Netwinder Floating Point Emulation", and "FastFPE" is Peter Teichmann's Fast Floating Point Emulation. The latter is notorious for rather crude results for floating point, and has caused Debian's dpkg/perl to fail, though it is 3-5 times faster than NWFPE. Both NWFPE and FastFPE are options that are selected when the kernel is configured - one must choose one or the other.
[31 January 2004 - np] Scenario 1 (hard-float): The compiler emits opcodes designed to be used with a hardware floating point coprocessor (FPU). The FPU usually has a set of extra registers for its use, and the compiler may as well pass floating point argument to functions through those registers. This is of course the best performing solution when a real hardware FPU is used.
Scenario 2 (soft-float): the compiler converts floating point operations into function calls and a special library is used to provide all functions performing the required operations, all in software with no FPU instructions at all. There is obviously no extra floating point registers available in this case, therefore all FP arguments to functions have to be passed through standard registers or on the stack. This is of course the best performing solution when no hardware FPU is available, given that the library implementing the FP operations is optimally coded.
Now, unfortunately, the default on ARM Linux has traditionally been set to have the compiler use hard-float, even if ARM Linux never ran on any ARM CPU with a real hardware FPU. The CPU is therefore raising the invalid instruction exception each time some FPU opcode is encountered. Then the kernel traps that exception, looks at the given FPU instruction and emulates it in software. But here not only must the kernel perform the FP operation, it must also emulate the whole hardware FPU as well. That's what NWFPE or FastFPE are doing. This is obviously the worst performing arrangement that can be due to the exception trap and emulation overhead.
[31 January 2004 - np] Depends. You can use both at the same time, but not in the same application. The problem has to do with the ABI incompatibility between soft-float and hard-float due to the different floating point argument passing conventions. So, if you decide to switch to using soft-float for some application, you MUST recompile ALL the libraries that application is going to use, including system libraries like the C library. If those libraries are dynamically linked libraries, you then must also recompile all the applications that share those same libraries. And then your application will run correctly only on systems with soft-float environments, unless you link it statically in which case it will run anywhere (even on a kernel with NWFPE configured in -- it will simply not be invoked). That's the main reason why mainstream ARM distributions are still reluctant to switch to soft-float because of the associated compatibility pain.