Messages in this thread | | | Date | Tue, 10 Nov 1998 17:37:02 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: A patch for linux 2.1.127 |
| |
On Tue, 10 Nov 1998, David S. Miller wrote:
> Date: Tue, 10 Nov 1998 10:28:02 -0500 (EST) > From: "Richard B. Johnson" <root@chaos.analogic.com> > > 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. > > ? Your application just would not a good usage of the inline asm > feature of gcc, it was not designed for this sort of task. You can > always choose some other method to achieve what you want. > > Although, I can't think of one situation where I wanted to do > something incredibly crazy and grotesque in raw assembly on Sparc and > couldn't find a way to do it within' a C source file with gcc. For > example I once had a version of the UltraSparc/VIS unrolled memcpy > completely in C using gcc, the arguments could be passed in, it > required 7 versions of the 300 instruction loop, etc. all in one hunk > of code, it had a return value, and it all worked. > > I think the bottom line is that gcc inline asms are more powerful in > one aspect than other schemes, and in another aspect they are less > powerful than such schemes. It was a trade off in design when they > were initially implemented. Perhaps it's showing it's age now, so > lets work on fixing it. > > Later, > David S. Miller > davem@dm.cobaltmicro.com >
I think that assemblers (as opposed to compilers) should be specifically written for a platform. We have at this company collectively, about 100 years of Intel Assembly expertise. To force a foreign language (GNU pseudo-assembly) on long-time assembly-language experts tends to dampen their interest in becoming involved in helping to streamline sections of code that are frequently executed. One of our experts tried to port working video controller code to Linux and gave up in disgust. This was going to sign-on with a Penguin Logo and show startup messages in a box.
Another wanted to rewrite a driver for a 100-base Ethernet card in assembly for Linux. This also failed because there was just too much work to do converting Intel code to GNU 'stuff'.
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.
FYI RISC machines are a real pain to work with in Assembly because of the "always-larger-size-than-you-wanted" memory access. However, there are experts available for those machines also. Linux is, after all, world-wide. It would be nice to have the guy (or gal) who wrote the latest 64-bit compiler, tweak you kernel with the assembly-language sequences that make the machine scream.
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.
- 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/
| |