[EMAIL PROTECTED] wrote:
> Paolo: you do know that the PowerPC port of Linux was partly written
> by Cort Dougan during his Masters project at New Mexico Tech?
> I was the supervisor for that project.
> Would you like to be credited for the use of indirect pointers in
> the PowerPC port?
Not at all, I said "natively" to mean that it is there without any need
of further intervention, almost. Do no provoke too far.
> If we ignore wording and consider whether there is
> any fundamental virtue in the indirect pointer method, we have a real
> difference. To my way of thinking, the implementation of the RTLinux
> intercept of interrupt control should be purely a question of balancing
> programmer time and hardware efficiency. We would like to do an optimized
> version of RTL for the many embedded 486/low-power Pentium machines and
> here the indirect pointer becomes a performance problem -- partially
> because of the smaller caches. The operation:
> fetch instruction
> call emulation
> can be noticeably faster than
> fetch instruction
> do pointer arithimetic
> fetch indirect pointer
> call what was pointed to
>
> In a modern OOO processors, the caches and pipelines
> are so deep that the difference is minimal. But that's not necessarily
> the case for Elan4xx or a strongarm or a mips core embedded in an ASIC or
> a MPC860. And it is not necessarily even always the case for high
> end processors.
> So, for me, indirect function pointer/static pointer is merely a
> difference in how the abstraction is implemented -- the user sees no difference
> other than possibly performance. And as someone whose instincts are to
> both guard every cycle and to allow for greatest flexibility in
> implementation,insisting that we always use the indirect function pointer
> seems a clearly wrong decision -- a decision to impose a low level
> non-optimal implementation as a design fundamental.
The above is agreed totally. For me the two solutions are conceptually
the same. In fact the practicall loss of performance on lesser machine
can be proved to be marginal on the base of experience. To be precise I
have such an experience only on 486 and low end Pentiums, all going out
of market also on PC104. 486 correspending Cyrix and AMD based PC-104
are already a lot better. See the comment on cli/sti/pushfl/popfl
further on. \
In any case you must admit that it was not so when you rejected my
proposal on March 1999. In any case if any marginal performance loss
exists between the two solutions it is just on Linux, real time is not
suffering in any case.
> BTW: Paolo and anyone else out there. There has for a long time
> been an invitation to send complaints if you feel slighted in the CREDITS
> file that is part of the RTLinux distribution. Send
> me a list of what you believe
> your contributions to be and, unless it is totally absurd, I'd be happy
> to put it in the distribution.
I do not ask for any credit, just admit it was not saw 1.5 years ago.
After all we are discussing things that a lot of Computer Science
graduates can do quite easily for free, just if it payed a meaningfull
grade increase for their thesis.
My proposal is the same as for March 1999( see:
Subject: [rtl] Real Time Application Interfaces/
From: Paolo Mantegazza <[EMAIL PROTECTED]>
Date: Tue, 09 Mar 1999 11:34:44 +0000) in the RTL mailing list archives.
> For those who want to know. Linus notes that in the x86,
> cli/sti/pushfl/popfl are 8 bit instructions. Replacing these
> with a "move mem,reg, call reg" inflates code and may cause cache
> misses -- cli becomes a 10 byte or so operation instead of 1. The core Linux
> developers are obsessive about cache lines, for good reason, and
> we do see a minor slowdown in Linux on some x86s when any form
> of RTLinux indirection is added. This was not always the case, but
> base Linux IRQ handling has improved.
The problem is clearly not one of bytes but of cycles of excution. The
outcome depends on how many bytes of code the above are protecting. In
any case RTL and RTAI are using them as such so, I repeat, it is just a
problem of having Linux pay a marginal cost, not the hard real time
applications running unde RTL/RTAI.
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/
