Hello,
I am very new to RT-Linux and I was following your FP-discussions.
I notice that You want to avoid this functionality in kernel mode.
I am curently in study fase to see if our motion-controller/robotics
package can be ported to RT-Linux.
In general, a robot controller package uses lots and lots of FPU
calculations,
also during initialisation.
I would say that this this kind of applications is a typical RT application.
So, please export the fp save and restore functions in the future.
Regards,
Bert Eding
Nyquist Industrial Control.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: maandag 19 juni 2000 21:25
To: Shel Hoffman
Cc: rtlinux
Subject: Re: [rtl] Floating point in "restricted" code
On Mon, Jun 19, 2000 at 11:29:57AM -0500, Shel Hoffman wrote:
> Under what circumstance is it acceptable to use floating point (FPU) in:
>
> . a interrupt service routine?
nope.
>
> . a RT-FIFO handler that is called when a FIFO has data added to it?
> (e.g., a FIFO handler function specified rtf_create_handler())
no.
>
> Would it make some sense to provide functions that save/restore the
> FPU state so that an RTLinux application developer could use the FPU
> in "restricted" places:
>
> init_module() // FPU can't normally be used
here
> {
> FPP_STATE state;
>
> rtl_save_fpp_state(&state); // Preserve FPU state
>
> // Use floating point here
>
> rtl_restore_fpp_state(&state); // Restore FPU state
> }
>
These functions are in i386/switch.c in the V2 distribution. We have not
exported them to
the general purpose API because it complicates the API and doesn't seem to
add utility.
Here's the line of thought:
1. Saving fp state is _slow_ so you don't need it in an ISR -- there is no
performance loss
in having the ISR hand over work to a thread.
2. Linux kernel code should follow Linux coding conventions so since use of
FP is fobidden in
Linux kernel code, RTL assumes that parts of applications that run under
Linux kernel
are going to not use FP.
These components can ask RT threads or Linux user processes to do FP
computations.
3. Rare workarounds are better than rarely used features. Keeping the API
simple is
critical.
Furthermore: I'm very concerned about FP in alternative architectures. I
would like RTL applications
to run transparently in PPC, MIPS, Alpha, ia32,ia64 and some other upcoming
architectures.
What's going to happen on a ia64 to code that does
save fp // which means wait many cycles until the last of
God knows how many
fp instructions complete and the fp pipeline clears
do a couple of ops
restore fp // which means wait until our ops all complete
so that we
// don't get failure interrupts after we have
switched to
// another thread.
FP is dangerous, scary, frightening, stuff. It is only barely compatible
with RT, and
is really dubious outside of an RT thread.
What do you think?
--
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
