Messages in this thread | | | Date | Thu, 12 Nov 1998 09:05:04 +0000 | From | Jamie Lokier <> | Subject | Re: A patch for linux 2.1.127 |
| |
On Tue, Nov 10, 1998 at 05:37:02PM -0500, Richard B. Johnson wrote: > Any/all of this stuff could be done with a real assembler. You get > real performance benefits if entire procedures (functions) are written > in the native machine-language. Portability-buffs can use 'C' substitutes > to keep their noses "clean", but those who wanted to save every CPU > cycle for user-mode work, could get their rocks off by making the > fastest (name your machine) kernel in the world.
Richard, what does GNU as not having your preferred syntax standard have to do with the performance benefits of real assembler? And if you hadn't noticed, speed critical bits of the kernel _are_ written in pure assembler (see entry.S et al.).
BTW, there are both Intel-syntax and ATT-syntax pure assembler files in the Linux source tree already. If you want to use Intel syntax, there are enough assemblers around.
Are for the bit about macros, GNU as has had .macro and .rept built in for some time. Plenty of preprocessors were available (including one specially designed for GNU as) before that.
Oh yes, from a speed perspective we use GCC asms because they're faster than putting entire assembler procedures out of line and/or with non-optimal operand allocation.
And one final thing ;-), in my experience the most speed-tweaked assembly language tends not to run to well on newer processor generations. I've written really speedy 386 code in my time, only to find a straightforward C implementation runs much faster on a 486 (though much slower on a 386). So there.
My philosophy: if the code isn't quite speedy enough, fix the compiler.
-- Jamie
- 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/
| |