This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A patch for linux 2.1.127


On Tue, 10 Nov 1998, Hans Lermen wrote:

> On Mon, 9 Nov 1998, Peter T. Breuer wrote:
> 
> > ...  All
> > studies show that hand-optimizing code is a waste of effort 99.99% of
> > the time, not least because it's unmaintainable.
> 
> Smells a bit like an excuse for lazyness. For sure you have cases where
> the programmer 'knows it better' than the compiler and for sure such
> cases happen during kernel programming. If you can't tell the compiler
> that you are the boss, you get lost.
> 
> And a final point: If you know the kernel was written/tested/proven with
> -O2 and the Makefiles explicitely set -O2, then using -O6 and complaining
> its not running is just ignoring the fact that the 'author' knows it 
> better.

If instead of using occasional 'inline asm' stuff, specific to a compiler,
some critical functions were written in real assembly with an assembler
that produced code exactly as written, using the language that the
processor designer specified, i.e., Intel for Intel, then there could
be improvements in the execution speed. Further, such functions would
be maintainable because the code produced is always what was written,
not some interpretation made by a compiler.

At Analogic, we write software that interacts with machines. Typically
there is an assembly-language wrapper around each piece of hardware
that makes each hardware assembly seem 'perfect'. This wrapper (you
might call it a driver) handles all of the device-specific aspects of
the hardware. Its interface to upper-level code uses 'C' calling
rules so that the upper levels, which deal with the logic necessary
to make the whole machine function, can be (are) written in the
'C' language.

The result is that capable 'real-time' software engineers can optimize
the hardware interface while maintaining the exact functionality
necessary for the 'system' software engineers who design the upper
levels.

For example, a typical CAT Scanner may have hundreds of special
communications and control boards that must function in a time-
critical manner to maintain system-wide pipe-lining to maximize
throughput, while maintaining safety.

One 'board' might be an A/D converter with a 16-channel MUX. The MUX must
be set, a MUX settle time must occur, the converter is told to convert,
one must wait for the conversion to complete, the converted result is
read, it is filtered, then written as a storage variable.

This all happens "auto-magically" within a timer ISR. When upper-level
code wants voltage-X or current-Y, it makes a function-call to get
it and it's simply read from RAM. The converter is never disturbed. 

Further, the necessary "wait for results" shown above never wastes
CPU time because no code ever waits or loops within an ISR. The
required "waits" are just "do-nothing" states maintained within
the ISR where it gets called, but after checking a state-variable,
returns.

Such state-machines and real-time hardware interfaces can be readily
implemented and optimized in assembly. If you try to the same thing
in 'C', you can only use 'pseudo-asm' inside a 'C' wrapper. The
results are specific to a 'C' compiler version which makes maintain-
ability a nightmare.

I have a checksum routine which will checksum a 1500 MTU packet
(or less) in a single pass. It uses a computed jump into the
correct location of a aligned instruction-stream. This is used
in my network communications interface on an Analogic product
that received FAA certification two weeks ago.

There are no secrets on how this is done. Any competent assembly-
language programmer would use this technique as a trade-off of
RAM v.s. speed. The GNU pseudo-assem prevents me from porting this
to Linux.

Cheers,
Dick Johnson
                 ***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.127 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]