On Tue, Jun 20, 2000 at 03:35:59PM +0200, Paolo Mantegazza wrote:
> [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.
I said there was no performance loss, I did not claim any gain.
The point is that there is no real gain from using FP in the ISR.
In the absence of a gain, we have, so far, chosen to keep the API simpler.
> > 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.
There is negligable additional overhead. In fact,
there may actually be a performance gain due to improved cache locality.
-- [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/
