Re: Float numbers in module programming

[Phillip Susi <psusi@cfl.rr.com>]

linux-os (Dick Johnson) wrote:
> No. Any file I/O, or anything that takes time sleeps and gives up
> the CPU, ultimately calling schedule(). That means that anybody
> can have its coprocessor state dorked. This has been discussed many

The FPU state is saved across normal thread switches if either the new 
or old thread uses the fpu, so this should be safe.  Unless this does 
not apply to kernel threads?

> times. Also, floating-point is never required for anything!!! It's
> just a convenience for people who like to write code using 10 fingers.
> It has real problems when trying to exactly represent real numbers.
> For instance __all__ real numbers, except for transcendentals, can
> be represented as a ratio of two integers. For instance, you can't
> represent 1/3 exactly as a decimal. It is, however exactly the ratio
> of 1 and 3, two integers. Given this, I'm sure you can find a way
> to perform high-precision mathematics within the kernel without
> using the coprocessor. Usually, it's just a little thought that
> is required. Somebody needs 8 bits to feed into a volume-control
> register, but the value needs to be log-scale. Trivial, even if
> you don't want to use a table.

Agreed, adjusting your thinking a bit to stick to integer math is 
usually preferred for efficiency reasons.

> If you divulge the mathematics you need calculated, I'll bet you
> will get many answers from responders to the linux-kernel list.
> However, if you expect to use the coprocessor as part of an image
> processing routine and your driver was designed to use that
> coprocessor, then you need a private coprocessor or you need
> a user-space 'driver' that probably communicates using shared-
> memory, this not involving kernel code at all.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/