lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Apparently the non-Windows x64 ABI doesn’t use those “always reserved” four stack slots that correspond to where four parameters would be if the calling convention was purely stack based…

…but it does require the 16-byte stack alignment before a CALL. (Not sure what happens if you don’t do this.)

Indeed, it’s a wildly diverse world down there. 

> On 10 Aug 2022, at 03:53, Sean Conner <sean@conman.org> wrote:
> 
> It was thus said that the Great Paul Ducklin once stated:
>>> Not only are some of the register names
>>> different, but the calling convention is
>>> different between x86-32 bit (parameters
>>> passed on the system stack) and x86-6
>>> bit (first six parameters passed in registers,
>>> rest on the system stack
>> 
>> By convention, X64 calls have up to four parameters passed in registers
>> (RCX, RDX, R8 and R9). Any additional parameters are pushed on the stack
>> in reverse order.
> 
>  For Windows.  For Solaris, Linux, FreeBSD and MacOS, it's six registers
> (RDI RSI RDX RCX R8 R9) and any additional parameters are pushed on the
> stack in reverse order.
> 
>> Functions put their return value in RAX, if there is one.
> 
>  This is true for Linux, Solaris, FreeBSD and MacOS.
> 
>> (After pushing any needed stack parameters, the stack pointer is then
>> shifted downwards to leave room for four temporary values on the stack -
>> the called function can use this space for whatever it likes, such as
>> temporary storage of register parameters. At this point the desired
>> function is CALLed. Oh, and you are supposed to ensure that whenever a
>> CALL happens, the stack pointer RSP is a multiple of 16.)
> 
>  Again, for Windows; I am unsure of for other systems.  A decent place to
> start is the Wikipedia article:
> 
>    https://en.wikipedia.org/wiki/X86_calling_conventions
> 
>> https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170
> 
>  -spc (So yeah, to repeat what I said earlier---this is non-portable, and
>    it really depends upon the architecture and OS)