problem with MSVC

Discussion in 'C Programming' started by raashid bhatt, Aug 17, 2008.

  1. 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
    raashid bhatt, Aug 17, 2008
    #1
    1. Advertising

  2. On 17 Aug 2008 at 17:23, Malcolm McLean wrote:
    >> int a;
    >> ++a; // INC assembly instruction
    >>
    >> i compiled the program with the removal of libc but when i disassemble
    >> the program i dont get the INC instruction
    >>

    > 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...)
    Antoninus Twink, Aug 17, 2008
    #2
    1. Advertising

  3. raashid bhatt <> writes:

    > 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.

    --
    Ben.
    Ben Bacarisse, Aug 17, 2008
    #3
  4. raashid bhatt

    santosh Guest

    raashid bhatt wrote:

    > 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;
    }
    santosh, Aug 17, 2008
    #4
  5. raashid bhatt

    Serve Lau Guest

    "Antoninus Twink" <> schreef in bericht
    news:...
    > 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
    Serve Lau, Aug 18, 2008
    #5
  6. On 18 Aug 2008 at 16:47, Serve Lau wrote:
    > "Antoninus Twink" <> schreef:
    >> (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


    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.
    Antoninus Twink, Aug 18, 2008
    #6
  7. raashid bhatt

    santosh Guest

    Antoninus Twink wrote:

    > On 18 Aug 2008 at 16:47, Serve Lau wrote:
    >> "Antoninus Twink" <> schreef:
    >>> (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

    >
    > 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.
    santosh, Aug 19, 2008
    #7
  8. santosh <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 19, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan
    Replies:
    0
    Views:
    1,100
  2. Arkadiy Vertleyb
    Replies:
    1
    Views:
    1,432
    Victor Bazarov
    Jul 9, 2003
  3. =?ISO-8859-1?Q?Christian_Engstr=F6m?=

    Another base/derived problem with gcc, but not with MSVC

    =?ISO-8859-1?Q?Christian_Engstr=F6m?=, Feb 12, 2004, in forum: C++
    Replies:
    7
    Views:
    357
    John Harrison
    Feb 13, 2004
  4. h79
    Replies:
    2
    Views:
    414
  5. h79
    Replies:
    1
    Views:
    346
    Victor Bazarov
    Aug 30, 2004
Loading...

Share This Page