lkml.org 
[lkml]   [1998]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: A patch for linux 2.1.127
Date
From
"Richard B. Johnson" <root@chaos.analogic.com> said:

[...]

> 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.

The problem with this is that either every complete function that uses a
tiny piece of assembler has to be written in assembler in full (just take a
look at the kernel, I'd wager this is at least 50% of the whole kernel;
there goes portability), or you pay the C function call overhead for each
such (mostly one-instruction) assembler streches. Take your pick. gcc gives
you the _option_ of doing inline asms, Linus has choosen to use
them. Wisely, IMHO.

> 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.

Now put your card into an Alpha, or a SPARC. Or a handy PPC... you'll have
to rewrite/recheck/retest everything. Plus it is written in assembly... no,
thanks.

[...]

> 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.

Just curious: Exactly _how_ does it prevent doing this? AFAIU, what you are
doing is something like:


; Compute some hairy function involving 'there' into %R
jmp %R
there:
; ...

You can align instructions in asm() via .align, and you can define (pseudo)
labels that are good for the current assembler strech (that you then can
use for the "there" above); and you can also define real labels, you just
have to make sure they don't repeat (ANSI stringifying and string pasting
might come handy there). I fail to see the problems you mention... care to
explain more fully? (Note: I'm no assembler expert; and perhaps we shold
take this offline?)
--
Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.109 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site