Hi
i wonder if it is available to use float numbers in a module programming.
Because, when I'm look for the param_get functions, i find them only
for integers (long, short, and others) but none for the float numbers.
Thanks for yours answer.
bye
On Wed, 29 Mar 2006, beware wrote:
> Hi
>
> i wonder if it is available to use float numbers in a module programming.
> Because, when I'm look for the param_get functions, i find them only
> for integers (long, short, and others) but none for the float numbers.
>
> Thanks for yours answer.
>
> bye
> -
This used to be a FAQ. The floating-point coprocessor in ix86
machines is a shared resource. There is only one. Therefore,
the state of the floating-point unit needs to be saved and
restored across all context switches. Because this is expensive
in terms of CPU time used, it is not saved and restored during
system calls. This means that if you use the coprocessor in
the kernel, you may screw up somebody's mathematics, causing
the airplane to go off course and crash into the Getchey-
Goomy swamp. If this is okay, then fine. Otherwise, don't
use the coprocessor inside kernel code.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
beware wrote:
>Hi
>
>i wonder if it is available to use float numbers in a module programming.
>Because, when I'm look for the param_get functions, i find them only
>for integers (long, short, and others) but none for the float numbers.
>
>Thanks for yours answer.
>
>
The short answer is no, don't bother.
If you touch the floating point registers in kernel code, then
you mess them up for any user program that use floating point.
It can be done, but then you have to take all sorts of precations
saving the registers before using them, and restoring them
when finished. And you must prevent context switching
while you have them!
If you need a few computations, try to do it with fixed point
instead if at all possible. Or emulate floating point,
or have a userspace helper app to do it.
It all depends on what you think you need floats for.
Helge Hafting
>
>This used to be a FAQ. The floating-point coprocessor in ix86
>machines is a shared resource. There is only one. Therefore,
>the state of the floating-point unit needs to be saved and
>restored across all context switches. Because this is expensive
>in terms of CPU time used, it is not saved and restored during
>system calls. This means that if you use the coprocessor in
>the kernel, you may screw up somebody's mathematics,
"somebody" is the current process, is not it? What if used in kthreads?
Jan Engelhardt
--
> If you need a few computations, try to do it with fixed point
> instead if at all possible. Or emulate floating point,
> or have a userspace helper app to do it.
Or try to transform it into integer math, if the precision loss is
acceptable and no integer overflow can occur.
Jan Engelhardt
--
On Thu, 30 Mar 2006, Jan Engelhardt wrote:
>>
>> This used to be a FAQ. The floating-point coprocessor in ix86
>> machines is a shared resource. There is only one. Therefore,
>> the state of the floating-point unit needs to be saved and
>> restored across all context switches. Because this is expensive
>> in terms of CPU time used, it is not saved and restored during
>> system calls. This means that if you use the coprocessor in
>> the kernel, you may screw up somebody's mathematics,
>
> "somebody" is the current process, is not it? What if used in kthreads?
>
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
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.
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.
>
> Jan Engelhardt
> --
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
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.
>
>
On Thu, Mar 30, 2006 at 08:09:14AM -0500, linux-os (Dick Johnson) wrote:
> For instance __all__ real numbers, except for transcendentals, can
> be represented as a ratio of two integers.
Dear wrongbot, "transcendentals" doesn't mean what you think it means.
> > For instance __all__ real numbers, except for transcendentals, can
> > be represented as a ratio of two integers.
> Dear wrongbot, "transcendentals" doesn't mean what you think it means.
Yes, I got a real kick out of his statement, because he has risen
above his usual simple level of wrongness and come up with something
doubly wrong. First, there are certainly real numbers such as the
square root of 2, which are neither trancendental nor the ratio of
integers. And anyway, there are infinitely more transcendental
numbers than rational numbers, so only an infinitesimally small
fraction of real numbers can be represented as a ratio of integers.
- R.
On Thu, 30 Mar 2006 08:09:14 EST, "linux-os (Dick Johnson)" said:
> 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.
That's a "rational" number (or alternately, an algebraic number of order 1.
Irrational numbers result from algebraic expressions but aren't representable
as a ratio (for instance, the square root of 2, or the number phi - both of
these are algebraic numbers of order 2). Trancendentals are numbers which
can't result from algebraic expressions with whole number coefficients (for
instance, pi and e).
All transcendentals are irrational, but not all irrationals are transcendental.
http://mathworld.wolfram.com/AlgebraicNumber.html
http://mathworld.wolfram.com/IrrationalNumber.html
http://mathworld.wolfram.com/TranscendentalNumber.html
http://mathworld.wolfram.com/GoldenRatio.html
On 08:09, linux-os (Dick Johnson) wrote:
> For instance __all__ real numbers, except for transcendentals, can
> be represented as a ratio of two integers.
Nope. It was known already to Euklid (300 before christ) that the real
number sqrt(2) can _not_ be represented as ratio of two integers. Of
course, sqrt(2) is not transcendental because it is a zero of x^2 -
2, a polynomial with integer coefficients.
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe
On Thu, 30 Mar 2006, Andre Noll wrote:
> On 08:09, linux-os (Dick Johnson) wrote:
>
>> For instance __all__ real numbers, except for transcendentals, can
>> be represented as a ratio of two integers.
>
> Nope. It was known already to Euklid (300 before christ) that the real
> number sqrt(2) can _not_ be represented as ratio of two integers. Of
> course, sqrt(2) is not transcendental because it is a zero of x^2 -
> 2, a polynomial with integer coefficients.
>
> Andre
> --
Yeah. The correct word was irrational, which is its definition. The
point was that one can do a lot of very accurate work on real numbers
without using the FP unit and the decimal system.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Thu, Mar 30, 2006 at 01:46:20PM -0500, linux-os (Dick Johnson) wrote:
> Yeah. The correct word was irrational, which is its definition. The
> point was that one can do a lot of very accurate work on real numbers
> without using the FP unit and the decimal system.
As long as you don't use sin/cos (oops, no 3D, no polar coordinates,
no FFT), sqrt (oops no lenghts), pi (oops no non-polygonal surfaces)
or ln/exp (oops, a lot of things are gone there).
Working with rationals is not that realistic nowadays except in things
like mathematica, maple and friends. Fixed-point though is still very
realistics, it's just a different precision/scale tradeoff than fp,
and one you control.
OG.
Olivier Galibert wrote:
> On Thu, Mar 30, 2006 at 01:46:20PM -0500, linux-os (Dick Johnson) wrote:
>> Yeah. The correct word was irrational, which is its definition. The
>> point was that one can do a lot of very accurate work on real numbers
>> without using the FP unit and the decimal system.
>
> As long as you don't use sin/cos (oops, no 3D, no polar coordinates,
> no FFT), sqrt (oops no lenghts), pi (oops no non-polygonal surfaces)
> or ln/exp (oops, a lot of things are gone there).
>
> Working with rationals is not that realistic nowadays except in things
> like mathematica, maple and friends. Fixed-point though is still very
> realistics, it's just a different precision/scale tradeoff than fp,
> and one you control.
Fixed point is a special case of rational i.e. with a fixed denominator.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce