in reply to Re^4: Help me to understand increment / decrement operator behavior in perl
in thread Help me to understand increment / decrement operator behavior in perl

Try compiling with -O0, that usually forces auto variables to stack (may be useful when debugging).

Intels icc with -Os (size optimized) may load small constants like so: pushq $18; popq %rdi.

Replies are listed 'Best First'.
Re^6: Help me to understand increment / decrement operator behavior in perl
by BrowserUk (Patriarch) on Mar 05, 2015 at 08:29 UTC
    Try compiling with -O0

    (On MSVC) /O0 is the same as /Od and results in the same assembler output shown above right down to the annotation: ; Function compile flags: /Odtp.

    that usually forces auto variables to stack

    On (Windows) X64, the ABI designates that the first 4 args are passed in registers and the others on the stack.

    But that requires that there would be arguments passed. Whilst == is implemented as a (kind of) function call in Perl; it is not in C -- on any platform/compiler I am aware of.

    Even the integer C interpreter I had back in the day loaded one value into a register and the did a cmp reg, mem; instruction.

    may load small constants like so: pushq $18; popq %rdi.

    I'm not familiar with those style of opcodes -- they don't appear in my Intel manuals -- but assuming the 'q' in pushq/popq stands for quad (in 64-bit mode that's the only push/pop available), and this is a "small constant"; why does it store that small constant in a 64-bit memory location, then move it into a 64-bit register by moving it through another 64-bit memory location (on the stack) first?

    Why not use (in Intel Asm syntax) mov rdi, $18; (register to memory 64-bit move)?

    Or better yet, mov reg8/16/32/64, imm8/16/32/64;?

    Ie. store the small constant directly in the opcode itself; per this from the listing above: sub    eax, 1;

    (Note:I've never used Intel's compiler.)


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

      Well, in that same asm output, there's sub rsp, 56 (make room for the stack frame), then mov DWORD PTR a$[rsp], 10 (initializes the a variable on stack). In other words, variables are placed on stack.

      Regarding the push+pop: it takes fewer bytes. 2+1 == 3 vs 5 bytes of immediate mov.

        Well, in that same asm output, there's sub rsp, 56 (make room for the stack frame), then mov DWORD PTR a$rsp, 10 (initializes the a variable on stack). In other words, variables are placed on stack.

        Of course the C compiler uses the stack; just not for performing an integer comparison.

        The question is whether any C compiler would move a numeric value to the stack in order to compare it against another numeric value; not whether one or both of those values might have transitioned through the stack on their way to the point of comparison. So, I'm lost as to what point you are trying to make.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
        In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked