0

I don't understand why the following lines are using movl to push data below the stack pointer are produced by GCC.

movl    -4(%ebp), %eax      # -4(%ebp) <- local variable 1
movl    8(%ebp), %edx       # 8(%ebp)  <- first parameter
movl    %edx, 8(%esp)       # ??? WHY NOT:   pushl %edx
movl    %eax, 4(%esp)       # ??? WHY NOT:   pushl %eax
movl    -8(%ebp), %eax      # ??? WHY NOT:   pushl -8(%ebp)
movl    %eax, (%esp)
call    athena
movl    %eax, f

(full code)

I guess this code tries to push 3 parameters for the function call. But why isn't it using pushl. What is the usage of this code and how does this work?

miho
  • 11,765
  • 7
  • 42
  • 85
  • I don't know why does it work that way. Maybe because the code is similar to the x86-64 in which you pass the parameters via registers? (so for example, they would only have a "load value into.." instruction). Also, have you seen this question? http://stackoverflow.com/questions/22267767/why-is-gcc-using-mov-instead-of-push-in-function-calls – Marco Apr 26 '14 at 11:41
  • 5
    PUSH is a legacy instruction that does not execute well on modern cores. It has an indirect dependency on the value of the ESP register. That makes it hard to execute out-of-order. No such problems with the MOVs. As noted in the Intel optimization manual, coding rule 25. – Hans Passant Apr 26 '14 at 12:03
  • Is there something missing here? I would expect somewhere before the `movel`s would be a `sub %esp,xxx` where `xxx` is the size of the parameters to be passed? And then when the call returns, shortly thereafter, `add %esp,xxx`? – lurker Apr 26 '14 at 12:49
  • Also note it's not "below the stack pointer" it's actually above. gcc has options to control this behavior, see `-mpush-args` and `-maccumulate-outgoing-args` in the manual. They also give some explanation there. – Jester Apr 26 '14 at 13:34

1 Answers1

3

Hans Passant answered correctly. The push/pop opcodes can be broken down into two micro-ops which do a memory move and an increment/decrement of the stack pointer. If the stack pointer - or any pointer - is updated and then immediately used in the next opcode, an execution stall generally occurs. By accessing the individual memory locations through the stack pointer - as in your example - there would be no stall and the operations could be paired allowing them to be executed simultaneously.

Any superscalar CPU type will attempt to execute multiple opcodes in a single cycle if their results/sources have nothing to do with one another. The compiler is doing something for you to speed up execution that would be fairly laborious to do by hand. The opcodes may occupy more space than pushes, but they will execute roughly twice as fast - all other things being the same.

user3575124
  • 91
  • 3