[lkml]   [2000]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: __ucmpdi2
    >  - Linux developers often do horribly stupid things, and use 64-bit
    > division etc instead of using a simple shift. Again, not linking
    > against libgcc finds those things early rather than late, because the
    > horribly stupid things end up requireing libgcc support.

    I would have thought that the compiler would generate a shift if it
    could (I'm presuming you're talking about shifting by a constant
    here -- or are you talking about code that always shifts by a
    computed power of two).

    > In the case of __ucmpdi2, it appears to be a combination of kernel and
    > compiler stupidity - there's no reason why __ucmpdi2 should not be done
    > inline by the compiler, but at the same time there is probably also
    > little reason to use a slow "long long" comparison in the kernel.

    Little reason or no reason? If there is a reason, and it doesn't
    work, then the coder is forced to rewrite using 32 bit variables,
    synthesizing the result. Then you have belabored C code as well
    as belabored machine code, and it doesn't automatically clean up
    when you move to a 64 bit machine.

    > So again, not linking libgcc showed a problem. Good for us.

    (Un)fortunately, it was only the switch that caused the problem.
    Other expressions using 64 bit variables work fine. So you can
    if ((uint64_t) x == (uint64_t) y)

    all you want.

    So what we've said is: 64 bit is okay, except in a switch statement,
    or other random expressions that might cause gcc to embed a call to
    similar libgcc function. If you run into that, figure out what
    caused it (presumably by disassembling and comparing with source),
    and then use a different construction (that may be more obtuse).
    If you can, change to 32 bits. And you may be forced to.

    > But yes, it is often much more convenient to not know about problems
    > like this. And some people don't think they are a big deal. I'd rather
    > nip them in the bud early than be "convenient", myself.
    > Linus

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.021 / U:2.124 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site