On Wed, 27 Jul 2005 15:58:48 -0400, "linux-os \(Dick Johnson\)" <[EMAIL
PROTECTED]> wrote:
>
>I think the XOR thread was started by somebody as a ruse or
>a joke. XOR will always destroy the value of an operand.
You missed the part where somebody checked assembler output and
found compiler optim
On Wed, 27 Jul 2005, Clayton Weaver wrote:
> Is not xor (^) typically compiled to a
> one cycle instruction regardless of
> requested optimization level? (May not
> always have been the case on every
> target architecture for != equality
> tests.)
> Clayton Weaver
> cgweav at fastmail dot fm
>
I
Is not xor (^) typically compiled to a
one cycle instruction regardless of
requested optimization level? (May not
always have been the case on every
target architecture for != equality
tests.)
Clayton Weaver
cgweav at fastmail dot fm
PS:
Anyone know where I can get
a waterproof, battery powered gp
On Tue, 2005-07-26 at 08:07 +0200, Jan Engelhardt wrote:
[...]
> To answer for x *= 2 vs x <<= 1:
and x += x
> Use * when you would logically want to do a multiplication,
> << if you're working on a bitfield. It's just for keeping the code clean
> enough so that others may understand it.
>
> In
>> > Where do we draw the line with this? Is x *= 2 preferable to x <<= 2 as
>> > well?
>>
>> Depends if you want to multiply by 2 or 4 :-)
>
>I guess I just answered my own question ;-)
To answer for x *= 2 vs x <<= 1:
Use * when you would logically want to do a multiplication,
<< if you're wo
Lee Revell wrote:
On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
Doesn't matter. The cycles saved for old compilers is not rational to
have obfuscated code.
Where do we draw the line with this? Is x *= 2 preferable to x <<= 2 as
well?
In addition to the obvious error, let's not
Lee Revell wrote:
On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
Doesn't matter. The cycles saved for old compilers is not rational to
have obfuscated code.
Where do we draw the line with this? Is x *= 2 preferable to x <<= 2 as
well?
I guess this depends on what you logically wa
On Mon, 2005-07-25 at 12:16 -0700, Philippe Troin wrote:
> Lee Revell <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
> > > Doesn't matter. The cycles saved for old compilers is not rational to
> > > have obfuscated code.
> >
> > Where do we draw the li
On Mon, 2005-07-25 at 20:23 +0100, Paulo Marques wrote:
> Lee Revell wrote:
> > On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
> >
> >>Doesn't matter. The cycles saved for old compilers is not rational to
> >>have obfuscated code.
> >
> > Where do we draw the line with this? Is x *= 2
On Mon, 2005-07-25 at 12:16 -0700, Philippe Troin wrote:
> Lee Revell <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
> > > Doesn't matter. The cycles saved for old compilers is not rational to
> > > have obfuscated code.
> >
> > Where do we draw the li
On Mon, 2005-07-25 at 12:16 -0700, Philippe Troin wrote:
> Lee Revell <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
> > > Doesn't matter. The cycles saved for old compilers is not rational to
> > > have obfuscated code.
> >
> > Where do we draw the li
Lee Revell <[EMAIL PROTECTED]> writes:
> On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
> > Doesn't matter. The cycles saved for old compilers is not rational to
> > have obfuscated code.
>
> Where do we draw the line with this? Is x *= 2 preferable to x <<= 2 as
> well?
Depends if y
On Mon, 2005-07-25 at 13:55 -0400, Steven Rostedt wrote:
> Doesn't matter. The cycles saved for old compilers is not rational to
> have obfuscated code.
Where do we draw the line with this? Is x *= 2 preferable to x <<= 2 as
well?
Lee
-
To unsubscribe from this list: send the line "unsubscribe
Sorry for the double post. I added [PATCH] and changed the subject, and added
Linus.
On Mon, 2005-07-25 at 10:57 +0200, Bernd Petrovitsch wrote:
> On Sun, 2005-07-24 at 18:15 -0400, Puneet Vyas wrote:
> [...]
> > I just compiled two identical program , one with "!=" and other with
> > "^". The a
On Mon, 2005-07-25 at 10:57 +0200, Bernd Petrovitsch wrote:
> On Sun, 2005-07-24 at 18:15 -0400, Puneet Vyas wrote:
> [...]
> > I just compiled two identical program , one with "!=" and other with
> > "^". The assembly output is identical.
>
> Hmm, which compiler and which version?
> You might wa
On Sun, 2005-07-24 at 18:15 -0400, Puneet Vyas wrote:
[...]
> I just compiled two identical program , one with "!=" and other with
> "^". The assembly output is identical.
Hmm, which compiler and which version?
You might want to try much older and other compilers.
Bernd
--
Firmix Softwa
Jan Engelhardt wrote:
To confuse you, coders with assembly or hardware background throw in
I doubt that. I'm good enough assembly to see this :)
equivalent bit operations to succinctly describe their visualisation
of solution space... Perhaps the writer _wanted_ you to pause and
th
>To confuse you, coders with assembly or hardware background throw in
I doubt that. I'm good enough assembly to see this :)
>equivalent bit operations to succinctly describe their visualisation
>of solution space... Perhaps the writer _wanted_ you to pause and
>think? Maybe the compiler prod
On Sun, 24 Jul 2005 18:40:25 +0200 (MEST), Jan Engelhardt <[EMAIL PROTECTED]>
wrote:
>
>I have seen this in kernel/signal.c:check_kill_permission()
>
>&& (current->euid ^ t->suid) && (current->euid ^ t->uid)
>
>If current->euid and t->suid are the same, the xor returns 0, so these
>st
Hi list,
I have seen this in kernel/signal.c:check_kill_permission()
&& (current->euid ^ t->suid) && (current->euid ^ t->uid)
If current->euid and t->suid are the same, the xor returns 0, so these
statements are effectively the same as a !=
current->euid != t->suid ...
Wh
20 matches
Mail list logo
