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/
