So I understand the point about filesystems and values that always happen
to be a power of two where the compiler can't know that.
However:
> From: torvalds@transmeta.com (Linus Torvalds)
>
> >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.
>
> No, what Linux really says is that you should avoid using "long long"
> (and thus 64-bit values), because on many architectures it is slower.
>
> And I further say that it is usually very easy to avoid it.
>
> But you shouldn't go overboard. Simple "long long" arithmetic is useful
> and easy, even on 32-bit platforms. The kernel does quite a lot of it,
> as all file offsets are basically 64 bits. But by thinking about the
> problem some more, you can often limit it to those simple operations,
> which are fast anyway.
>
> Linus
In my case, it is simple "long long" arithmetic. Shifts, ANDs, ORs,
comparisons, etc. Not even any addition (which should be pretty efficient
with the HW carry bit on X86). I don't know why:
if (a == b)
is inlined, but
switch a {
case b:
}
isn't. It's been pointed out to me that my compiler is old (egcs-2.91.66),
and that may be the problem.
I don't see an advantage to having equality expressions work, but not
switches. There is nothing gained in forcing people to change switch
to if . . . else . . . else . . . . I do see an advantage to not having
division.
I definitely don't see an advantage to forcing synthetic 64 bit types
(the C code for 64 bit file offsets would be painful).
Anyway, I've probably belabored this enough.
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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:24 EST