Earlier, Paolo 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.
But get out of an ISR quickly. Why sit in an ISR and pre-empt the
regular scheduling when it is not necessary? Some ISRs would, conceptually,
be lower priority than other tasks. By getting out of the ISR as quickly as
possible, it gives the regular priority mechanisms the opportunity to do the
"right thing" for the system. It also gives lower priority interrupts a
crack at the CPU when necessary.
> 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.
To regain the function of the scheduler and priority structure of
the RTOS.
Regards,
Steve
-- [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/
