ZZ function call Convention (_ cdecl + _ stdcal + _ fastcall)

Calling convention)Determine the following:The order in which function parameters are pushed to the stack. The caller or the caller pushes the parameter to the stack and generates the function modifier name.

 

 

Use _ cdeclCalling convention)Determine the following:The order in which function parameters are pushed to the stack. The caller or the caller pushes the parameter to the stack and generates the function modifier name.

 

 

Use _ cdeclTiming:Function parameters are written to the stack in the order from right to left, and the caller pops up the parameter stack to clear the stack.

Use _ stdcalTiming:Function parameters are written to the stack in the order from right to left. The called function clears the stack of the transfer parameter before return. The number of function parameters is fixed. Because the function body knows the number of passed parameters, the called function can directly clear the stack of the passed parameters with a RET n command before returning the result.

 

Use _ fastcallTiming:Put the two DWORD parameters starting from the left in the ECX and EDX registers respectively, and the other parameters are still transmitted from the right to the left pressure stack, the called function clears the stack of the transfer parameter before returning.

 

 

_ CdeclAnd _ stdcalThe only difference between them is thatWhether the stack is cleared by the caller or by the caller.

However, what is the impact of these two methods of clearing stacks?

 

 

_ StdcallAnd _ cdeclDifferences between the two:

Stack is required for Windows function calling (stack, a storage structure that is imported first and then output ). After the function call is complete, the stack needs to be cleared. Here is the key to the problem. How can we clear it?

If the function uses _ cdecl, the stack cleanup is done by the caller. In terms of COM, it is done by the customer. This brings about a difficult problem. Different compilers may generate stacks in different ways. Can the caller complete the cleanup work normally? The answer is no.

If _ stdcall is used, the above problem is solved, and the function solves the clearing work by itself. Therefore, in cross-platform (Development) calls, we use _ stdcall (although sometimes it appears as winapi ).

So why do we still need _ cdecl? When the parameters of such a function, such as fprintf (), are variable and variable, the caller cannot know the length of the parameter in advance, and the cleanup operation afterwards cannot proceed normally, therefore, we can only use _ cdecl in this case.

Here we have a conclusion that if your program does not involve variable parameters, it is best to use the _ stdcall keyword.

 

========================================================== ==================

Http://hi.baidu.com/lijinming119/blog/item/ed2fe4f5619d1823bc310915.html

 

Start with _ stdcall encountered when writing a thread function.

When writing a thread function today, we found that the threadproc definition in msdn has requirements: DWORD winapi threadproc (lpvoid lpparameter );

I don't know why to use the winapi macro definition. I found the following definition after checking it. The difference between _ stdcall and _ cdecl is needed;

# Define callback _ stdcall
# Define winapi _ stdcall
# Define winapiv _ cdecl
# Define apientry winapi
# Define apiprivate _ stdcall
# Define Pascal _ stdcall
# Define cdecl _ cdecl
# Ifndef cdecl
# Define cdecl _ cdecl
# Endif

Almost every Windows API function we write is of the _ stdcall type. First, we need to know the difference between the two: Stack (stack, A storage structure ). After the function call is complete, the stack needs to be clear. Here is the key to the problem. How can we clear it ?? If our function uses _ cdecl, the stack clearing is done by the caller. In terms of COM, it is done by the customer. This brings about a difficult problem. Different compilers may generate stacks in different ways. Can the caller complete the cleanup work normally? The answer is no. If _ stdcall is used, the above problem is solved, and the function solves the clearing work by itself. Therefore, in cross-platform (Development) calls, we use _ stdcall (although sometimes it appears as winapi ). So why do we still need _ cdecl? When the parameters of such a function, such as fprintf (), are variable and variable, the caller cannot know the length of the parameter in advance, the cleanup operation afterwards cannot be performed normally. Therefore, we can only use _ cdecl in this case. Here we have a conclusion that if your program does not involve variable parameters, it is best to use the _ stdcall keyword.

What do cdecl, Pascal, stdcall, fastcall and other modifiers mean?

What do cdecl, Pascal, stdcall, fastcall and other modifiers mean?
It is very simple, that is, some descriptions of the stack. The first is the function parameter pressure stack sequence, and the second is
Who clears the content pushed into the stack, the caller or the function itself?
These switches are used to tell the compiler what kind of assembly code is generated.

