Float numbers in module programming

Float numbers in module programming

[beware]

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

Re: Float numbers in module programming

[linux-os (Dick Johnson)]

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.
_
\x1a\x04

****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Float numbers in module programming

[Jan Engelhardt]

>
>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
-- 

Re: Float numbers in module programming

[linux-os (Dick Johnson)]

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.
_
\x1a\x04

****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Float numbers in module programming

[Phillip Susi]

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.
> 
> 

Re: Float numbers in module programming

[Helge Hafting]

Phillip Susi wrote:

> 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?

Wrong.  The FPU state is saved if context is switched from one
userspace thread to another.  I don't know about kernel threads, but
be aware that lots of the kernel code is not executed in a kernel thread
context, so thread switching details doesn't matter at all.

Driver code is often executed in interrupt context.  Any thread can
be interrupted while doing floating-point work, and the floating
point registers are _not_ saved when an interrupt comes in. This
goes for all drivers - disk drivers, usb, serial, audio, video, ...
Drivers may then call all sorts of kernel functions, so the
cpu may have "hot" FPU registers when executing filesystem and VM
code and almost anything else too.

To further complicate this:  Your driver can save the FPU registers,
but it too may get interrupted. Possibly even by another instance of
itself, if the user have several devices.

>> If you divulge the mathematics you need calculated, I'll bet you
>> will get many answers from responders to the linux-kernel list.
>
Excellent advice.  This problem has been solved so many times already .

Helge Hafting

Re: Float numbers in module programming

[Jan Engelhardt]

>
> To further complicate this:  Your driver can save the FPU registers,
> but it too may get interrupted. Possibly even by another instance of
> itself, if the user have several devices.
>
In which case the drive author probably already uses interrupt disabling.


Jan Engelhardt
-- 

Re: Float numbers in module programming

[Al Viro]

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.

Re: Float numbers in module programming

[Roland Dreier]

 > > 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.

Re: Float numbers in module programming

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 228 bytes --]

Re: Float numbers in module programming

[Andre Noll]

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

Re: Float numbers in module programming

[linux-os (Dick Johnson)]

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.
_
\x1a\x04

****************************************************************
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 DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Float numbers in module programming

[Olivier Galibert]

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.

Re: Float numbers in module programming

[Peter Williams]

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                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: Float numbers in module programming

[Helge Hafting]

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

Re: Float numbers in module programming

[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
--