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    [from the cache]
©2003-2011 Jasper Spaans