lkml.org 
[lkml]   [2000]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    use:
    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

    jeremy
    -
    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:38    [W:0.023 / U:151.588 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site