Scribd
Upload
167 views3 pages

Calling Conventions in C

The document discusses different calling conventions in C including CDECL, STDCALL, FASTCALL, SYSCALL, STDCALL, VECTORCALL, SAFECALL, and the Microsoft X64 calling convention. It provides details on how each convention handles passing arguments, returning values, and preserving registers. For example, it notes that CDECL passes arguments right-to-left on the stack and returns integers in EAX and floats in ST0. It also provides additional resources on calling conventions.

Uploaded by

mahamd saied
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
167 views3 pages

Calling Conventions in C

The document discusses different calling conventions in C including CDECL, STDCALL, FASTCALL, SYSCALL, STDCALL, VECTORCALL, SAFECALL, and the Microsoft X64 calling convention. It provides details on how each convention handles passing arguments, returning values, and preserving registers. For example, it notes that CDECL passes arguments right-to-left on the stack and returns integers in EAX and floats in ST0. It also provides additional resources on calling conventions.

Uploaded by

mahamd saied
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

:Calling conventions in c

--:)da t3rif calling conventions w 3 mnhom 2ly homa (CDECL,STDCALL,FASTCALL) (


https://en.wikibooks.org/wiki/X86_Disassembly/Calling_Conventions

--:)Description for calling conventions on Windows,Linux and Mac IO (

https://scc.ustc.edu.cn/zlsc/sugon/intel/compiler_c/main_cls/bldaps_cls/common/bldap

--(da pdf feh goz2 3n calling conventions (p.17)):

https://www.agner.org/optimize/calling_conventions.pdf

--:) da t3rif l kol calling conventions (

cdecl - In cdecl, subroutine arguments are passed on the stack. Integer values
and memory addresses are returned in the EAX register, floating point values in
the ST0 x87 register. Registers EAX, ECX, and EDX are caller-saved, and the
rest are callee-saved. The x87 floating point registers ST0 to ST7 must be empty
(popped or freed) when calling a new function, and ST1 to ST7 must be empty on
.exiting a function. ST0 must also be empty when not used for returning a value

pascal - the parameters are pushed on the stack in left-to-right order (opposite
of cdecl), and the callee is responsible for balancing the stack before return.

fastcall - __fastcall convention (aka __msfastcall) passes the first two


arguments (evaluated left to right) that fit into ECX and EDX. Remaining
arguments are pushed onto the stack from right to left.

syscall - This is similar to cdecl in that arguments are pushed right-to-left. EAX,
ECX, and EDX are not preserved. The size of the parameter list in double words
is passed in AL.

stdcall - The stdcall[4] calling convention is a variation on the Pascal calling


convention in which the callee is responsible for cleaning up the stack, but the
parameters are pushed onto the stack in right-to-left order, as in the _cdecl
calling convention. Registers EAX, ECX, and EDX are designated for use within
the function. Return values are stored in the EAX register.

vectorcall - In Visual Studio 2013, Microsoft introduced the __vectorcall


calling convention in response to efficiency concerns from game, graphic,
video/audio, and codec developers.[7] For IA-32 and x64 code, __vectorcall is
similar to __fastcall and the original x64 calling conventions respectively, but
extends them to support passing vector arguments using SIMD registers. For
x64, when any of the first six arguments are vector types (float, double, __m128,
__m256, etc.), they are passed in via the corresponding XMM/YMM registers.
Similarly for IA-32, up to six XMM/YMM registers are allocated sequentially for
vector type arguments from left to right regardless of position. Additionally,
__vectorcall adds support for passing homogeneous vector aggregate (HVA)
values, which are composite types consisting solely of up to four identical vector
types, using the same six registers. Once the registers have been allocated for
vector type arguments, the unused registers are allocated to HVA arguments
from left to right regardless of position. Resulting vector type and HVA values are
returned using the first four XMM/YMM registers

safecall - n Delphi and Free Pascal on Microsoft Windows, the safecall calling
convention encapsulates COM (Component Object Model) error handling, thus
exceptions aren't leaked out to the caller, but are reported in the HRESULT return
value, as required by COM/OLE. When calling a safecall function from Delphi
code, Delphi also automatically checks the returned HRESULT and raises an
exception if necessary.
The safecall calling convention is the same as the stdcall calling convention,
except that exceptions are passed back to the caller in EAX as a HResult
(instead of in FS:[0]), while the function result is passed by reference on the stack
as though it were a final "out" parameter. When calling a Delphi function from
Delphi this calling convention will appear just like any other calling convention,
because although exceptions are passed back in EAX, they are automatically
converted back to proper exceptions by the caller. When using COM objects
created in other languages, the HResults will be automatically raised as
exceptions, and the result for Get functions is in the result rather than a
parameter. When creating COM objects in Delphi with safecall, there is no need
to worry about HResults, as exceptions can be raised as normal but will be seen
as HResults in other languages.

Microsoft X64 Calling Convention - The Microsoft x64 calling


convention[12][13] is followed on Windows and pre-boot UEFI (for long mode on
x86-64). It uses registers RCX, RDX, R8, R9 for the first four integer or pointer
arguments (in that order), and XMM0, XMM1, XMM2, XMM3 are used for floating
point arguments. Additional arguments are pushed onto the stack (right to left).
Integer return values (similar to x86) are returned in RAX if 64 bits or less.
Floating point return values are returned in XMM0. Parameters less than 64 bits
long are not zero extended; the high bits are not zeroed.
When compiling for the x64 architecture in a Windows context (whether using
Microsoft or non-Microsoft tools), there is only one calling convention – the one
described here, so that stdcall, thiscall, cdecl, fastcall, etc., are now all one and
the same.

In the Microsoft x64 calling convention, it is the caller's responsibility to allocate


32 bytes of "shadow space" on the stack right before calling the function
(regardless of the actual number of parameters used), and to pop the stack after
the call. The shadow space is used to spill RCX, RDX, R8, and R9,[14] but must
be made available to all functions, even those with fewer than four parameters.

The registers RAX, RCX, RDX, R8, R9, R10, R11 are considered volatile (caller-
saved).[15]
The registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are
considered nonvolatile (callee-saved).[15]

For example, a function taking 5 integer arguments will take the first to fourth in
registers, and the fifth will be pushed on the top of the shadow space. So when
the called function is entered, the stack will be composed of (in ascending order)
the return address, followed by the shadow space (32 bytes) followed by the fifth
parameter.

In x86-64, Visual Studio 2008 stores floating point numbers in XMM6 and XMM7
(as well as XMM8 through XMM15); consequently, for x86-64, user-written
assembly language routines must preserve XMM6 and XMM7 (as compared to
x86 wherein user-written assembly language routines did not need to preserve
XMM6 and XMM7). In other words, user-written assembly language routines
must be updated to save/restore XMM6 and XMM7 before/after the function
when being ported from x86 to x86-64.

((As a side-note: all of the listed above are applicable to externally linked functions,
and functions that CAN be externally called (a pointer to function is taken somewhere
in the unit). If a compiler (I'm speaking of x86 MSVC, but it may be extended to others)
can deduce that the function is linked only internally (within single compilation unit -
o/obj) AND it also considers it a less overhead by not inlining one, it is free in how it
assigns registers / stack slots to arguments))

>>>Videos<<<

https://www.youtube.com/watch?v=hlpW_BqGmvM

>>> (CDECL) :

https://www.youtube.com/watch?v=frqPX7EHscM

You might also like