The same assembler code for foo(char&) and foo(char*)

[Alex Vinokur]

==========================================
Windows 2000 Professional
CYGWIN_NT-5.0 1.5.4(0.94/3/2)
GNU g++ version 3.2 20020927 (prerelease)
GNU objdump 2.14.90 20030901
==========================================


We can see that the same assembly code is generated for
* foo2 (char& )
and
* foo3 (char* ).

Does it mean that after parsing
a compiler "sees"/implements foo(char&) and foo(char*)
as identical function?

In other words, on the assembly stage there is no difference
between char& and char* (?).


====== C++ code : BEGIN ======
// File t1.cpp

static int sink = 0;

static void foo1 (char var) { sink += var; }
static void foo2 (char& var) { sink += var; }
static void foo3 (char* ptr) { sink += *ptr; }
static void foo4 () { sink += 1; }

====== C++ code : END ========



====== Compilation : BEGIN ======

$ g++ -c t1.cpp

====== Compilation : END ========



====== objdump : BEGIN ======

$ objdump -CSD t1.o

t1.o: file format pe-i386

Disassembly of section .text:

00000000 <foo1(char)>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 04 sub $0x4,%esp
6: 8b 45 08 mov 0x8(%ebp),%eax
9: 88 45 ff mov %al,0xffffffff(%ebp)
c: 0f be 45 ff movsbl 0xffffffff(%ebp),%eax
10: 01 05 00 00 00 00 add %eax,0x0
16: c9 leave
17: c3 ret

00000018 <foo2(char&)>:
18: 55 push %ebp
19: 89 e5 mov %esp,%ebp
1b: 8b 45 08 mov 0x8(%ebp),%eax
1e: 0f be 00 movsbl (%eax),%eax
21: 01 05 00 00 00 00 add %eax,0x0
27: 5d pop %ebp
28: c3 ret
29: 90 nop

0000002a <foo3(char*)>:
2a: 55 push %ebp
2b: 89 e5 mov %esp,%ebp
2d: 8b 45 08 mov 0x8(%ebp),%eax
30: 0f be 00 movsbl (%eax),%eax
33: 01 05 00 00 00 00 add %eax,0x0
39: 5d pop %ebp
3a: c3 ret
3b: 90 nop

0000003c <foo4()>:
3c: 55 push %ebp
3d: 89 e5 mov %esp,%ebp
3f: ff 05 00 00 00 00 incl 0x0
45: 5d pop %ebp
46: c3 ret
47: 90 nop
48: 90 nop
49: 90 nop
4a: 90 nop
4b: 90 nop
4c: 90 nop
4d: 90 nop
4e: 90 nop
4f: 90 nop
Disassembly of section .data:

00000000 <sink>:
...

====== objdump : END ========


=====================================
Alex Vinokur
mailto:[email protected]
http://mathforum.org/library/view/10978.html
=====================================

 

[=?iso-8859-1?Q?Andr=E9_P=F6nitz?=]

GNU g++ version 3.2 20020927 (prerelease)
GNU objdump 2.14.90 20030901
[...]
We can see that the same assembly code is generated for
* foo2 (char& )
and
* foo3 (char* ).

Does it mean that after parsing
a compiler "sees"/implements foo(char&) and foo(char*)
as identical function?

That's an implemtation detail. Implementing references as pointers is
certainly feasible and - as you have shown - done.

It is not required by the language, though.

Andre'

 

[Paul Pluzhnikov]

Implementing references as pointers is
certainly feasible and - as you have shown - done.

How *else* could you implement references?

Cheers,

 

[Ron Natalie]

How *else* could you implement references?

Except in a few cases where they need to actually be stored
(like you put a reference member in a class), the compiler just
inserts whatever it would have needed to access the original
object. A trivial example;

int i = 5;
int& r = i;

r++;

I know of no compiler that would actually allocate any storage for r
(as a matter of fact, the code generated is indistinguisable from

i++;

 

[=?iso-8859-1?Q?Andr=E9_P=F6nitz?=]

How *else* could you implement references?

I don't know...

Andre'

 

[Rob Williscroft]

Paul Pluzhnikov wrote in

How *else* could you implement references?

When you need to pass or store a reference then they do need
to be pointers, but not nessaseraly the same *type* of pointer
as a regular C++ ponters, references arn't allowed by the
language to be NULL for instance, so there maybe some machines
out there for which a reference can be stored in a more efficient
way than a pointer.


Rob.

 

[Jack Klein]

==========================================
Windows 2000 Professional

Windows 2000 Professional is off-topic in comp.lang.c++.

CYGWIN_NT-5.0 1.5.4(0.94/3/2)

The version of your platform's infrastructure is off-topic in
comp.lang.c++.

GNU g++ version 3.2 20020927 (prerelease)

The version of your compiler is off-topic in comp.lang.c++.

GNU objdump 2.14.90 20030901

The version of some utility program you use is off-topic in
comp.lang.c++.

==========================================


We can see that the same assembly code is generated for

Assembly language generated by any compiler is off-topic in
comp.lang.c++.

Stop cross-posting off-topic crap to comp.lang.c++.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Jerry Coffin]

[ ... ]

We can see that the same assembly code is generated for
* foo2 (char& )
and
* foo3 (char* ).

Does it mean that after parsing
a compiler "sees"/implements foo(char&) and foo(char*)
as identical function?

At most, it means that one port of one compiler produces similar code
for the implementation. Certainly code generation comes after parsing,
but that's certainly not ALL that happens after parsing, and there's no
question that throughout most of the compilation process, the two _must_
be treated distinctly from each other.