Messages in this thread | | | Subject | Re: A patch for linux 2.1.127 | Date | Wed, 11 Nov 1998 10:30:50 -0300 | From | Horst von Brand <> |
| |
"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/
| |