On Fri, Jun 30, 2000 at 10:10:16AM +0200, Paolo Mantegazza wrote:
> Jeff Studer wrote:
> >
> > I think the point you missed, Karim, was that a function pointer is no big
> > deal. The fact someone makes out like it was, is sort of silly.
>
> So I was a silly guy from the very beginning, the good guys became such
> afterwards only afterwards. BTW: then all PPC Linux is a silly code as
> most basic mach dep functions, including sti/cli equivalents, are
> pointers natively.
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?
> Clearly I do not think so, in fact all Linux versions should be
> structured that way. Note that I'm not supporting that specific
> implementation but just the idea behind it, i.e. a complete HAL, which
> despite someone's claim is not present yet in i386 Linux.
>From my perspective, i386 Linux provides a clear irq control
hardware abstraction layer. If it did not RTLinux would be impossible
and Linux portability would be a joke.
The hardware layer consists of the operations {cli,sti, enable_irq,disable_irq
save_flags, restore_flags} and all the irq_save/spinlock operations for
SMP. This layer was present (except for the SMP parts) in very
early versions of Linux. From Paolo's perspective, as I understand it,
when the layer is implemented in the form of macros (as in the x86 native
Linux) it is not a hardware abstraction layer, however, when it is implemented
via function pointers (as in the PowerPC native Linux) it does implement
a hardware abstraction layer.
I don't share this perspective and I think
it violates the standard usage of the term "abstraction" in this
part of computer science. IBM implements an "abstraction layer" in the
390s in the microcode. This is an abstraction layer in my book, and
would remain so if it were implemented in the hardware state machine
or in a Virtual Basic function.
Suppose we write the C code;
x = funcname;
x();
and "cc rt_nobel_prize_winning_code.c" gets us
move, $funcname,reg
call *reg
and "cc -O2 rt_nobel_prize_winning_code.c" gets us peephole optimization
and the result:
call funcname
Is the result of the first compile "hardware abstraction", while the
second is not?
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.
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.
For example:
Paolo Mantegazza should be credited for:
1. First use of 8253 timers in periodic mode in RTLinux.
2. Major input in getting floating point working on RTLinux.
3. First use of indirect pointers to implement the intercept
of cli/sti in an RTLinux type system.
4. --- 10^300
...
whatever. Just send me a note. Try to keep it under 1 megabyte.
> Torvalds likely does not like it and is accepting such a solution for
> other archs just because that helps in promoting his creature and, being
> almost god but not completly, cannot do everything by himself.
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.
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.
-- [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/
