problem with MSVC

[raashid bhatt]

i am compiling my c program with MSVC its just a simple program

int main()
{
int a;
++a; // INC assembly instruction
return 0; // RET instruction
}

then i compile it

cl /O1 /c sample.c
link /SUBSYSTEM:CONSOLE /ENTRY:main /NODEFAULTLIB sample.obj

i compiled the program with the removal of libc but when i disassemble
the program i dont get the INC instruction

i only get this

XOR EAX,EAX
RET

Rather than

INC ADDRESS_OF_VAR
RET

 

[Antoninus Twink]

The compiler is optimising away the inc instruction.
You need to take a on the command line (use atoi), increment it, and print
the result.

Or make a volatile.

(If you're compiling for an Intel chip, don't expect to see an INC
instruction generated - it will be an ADD instead for amusing historical
reasons...)

 

[Ben Bacarisse]

i am compiling my c program with MSVC its just a simple program

int main()
{
int a;
++a; // INC assembly instruction
return 0; // RET instruction
}

then i compile it

cl /O1 /c sample.c
link /SUBSYSTEM:CONSOLE /ENTRY:main /NODEFAULTLIB sample.obj

i compiled the program with the removal of libc but when i disassemble
the program i dont get the INC instruction

i only get this

XOR EAX,EAX
RET

That is correct. Your program has no effect other than to return zero
to the host environment.

There is another issue. By incrementing an indeterminate value pretty
much anything can happen (though there is some debate about exactly
how bad this is).

Rather than

INC ADDRESS_OF_VAR
RET

The compiler is allowed to remove the increment if it can be sure
there is no need to for it, as in your example.

 

[santosh]

i am compiling my c program with MSVC its just a simple program

int main()
{
int a;
++a; // INC assembly instruction
return 0; // RET instruction
}

then i compile it

cl /O1 /c sample.c
link /SUBSYSTEM:CONSOLE /ENTRY:main /NODEFAULTLIB sample.obj

i compiled the program with the removal of libc but when i disassemble
the program i dont get the INC instruction

i only get this

XOR EAX,EAX
RET

Rather than

INC ADDRESS_OF_VAR
RET

The compiler detects that the increment of 'i' has no effect whatsoever
and optimises it away. C compilers have become so good these days that
expecting them to produce the same sort of output that an assembler
beginner might produce is unrealistic. If you want to learn assembler
then do so with a proper assembler and necessary pedagogic material.
Examining the output of modern C compilers will quickly get *very*
confusing, even with optimisations disabled. Compiler assembler output
is not meant for beginners.

Anyway, to get the compiler to actually increment 'i' qualify it as
volatile. This will suppress all optimisations on it.

volatile int i;

int main(void) {
i++;
return 0;
}

 

[Serve Lau]

Or make a volatile.

(If you're compiling for an Intel chip, don't expect to see an INC
instruction generated - it will be an ADD instead for amusing historical
reasons...)

amuse me

 

[Antoninus Twink]

amuse me

OK, so it's not all that amusing, but here's an extract from
<http://www.intel.com/design/processor/manuals/248966.pdf>:

Assembly/Compiler Coding Rule 32. INC and DEC instructions should be
replaced with ADD or SUB instructions, because ADD and SUB overwrite all
flags, whereas INC and DEC do not, therefore creating false dependencies
on earlier instructions that set the flags.

 

[santosh]

OK, so it's not all that amusing, but here's an extract from
<http://www.intel.com/design/processor/manuals/248966.pdf>:

Assembly/Compiler Coding Rule 32. INC and DEC instructions should be
replaced with ADD or SUB instructions, because ADD and SUB overwrite
all flags, whereas INC and DEC do not, therefore creating false
dependencies on earlier instructions that set the flags.

If you had used the word might for the word will in your post up-thread,
then this discussion would not have been necessary.

 

[Keith Thompson]

Antoninus Twink wrote: [snip]

If you had used the word might for the word will in your post up-thread,
then this discussion would not have been necessary.

It wasn't necessary anyway.