Další info o 64bit architektuře

> With the Win64 calling convention, first the caller has to reserve
> space on the stack before making the call, and the called function
> always has to create a stack frame, even if it doesn't make any use
> of the stack itself.
>
> e.g. when calling a simple function in a tight loop this makes a huge
> difference.

That is all very true. However there *is* a slight performance
"claw-back" from the very way the stack frames are set up. Upon
function entry, the prologue code reserves enough stack space for all
the local parameters *and* the maximum number of parameters needed
between *all* the subsequent calls. The compiler no longer generates
PUSH instructions at each call sight, rather it merely MOVes the
parameters into the proper slot directly onto the stack (remember it's
been pre-allocated in the function's prologue).

This serves the purpose of ensuring that the stack always remains
aligned on a 16byte boundary and the stack isn't bouncing around quite
as much. The compiler can also make further optimizations if a given
function is a "leaf" function (meaning it makes no further calls).

Yes, in general, the x64 calling convention has greater overhead,
however it is not *all* bad. There are some overal systemic
efficiencies gained from less overall "stack churn" and nearly nil
impact on the normal execution flow when no exceptions are in play.

As for code size, yes there will some growth in actual code size due to
the need for the "REX" prefix when doing 64bit register/memory
operations or accessing the R8-R15 (and/or XMM8-XMM15). Even then, many
instructions are the same size and use 32bit RIP-relative offsets
instead of a 32bit segment offsets. In fact, only three segment
registers are even available, SS, FS and GS. The OS defines the values
and you can't change them.