The differences are listed below:

Directive Parameter order Clean-up Passes parameters in registers?
Register left-to-right routine Yes
Pascal left-to-right routine no
Cdecl right-to-left caller No
Stdcall right-to-left routine no
Safecall right-to-left routine no

Simple Description:

_ Cdecl is the call Convention used by C/C ++ and MFC programs by default. You can also add the _ cdecl keyword when declaring a function. When _ cdecl is used, function parameters are pushed to the stack in the order from right to left, and the caller pops up the parameter stack to clear the stack. Therefore, the function that implements variable parameters can only use this call. Every function using the _ cdecl Convention must contain the code for clearing the stack, so the size of the executable file generated will be relatively large. _ Cdecl can be written as _ cdecl.
_ Stdcall is used to call Win32 API functions. When _ stdcal is used, function parameters are written to the stack in the order from right to left. The called function clears the stack of the transfer parameter before returning, and the number of function parameters is fixed. Because the function itself knows the number of parameters passed in, the called function can use the RET n command to directly clear the stack of the passed parameters before returning. _ Stdcall can be written as _ stdcall.
_ Fastcall conventions are used in scenarios with high performance requirements. _ Fastcall: The two DWORD parameters starting from the left of the function are stored in the ECX and EDX registers respectively, the other parameters are still transmitted from the right to the left pressure stack. The called function clears the stack of the transfer parameter before returning. _ Fastcall can be written as _ fastcall.

· Special instructions
1. The _ cdecl method is used by default, so it can be omitted.
2. winapi is generally used to modify the export function in the dynamic link library.
3. Callback is only used to modify callback functions.

_ Cdecl _ fastcall and _ stdcall

Call conventions:
_ Cdecl _ fastcall and _ stdcall are call conventions (calling convention), which determine the following content: 1) the order of function parameters in the pressure stack; 2) the parameter pop-up stack is made by the caller or the caller. 3) the method for generating the function modifier name.

1. _ stdcall call Convention: The function parameters are passed from right to left through the stack. The called function clears the memory stack of the transfer parameter before returning,

2. _ cdecl is the default call Method for C and C ++ programs. Every function that calls it contains the code to clear the stack. Therefore, the size of the executable file generated is larger than that of the call to the _ stdcall function. The function uses the stack pressure mode from right to left. Note: For Variable Parameter member functions, always use the _ cdecl conversion method.

3. _ fastcall: it transmits parameters through registers (in fact, it uses ECx and EDX to transmit the first two DWORD or smaller parameters, the remaining parameters are still transmitted from the right to the left pressure stack, and the called function clears the memory stack of the transfer parameter before returning ).

4. thiscall is only applied to "C ++" member functions. This pointer is stored in the Cx register and the parameter is pressed from right to left. Thiscall is not a keyword and cannot be specified by programmers.

5. Naked call uses 1-4 call timing. If necessary, the compiler will generate code to save the ESI, EDI, EBX, and EBP registers when entering the function, when you exit the function, the code is generated to restore the content of these registers. Naked call does not generate such code. The naked call is not a type modifier, so it must be used together with _ declspec.

Call conventions can be selected through the Project Settings: setting.../C ++/code generation item. The default status is _ cdecl.

Naming Conventions:

1. decoration name: "C" or "C ++" functions are internally (compiled and linked) identified by modifier names.
2. Agreed rules for function name modification during C Compilation:
The _ stdcall call Convention adds an underline prefix before the output function name, followed by a "@" symbol and the number of bytes of the parameter. The format is _ functionname @ number. For example: function (int A, int B), whose name is: _ FUNCTION @ 8
The _ cdecl call Convention only adds an underline prefix before the output function name in the format of _ functionname.
_ Fastcall: Add a "@" symbol before the output function name, followed by a "@" symbol and the number of bytes of the parameter. The format is @ functionname @ number.

