Messages in this thread |  | | Date | Tue, 19 Sep 2000 22:00:14 -0700 (PDT) | From | (Jeremy Higdon) | Subject | Re: __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/
|  |