On Tue, Jun 20, 2000 at 01:14:41PM -0400, eric keller wrote:
> 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.
The advantage is that it encourages keeping the ISR absolutely simple.
And, in my experience, complex ISRs are trouble.
Well, complex code is trouble -- ok, any code is trouble.
>
> 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.
I agree. But we currently only make it easy to use in threads on the
following line of reasoning:
1. it is simple to make a thread run from an ISR
Therefore a ISR can easily pass FP requests to threads
2. ISRs seem to work better over the long run if they are kept really
simple.
3. Anyone who hates this idea can take code out of the arch specific
scheduling code and make the ISR use FP directly.
It follows that we keep the API simpler, encourage what we consider to be
good programming practice, and save ourselves work all at the same
time.
victor
-- [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/
