This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Linux-asm (was A patch for linux 2.1.127)
- To: Riccardo Facchetti <fizban at tin dot it>
- Subject: Re: Linux-asm (was A patch for linux 2.1.127)
- From: "Richard B. Johnson" <root at chaos dot analogic dot com>
- Date: Sun, 15 Nov 1998 10:50:25 -0500 (EST)
- cc: Ken Raeburn <raeburn at cygnus dot com>, Alex Buell <alex dot buell at tahallah dot demon dot co dot uk>, Linux-Egcs <egcs at cygnus dot com>, Linux Kernel <linux-kernel at vger dot rutgers dot edu>
- Reply-To: root at chaos dot analogic dot com
On Sun, 15 Nov 1998, Riccardo Facchetti wrote:
> On Sat, 14 Nov 1998, Richard B. Johnson wrote:
[SNIPPED]
>
> I have read your paper, the C code and the Assembly code.
>
> No problems understanding C code but Assembly ... I have programmed in 16
> bit Intel Assembly long time ago (but I am not a real Assembly programmer)
> and I am able to follow (sort of) the instruction paths. IMHO the real
> problem is that Assembly need an Assembly programmer to be fully
> understood and mantained while C is much more easy to mantain. Even more,
> an Assembly programmer can mantain C code while a C programmer may not be
> able to mantain asm code. We need a portable and mantainable kernel. Of
> course I can imagine that for some well defined code paths (like fast
> default cases) or counting functions (like checksumming) asm equivalents
> can be the best solution, but there is a limit at this one too:
> fast asm code for i386 != i486 != P5 != P6 so there should be something
> like:
>
> #if defined(i386)
> #include "fasti386.S"
> #elif defined(i486)
> #include "fasti486.S"
> #elif defined(P5)
> #include "fastP5.S"
> #elif defined(P6)
> #include "fastP6.S"
> else
> #include "slow.c"
> #endif
>
This might be a bit extreme, but I get your point!
> and we need someone that is willing to mantain all the different
> implementations in C and in asm and maybe write new ones for P7, P8 etc
> etc. To add more complexity someone should provide Alpha assembly version
> and MIPS and SPARC32 and SPARC64 and motorola etc etc. This is okay for
> something like checksumming but IMHO it will be a real pain if someone
> will come out rewriting e.g. filesystem code in Assembly.
> In this case I say slow C code is better than superfast Assembly code.
>
> OTOH I've enjoyed your paper Assembly Language, good work :)
>
> Ciao,
> Riccardo.
>
Thanks!
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.