about the keyword "register"

[Dave win]

howdy....
plz take a look at the following codes, and tell me the reason.

1 #define swap(a,b) a=a^b;b=b^a;a=a ^b
2
3 int main(void){
4 register int a=4;
5 register int b=5;
6 swap(a,b);
7
8 return 0;
9 }
The assemble code of the above code.

(gdb) disassemble main
Dump of assembler code for function main:
0x08048334 <main+0>: push %ebp
0x08048335 <main+1>: mov %esp,%ebp
0x08048337 <main+3>: sub $0x8,%esp
0x0804833a <main+6>: and $0xfffffff0,%es p
0x0804833d <main+9>: mov $0x0,%eax
0x08048342 <main+14>: add $0xf,%eax
0x08048345 <main+17>: add $0xf,%eax
0x08048348 <main+20>: shr $0x4,%eax
0x0804834b <main+23>: shl $0x4,%eax
0x0804834e <main+26>: sub %eax,%esp
0x08048350 <main+28>: mov $0x0,%eax
0x08048355 <main+33>: leave
0x08048356 <main+34>: ret
End of assembler dump.

where is the XOR instruction?

if I remove the keyword "register" in my C program.
1 #define swap(a,b) a=a^b;b=b^a;a=a ^b
2
3 int main(void){
4 int a=4;
5 int b=5;
6 swap(a,b);
7 return 0;
8 }

I'll got the following "monster" asm code...
(gdb) disassemble main
Dump of assembler code for function main:
0x08048334 <main+0>: push %ebp
0x08048335 <main+1>: mov %esp,%ebp
0x08048337 <main+3>: sub $0x8,%esp
0x0804833a <main+6>: and $0xfffffff0,%es p
0x0804833d <main+9>: mov $0x0,%eax
0x08048342 <main+14>: add $0xf,%eax
0x08048345 <main+17>: add $0xf,%eax
0x08048348 <main+20>: shr $0x4,%eax
0x0804834b <main+23>: shl $0x4,%eax
0x0804834e <main+26>: sub %eax,%esp
0x08048350 <main+28>: movl $0x4,0xfffffffc (%ebp)
0x08048357 <main+35>: movl $0x5,0xfffffff8 (%ebp)
0x0804835e <main+42>: mov 0xfffffff8(%ebp ),%edx
0x08048361 <main+45>: lea 0xfffffffc(%ebp ),%eax
0x08048364 <main+48>: xor %edx,(%eax)
0x08048366 <main+50>: mov 0xfffffffc(%ebp ),%edx
0x08048369 <main+53>: lea 0xfffffff8(%ebp ),%eax
0x0804836c <main+56>: xor %edx,(%eax)
0x0804836e <main+58>: mov 0xfffffff8(%ebp ),%edx
0x08048371 <main+61>: lea 0xfffffffc(%ebp ),%eax
0x08048374 <main+64>: xor %edx,(%eax)
0x08048376 <main+66>: mov $0x0,%eax
0x0804837b <main+71>: leave
0x0804837c <main+72>: ret
End of assembler dump.

Another strange thing is the xor instruction.
Plz see the code:
0x0804835e <main+42>: mov 0xfffffff8(%ebp ),%edx
0x08048361 <main+45>: lea 0xfffffffc(%ebp ),%eax
0x08048364 <main+48>: xor %edx,(%eax)
0x08048366 <main+50>: mov 0xfffffffc(%ebp ),%edx
0x08048369 <main+53>: lea 0xfffffff8(%ebp ),%eax
0x0804836c <main+56>: xor %edx,(%eax)

why dont use
xor %edx,(%eax)
xor %eax,(%edx)
to replace the redundent
0x08048366 <main+50>: mov 0xfffffffc(%ebp ),%edx
0x08048369 <main+53>: lea 0xfffffff8(%ebp ),%eax

Thanx!!!!

[Andrey Tarasevich]

Keith Thompson wrote:

...
First, any operation can be eliminated if its result isn't used, which
I think is what was happening with the OP's code.

Leaving that aside, there are a lot of cases where a multiplication by
a constant can be replaced by some cheaper operation such as a shift
...
That can happen if the compiler knows that both operands have the
value 0 or 1 (but only if a non-equality check is cheaper than an xor
...

This is all great, but my point is, once again, that in general case one
should not expect the compiler to unconditionally translate C operators
into their "intuitive" counterparts in machine language (which is what
the OP seems to do). There are several reasons why this might not be the
case, regardless of whether the result of the expression is used in the
program or not. One thing worth mentioning is that often the seemingly
natural mapping between C operators and machine instructions is not
really that straightforward when one starts to look closer and notices
some little but important detail of C operator specification (like, for
example, the requirement of integral division to operate in accordance
"round towards zero" approach).

--
Best regards,
Andrey Tarasevich

[Keith Thompson]

Andrey Tarasevich <an************ **@hotmail.com> writes:

Keith Thompson wrote:

...
First, any operation can be eliminated if its result isn't used, which
I think is what was happening with the OP's code.

Leaving that aside, there are a lot of cases where a multiplication by
a constant can be replaced by some cheaper operation such as a shift
...
That can happen if the compiler knows that both operands have the
value 0 or 1 (but only if a non-equality check is cheaper than an xor
...

This is all great, but my point is, once again, that in general case one
should not expect the compiler to unconditionally translate C operators
into their "intuitive" counterparts in machine language (which is what
the OP seems to do). There are several reasons why this might not be the
case, regardless of whether the result of the expression is used in the
program or not. One thing worth mentioning is that often the seemingly
natural mapping between C operators and machine instructions is not
really that straightforward when one starts to look closer and notices
some little but important detail of C operator specification (like, for
example, the requirement of integral division to operate in accordance
"round towards zero" approach).

I agree with your point. I just think you picked a poor example to
demonstrate it.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Randy Howard]

In article <33************ *@individual.ne t>, Mi**********@in valid.invalid
says...

Dave win wrote:

howdy....
plz take a look at the following codes, and tell me the reason.

1 #define swap(a,b) a=a^b;b=b^a;a=a ^b

This macro will break when used in a loop.
Use
#define swap(a,b) do { \
a=a^b;b=b^a;a=a ^b;\
} while(0)
to circumvent this problem.

It's still broken in that it does not work properly in all cases.
See the FAQ.

[Malcolm]

"Keith Thompson" <ks***@mib.or g> wrote

One thing worth mentioning is that often the seemingly
natural mapping between C operators and machine instructions is not
really that straightforward when one starts to look closer and notices
some little but important detail of C operator specification (like, for
example, the requirement of integral division to operate in accordance
"round towards zero" approach).

I agree with your point. I just think you picked a poor example to
demonstrate it.

I sort of agree as well. One of the strengths of C is that the programmer
has a pretty good idea of what assembly will be generated, and thus an
inutitive feel for how processor-intensive his function will be. However to
extend this to assuming that "I have used a XOR therefore the instruction
XOR must appear in the machine code" is dangerous. Most of the time you will
be correct, but it might be that the instruction can be optimised away, as
happened to the OP, or it might be that an alternative is chosen by the
compiler for some obscure reason. So if the actual machine instructions are
vital, you should program in actual assembler.