flat assembler
Message board for the users of flat assembler.

flat assembler > Windows > stack manipulation push vs mov[esp+xx]

Author
Thread Post new topic Reply to topic
int0x50



Joined: 19 Jul 2019
Posts: 13
in order to push values onto the stack, we can use push val1, push val2; etc.

However, I am seeing that compilers are using mov [esp + 4], mov [esp + 2], while pushing arguments to a function.

what is the difference? is there any specific reason that compilers are doing this.
Post 31 Jul 2019, 10:36
View user's profile Send private message Reply with quote
fpissarra



Joined: 10 Apr 2019
Posts: 58
int0x50 wrote:
in order to push values onto the stack, we can use push val1, push val2; etc.

However, I am seeing that compilers are using mov [esp + 4], mov [esp + 2], while pushing arguments to a function.

what is the difference? is there any specific reason that compilers are doing this.

Consider this:
Code:
push rbx
push rbp
push r12
...
    

Each PUSH will subtract 8 from RSP and write a value to the stack. The code above is the same as:
Code:
sub rsp,8
mov [rsp],rbx
sub rsp,8
mov [rsp],rbp
sub rsp,8
mov [rsp],r12
...    

Clearly this can be writen as:
Code:
sub rsp,24
mov [rsp+16],rbx
mov [rsp+8],rbp
mov [rsp],r12
...    
Post 31 Jul 2019, 11:00
View user's profile Send private message Reply with quote
int0x50



Joined: 19 Jul 2019
Posts: 13
Thanks for the response fpissarra. But why would compiler do that, instead of just pushing?
Post 31 Jul 2019, 11:04
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4208
Location: 2018
variables on stack are manipulated like this in functions bodies.

it depends on calling convention used by the compiler.
Post 31 Jul 2019, 11:06
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16737
Location: In your JS exploiting you and your system
It depends upon the compiler O setting, and maybe some other settings also. And there is the belief that using RISC type instructions (instead of CISC type) can equate to better performing code in some circumstances.

But like all optimisations it depends heavily upon which system the code is running on and the actual task it is performing. The extra code bytes can cause problems with cache thrashing, but the enhanced opportunities for the CPU to extract parallelism from the code stream may mitigate that. So there is a trade-off.

If you really need that particular function to perform at it's best then you will need to measure the final performance with each option. See which works best for your usage case.
Post 31 Jul 2019, 11:23
View user's profile Send private message Visit poster's website Reply with quote
fpissarra



Joined: 10 Apr 2019
Posts: 58
int0x50 wrote:
Thanks for the response fpissarra. But why would compiler do that, instead of just pushing?

I believe this was already explained by me:

PUSH will do 2 things: SUB RSP,8/MOV [RSP],reg/mem/imm
Multiple PUSHes will do these 2 things multiple times...
Post 31 Jul 2019, 16:40
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2795
Location: dank orb
This is such a common pattern that more modern processors have dedicated hardware to cope with stack changes.

https://stackoverflow.com/questions/36631576/what-is-the-stack-engine-in-the-sandybridge-microarchitecture

There is a symbiotic relationship between compilers and processor evolution. Processors are not strictly designed to be as fast/featureful as possible. Rather they are designed to meet the use cases of industry. If the majority of code is compiled by a handful of compilers then that is the target.

_________________
¯\(°_o)/¯ unlicense.org
Post 31 Jul 2019, 20:37
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2019, Tomasz Grysztar.

Powered by rwasa.