OSDev.org

Yeah initialising the FPU fixed it. I'm guessing some machines already pre-initialise the FPU or something.

And what do you guys mean by overhead? I don't exactly understand what you guys mean by "entering and exiting", are you referring to multitasking? Are floats really this expensive?

Are you referring to the overhead associated with dumping float registers?

YDeeps1 wrote:Yeah initialising the FPU fixed it. I'm guessing some machines already pre-initialise the FPU or something.

And what do you guys mean by overhead? I don't exactly understand what you guys mean by "entering and exiting", are you referring to multitasking? Are floats really this expensive?

Are you referring to the overhead associated with dumping float registers?

Other than saving state, there is no real need for a kernel to be manipulating floats.

Timers can be specified in microseconds, and manipulated using integer arithmetic. If microseconds doesn't provide the resolution you want, you can use nano-seconds, and use 64-bit integers to handle overflow. If nano-second resolution is not good enough for your timers, you may have your expectations set to high.

The FP state is rather large. WIth MMX, you need a 512 byte buffer, which you'll have to save and restore on each entry/exit from the kernel. Think for each timer interrupt, HDD interrupt, and ethernet controller interrupt. The could be thousands of these per second, so you'll shifting megabytes of FPU state each second in such a circumstance. It all adds up.

If you know you're not doing any FP in the kernel, you can skip all of this and save just the integer GPR.

YDeeps1 wrote:I don't exactly understand what you guys mean by "entering and exiting", are you referring to multitasking?

I'm referring to things like interrupts and system calls, which do not necessarily involve a task switch. If your kernel uses extended registers, every interrupt must save and restore the extended registers, even when returning to the same task.

YDeeps1 wrote:Are floats really this expensive?

Based on these measurements I'd estimate at least 200 cycles of overhead on every interrupt and system call. Do you save more than 200 cycles per interrupt by using floating-point math instead of integer math?