"Stephen D. Cohen" wrote:
> Earlier, Paolo Wrote:
>
> >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.
>
I would like to point out that an interrupt based approach, where the most
important
stuff happens in the ISR is a perfectly viable approach. If a task _must_ get
done
before the next interrupt, then you may as well do it in the ISR. I cannot see
any
advantage in scheduling a thread to clean up after an ISR each time the ISR
runs,
unless that cleanup is not as critical as the interrupt.
In my case i want my controller to run in an ISR, which means that I'm going to
use
fp in my ISR. I really don't see anything wrong with that on the processors i
am
using. If it becomes a problem with future processors, maybe i'll have to
switch
to a DSP or other processor where the fpu is not cobbled on like it is on the
i386.
I think the idea that you shouldn't use fp in kernal mode makes a lot of sense
for
linux and no sense at all for a RTOS.
eric
-- [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/
