lkml.org 
[lkml]   [2000]   [Feb]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel bugs found using inspect tool
"Jeffrey B. Siegal" wrote:
>
> Ben Kosse wrote:
> >
> > > nathan.zook@amd.com wrote:
> > > > > if((a == b) | (c == d) | (e < f))
> > > If c, d, e and f are simple variables, then the compiler should be able to
> > > tell that it makes no difference whatsoever whether | or || is used, and
> > > should generate the same (fastest) code for both.
> > Not necessarily true. || has the side effect of allowing you to jump out
> > after the first comparison. | *REQUIRES* you do all comparisons.
> Reread carefully. If "c, d, e, and f are simple variables" then the
> expression in question can not have side effects, and it makes no difference
> whether all the comparisons are performed or not (nor what in order they are
> performed).
And that's my point. The *very use* of || *creates* a side effect that the
compiler is free to use, and in fact used to be commonplace. At one point in
time, people would write the code with the most frequent occurance first and
the compiler would generate a list of cmp/jmp pairs. & vs && also creates
side-effects.

10 | 11 | 00 == 11
10 || 11 || 00 == (expression that evaluates to true)

You would be absolutely correct iff C had a one-bit boolean value, but it
doesn't, so there's always a side effect when you do bitwise operations and
you can always shortcut a logical operation (not a good idea anymore with
superscalar architectures, but it was really useful on a 386).

--
Ben Kosse <bkosse@iname.com>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.421 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site