[EMAIL PROTECTED] wrote:
> 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.
The above is totally wrong as when you get to the thread managing the
interrupt you need the FPUsave/restore anyhow, and so end up in loosing
efficiency as you pay for the thread switch overhead.
> 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?
I do not know anything about ia64 and Alpha, but on PPC and MIPS it is
not much different than with i386.
Once more if you need to use the FPU sooner or later you have to save
restore it and adding a task switch to keep it "elegant" is just adding
overhead.
Ciao, Paolo.
-- [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/