3. Agreed rules for function name modification during C ++ Compilation:
_ Stdcall call conventions:
1) "? "Mark the start of the function name, followed by the function name;
2) The function name starts with "@ YG", followed by the parameter table;
3) The parameter table is represented in code:
X -- void,
D -- char,
E -- unsigned char,
F -- short,
H -- int,
I -- unsigned int,
J -- long,
K -- unsigned long,
M -- float,
N -- double,
_ N -- bool,
Pa -- indicates the pointer. The code behind the pointer indicates the pointer type. If a pointer of the same type appears consecutively, it is replaced by "0". A "0" indicates a repetition;
4) the first item of the parameter table is the type of the return value of the function, followed by the Data Type of the parameter, and the pointer ID is before the data type referred to by the function;
5) The end of the name is marked with "@ Z" after the parameter table. If this function has no parameter, it ends with "Z.
The format is "? Functionname @ YG ***** @ Z "or "? Functionname @ YG * xz ", for example
Int test1 (char * var1, unsigned long) ----- "? Test1 @ yghpadk @ Z"
Void Test2 () ----- "? Test2 @ ygxxz"

_ Cdecl:
The rules are the same as the _ stdcall call Convention above, except that the start mark of the parameter table is changed from "@ YG" to "@ ya ".
_ Fastcall:
The rules are the same as the _ stdcall call Convention above, except that the start identifier of the parameter table changes from "@ YG" to "@ Yi ".
The "_ cedcl" Declaration for the function can only be called by C/C ++.

Note:
1. _ beginthread requires the thread function address of _ cdecl, and _ stdcall for _ beginthreadex and createthread.

2. Generally, Win32 functions are _ stdcall. Windef. H has the following definitions:
# Define callback _ stdcall
# Define winapi _ stdcall

3. extern "C" _ declspec (dllexport) int _ cdecl add (int A, int B );
Typedef int (_ cdecl * funpointer) (int A, int B );
The modifier is written in the above Order.

4. Function of extern "C": If add (int A, int B) is compiled in the C language compiler and used in the C ++ file, you need to declare in the C ++ file: extern "C" add (int A, int B ), because the C compiler and C ++ compiler have different interpretations of function names (function parameters must be considered when the C ++ compiler interprets a function name, which facilitates function overloading, in C language, there is no function re-loading problem). The essence of using extern "C" is to tell the C ++ compiler that this function is a function in the C library. If you do not use extern "C", a link error occurs.
It is generally used as follows:
# Ifdef _ cplusplus
# Define extern_c extern "C"
# Else
# Define extern_c extern
# Endif

# Ifdef _ cplusplus
Extern "C "{
# Endif
Extern_c int func (int A, int B );
# Ifdef _ cplusplus
}
# Endif

5. MFC provides some macros. You can use afx_ext_class to replace _ declspec (dllexport) and modify the class name to export the class, afx_api_export to modify the function, and afx_data_export to modify the variable.
Afx_class_import :__ declspec (dllexport)
Afx_api_import :__ declspec (dllexport)
Afx_data_import :__ declspec (dllexport)
Afx_class_export :__ declspec (dllexport)
Afx_api_export :__ declspec (dllexport)
Afx_data_export :__ declspec (dllexport)
Afx_ext_class: # ifdef _ afxext
Afx_class_export
# Else
Afx_class_import

6. dllmain is responsible for initialization and termination. Whenever a new process or a new thread of the Process accesses the DLL, or when every process or thread accessing the DLL no longer uses the DLL or ends, it will call dllmain. However, using terminateprocess or terminatethread to end a process or thread does not call dllmain.

7. One dll has only one instance in the memory.
The relationship between the DLL program and the program that calls its output function:
1) Relationship between DLL and process and thread
The DLL module is mapped to the virtual address space of the process that calls it.
The dll Memory is allocated from the virtual address space of the calling process and can only be accessed by the thread of the process.
The DLL handle can be used by the calling process, and the call Process Handle can be used by the DLL.
Dlldll can have its own data segment but does not have its own stack. It uses the stack of the calling process, which is the same as the stack mode of the application that calls it.

2) about shared data segments
The global variables defined by dll can be accessed by the calling process; The dll can access the global data of the calling process. Each process using the same dll has its own DLL global variable instance. If multiple threads access the same variable, you need to use the synchronization mechanism. For a DLL variable, If you want each thread that uses the DLL to have its own value, the local thread storage should be used (TLS, Thread Local strorage ).