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
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
>
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
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
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 think
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 optimised
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
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 working on a
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 the
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
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
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 *=
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
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
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
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
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
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
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
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 Software
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 want to try
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 assembly
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
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 you want to
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 line with this?
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 line with this?
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 preferable to
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 line with this?
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
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
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
>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
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
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 ...
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 ...
Why ^ ?
Jan
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
statements are
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
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
40 matches
Mail list logo
