lkml.org 
[lkml]   [2000]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectnon-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
    All,

    Alright, I've been lurking long enough on this thread. What say we
    consider the option of building the kernel with a compiler other than
    gcc? This would imply a slightly different structure to the makefiles
    and code.

    There are two immediate reasons I can come up with for this:

    1. There are architectures where some other compiler may do better
    optimizations than gcc. I will cite some examples here, no need to argue
    out the point unless you disagree with the POSSIBILITY that this may be
    true on at least one architecture. Anyway, possibilities include
    Compaq's compiler on alpha, HP's compiler on hppa, Intel's compiler (or
    rather plugins to another vendors compiler) on ia64, Metrowerk's
    compiler on PPC, etc.

    2. There are architectures where gcc is not yet available, but vendor C
    compilers are.

    I suggest that we avoid gcc extensions as much as possible, barring
    performance hits. When there is an ANSI way of doing things we should
    choose that route. Where there is not, then isolate the gcc way such
    that compiler vendors can either:

    1. implement the gcc way and conditional compile that code.

    2. implement some other way and easily add that conditional code.

    I've been looking into this here at Lineo for some of these vendors.
    Here is a brief list of things I've come across:

    1. C++ style comments

    Occurs in over 4000 lines of source and header files. :-( Should be
    converted to ansi c comments? We will probably want to just skirt this
    issue for now as the next rev of ANSI C is likely to include ANSI C++
    style comments.

    2. Inline assembly statements

    mostly in arch/ tree. Frequently used in macros as well. Much of this
    will incur performance penalties if moved to external assembly files.
    Some would require moving supported C code over as well. Hence many of
    these will probably translate into conditional compilation based on the
    compiler to avoid and performance hit for the mainstream case.

    3. Declaring attributes of functions

    The __attribute__ options: noreturn, const, format, section,
    constructor, destructor, unused, and weak. weak and section are needed.
    The rest can be ignored? These might want to be converted to #defines
    such that alternative compilers can implement them differently.

    4. Specifying attributes of variables

    The __attribute__ options: aligned, packed, section and weak. As above
    these will likely be #defines to handle different compiler syntax.

    5. Conditionals with omitted operands

    The missing operands should just be added into the mainstream source.

    6. Referring to a type with typeof

    no recommendation yet.

    7. Macros with variable numbers of arguments

    no recommendation yet.

    8. Inquiring on alignment of types or variables (__alignof__)

    no recommendation yet.

    Well, I got a bit more long winded than I planned, but there it is.
    Thoughts?

    "H. Peter Anvin" wrote:
    >
    > Followup to: <200011020011.QAA20585@pizda.ninka.net>
    > By author: "David S. Miller" <davem@redhat.com>
    > In newsgroup: linux.dev.kernel
    > >
    > > We already know we are a bunch of pinheads wrt. the userland compiler
    > > issue, full stop. It need not be restated several hundred more times.
    > > Believe me, after such a large fiasco, we have listened :-)
    > >
    > > But, on the other hand, to say that "kgcc" comceptually is something
    > > only Red Hat has ever done is a factual error, that is all I am trying
    > > to state, nothing more.
    > >
    >
    > I think at least supporting a "kgcc" compiler makes sense,
    > conceptually (although it probably should have been called "kcc", but
    > it's too late now.)
    >
    > The kernel uses a lot of gcc extensions, and history shows that these
    > extensions aren't as stable as the compiler system as a whole.
    >
    > -hpa
    --
    Tim Riker - http://rikers.org/ - short SIGs! <g>
    All I need to know I could have learned in Kindergarten
    ... if I'd just been paying attention.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

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