Exetools (https://forum.exetools.com/index.php)
-   x64 OS (https://forum.exetools.com/forumdisplay.php?f=44)
-   -   x64 calling convention and home space (https://forum.exetools.com/showthread.php?t=15350)

mcp 11-10-2013 07:44

x64 calling convention and home space
In the x64 calling convention, each parameter to a function has a corresponding record in the parent's function home space. Now, it seems unclear to me what the purpose of this is? Why has this decision been made? Doesn't that render the advantages,i.e. passing parameters via registers instead of using the stack, of x64 useless?

qkumba 11-10-2013 09:33

Your question begins with an invalid assumption. That space is reserved for register "spill", so that any special registers can be saved there if they will be used, without affecting the stack. If a function uses no special registers then the space won't be used (and might not even exist - it's compiler-dependent if it's even there).
The size of the space is fixed, so it's completely independent of the number of parameters.

mcp 11-10-2013 22:59

Nearly all of your points are completely wrong.
1) The space is not reserved for register spill, in fact there is no constraint on what the callee is supposed to do with that stack space: there is no reserved purpose for that area.
2) Since the callee can always rely on the existence of that area, he is free to use it for whatever he wants (if e.g. the optimizer decides to do so). That contradicts your "won't be used" claim.
3) It is not compiler dependent, all compilers for x64 on windows have to adhere to these conventions (at least when they interface with other compiler generated code or the OS API).
4) The size of the space is not fixed at all. To the contrary: the space depends on the number of parameters passed to the callee.

MSDN documentation


It contains at least four entries, but always enough space to hold all the parameters needed by any function that may be called. Note that space is always allocated for the register parameters, even if the parameters themselves are never homed to the stack; a callee is guaranteed that space has been allocated for all its parameters

qkumba 11-12-2013 11:34

riiight, because MSDN documentation is always correct...

mcp 11-12-2013 17:51

Well, MSDN is not the only source that describes the x64 calling convention exactly in this way. It also matches with the code I've seen being generated by compilers, so it is definitely correct.
I wonder though why you even try to answer a question which is obviously beyond your expertise, only to come up with a snarky response to my well founded criticism?!

qkumba 11-14-2013 04:01

1) it is intended for register spill. Nothing is stored there automatically. It avoids repeated push and pop sequences to save and restore the fastcall registers. If rcx and rdx are used as parameters, for example, and the compiler wants to use them for scratch registers, then they can be stored there.
2) your () in (3) contradicts your claim here.
3) your () here makes my point for me. It might not be there.
4) It is fixed. The first four parameters are in registers, and their space is reserved by the callee. The other parameters are pushed onto the stack by the caller. That's not home space anymore, that's regular stack calling convention.

mcp 11-14-2013 05:26

1) well, your original claim was that if a called function doesn't use any special registers, then it won't be used. That however is clearly false, as the called function is free to use the home space for whatever it likes. There is no "requirement" or "intent" to use it for register spill, the optimizer is free to use this space.
2/3) Well, what other x64 calling convention on windows do you know of?
4) That seems to be correct, according to MSDN and to code I've seen. My initial claim that it is not fixed and dependent on number of parameters was wrong.

matt 08-17-2015 11:40

Using homing space to retrieve register paras is NOT reliable, but could work for most of the time.

If anyone is still interested in this topic, check this url:

<Got here accidentally during a google search. >

All times are GMT +8. The time now is 03:38.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2022, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX