стандартный вызов и cdecl

Рэймонд Чен дает хороший обзор того, что делают __stdcall и __cdecl.

(1) Вызывающий «знает» очистить стек после вызова функции, потому что компилятор знает соглашение о вызовах этой функции и генерирует необходимый код.

void __stdcall StdcallFunc() {}

void __cdecl CdeclFunc()
{
    // The compiler knows that StdcallFunc() uses the __stdcall
    // convention at this point, so it generates the proper binary
    // for stack cleanup.
    StdcallFunc();
}

Возможно несоответствие соглашению о вызовах, например:

LRESULT MyWndProc(HWND hwnd, UINT msg,
    WPARAM wParam, LPARAM lParam);
// ...
// Compiler usually complains but there's this cast here...
windowClass.lpfnWndProc = reinterpret_cast<WNDPROC>(&MyWndProc);

Так много примеров кода делают это неправильно, что это даже не смешно. Это должно быть так:

// CALLBACK is #define'd as __stdcall
LRESULT CALLBACK MyWndProc(HWND hwnd, UINT msg
    WPARAM wParam, LPARAM lParam);
// ...
windowClass.lpfnWndProc = &MyWndProc;

Однако, предполагая, что программист не игнорирует ошибки компилятора, компилятор сгенерирует код, необходимый для правильной очистки стека, поскольку он будет знать соглашения о вызовах задействованных функций.

(2) Оба способа должны работать. На самом деле это происходит довольно часто, по крайней мере, в коде, взаимодействующем с Windows API, поскольку __cdecl — это значение по умолчанию для программ C и C++ в соответствии с компилятором Visual C++ и функции WinAPI используют __stdcall соглашение.

(3) Между ними не должно быть реальной разницы в производительности.

В CDECL аргументы помещаются в стек в обратном порядке, вызывающая сторона очищает стек, а результат возвращается через реестр процессора (позже я буду называть его «регистр A»). В STDCALL есть одно отличие: вызывающий не очищает стек, а вызывающий.

Вы спрашиваете, какой из них быстрее. Ни один. Никто. Вы должны использовать нативное соглашение о вызовах столько, сколько сможете. Изменяйте соглашение только в том случае, если нет выхода, при использовании внешних библиотек, которые требуют использования определенного соглашения.

Кроме того, есть и другие соглашения, которые компилятор может выбрать по умолчанию, например, компилятор Visual C++ использует FASTCALL, который теоретически быстрее из-за более широкого использования регистров процессора.

Обычно вы должны дать правильную подпись соглашения о вызовах для функций обратного вызова, переданных в некоторую внешнюю библиотеку, т.е. обратный вызов qsort из библиотеки C должен быть CDECL (если компилятор по умолчанию использует другое соглашение, тогда мы должны пометить обратный вызов как CDECL) или различные обратные вызовы WinAPI должны быть быть STDCALL (весь WinAPI является STDCALL).

Другой обычный случай может быть, когда вы храните указатели на некоторые внешние функции, т.е. для создания указателя на функцию WinAPI ее определение типа должно быть помечено STDCALL.

А ниже пример, показывающий, как это делает компилятор:

/* 1. calling function in C++ */
i = Function(x, y, z);

/* 2. function body in C++ */
int Function(int a, int b, int c) { return a + b + c; }

CDECL:

/* 1. calling CDECL 'Function' in pseudo-assembler (similar to what the compiler outputs) */
push on the stack a copy of 'z', then a copy of 'y', then a copy of 'x'
call (jump to function body, after function is finished it will jump back here, the address where to jump back is in registers)
move contents of register A to 'i' variable
pop all from the stack that we have pushed (copy of x, y and z)

/* 2. CDECL 'Function' body in pseudo-assembler */
/* Now copies of 'a', 'b' and 'c' variables are pushed onto the stack */
copy 'a' (from stack) to register A
copy 'b' (from stack) to register B
add A and B, store result in A
copy 'c' (from stack) to register B
add A and B, store result in A
jump back to caller code (a, b and c still on the stack, the result is in register A)

СТАНДАРТНЫЙ ВЫЗОВ:

/* 1. calling STDCALL in pseudo-assembler (similar to what the compiler outputs) */
push on the stack a copy of 'z', then a copy of 'y', then a copy of 'x'
call
move contents of register A to 'i' variable

/* 2. STDCALL 'Function' body in pseaudo-assembler */
pop 'a' from stack to register A
pop 'b' from stack to register B
add A and B, store result in A
pop 'c' from stack to register B
add A and B, store result in A
jump back to caller code (a, b and c are no more on the stack, result in register A)

Я заметил сообщение, в котором говорится, что не имеет значения, звоните ли вы __stdcall из __cdecl или наоборот. Оно делает.

Причина: при __cdecl аргументы, которые передаются вызываемой функции, удаляются из стека вызывающей функцией, при __stdcall аргументы удаляются из стека вызываемой функцией. Если вы вызываете функцию __cdecl с __stdcall, стек вообще не очищается, поэтому в конечном итоге, когда __cdecl использует ссылку на основе стека для аргументов или адреса возврата, будут использоваться старые данные в текущем указателе стека. Если вы вызываете функцию __stdcall из функции __cdecl, функция __stdcall очищает аргументы в стеке, а затем функция __cdecl делает это снова, возможно, удаляя информацию, возвращаемую вызывающими функциями.

Соглашение Microsoft для C пытается обойти это, искажая имена. Перед функцией __cdecl стоит символ подчеркивания. Функция __stdcall имеет префикс с подчеркиванием и суффикс со знаком "@" и числом байтов, которые необходимо удалить. Например, __cdecl f(x) связано как _f, __stdcall f(int x) связано как _f@4, где sizeof(int) равно 4 байтам)

Если вам удастся обойти компоновщик, наслаждайтесь беспорядком отладки.

Я хочу улучшить ответ @adf88. Я чувствую, что псевдокод для STDCALL не отражает того, как это происходит на самом деле. «a», «b» и «c» не извлекаются из стека в теле функции. Вместо этого они извлекаются инструкцией ret (в этом случае будет использоваться ret 12), которая одним махом возвращается к вызывающей стороне и в то же время извлекает из стека «a», «b» и «c».

Вот моя версия, исправленная в соответствии с моим пониманием:

СТАНДАРТНЫЙ ЗВОНОК:

/* 1. calling STDCALL in pseudo-assembler (similar to what the compiler outputs) */
push on the stack a copy of 'z', then copy of 'y', then copy of 'x'
call
move contents of register A to 'i' variable


/* 2. STDCALL 'Function' body in pseaudo-assembler */
copy 'a' (from stack) to register A
copy 'b' (from stack) to register B
add A and B, store result in A
copy 'c' (from stack) to register B
add A and B, store result in A
jump back to caller code and at the same time pop 'a', 'b' and 'c' off the stack (a, b and
     c are removed from the stack in this step, result in register A)

Это указано в типе функции. Когда у вас есть указатель на функцию, предполагается, что это cdecl, если явно не stdcall. Это означает, что если вы получите указатель stdcall и указатель cdecl, вы не сможете их поменять местами. Два типа функций могут вызывать друг друга без проблем, он просто получает один тип, когда вы ожидаете другой. Что касается скорости, то они оба выполняют одни и те же роли, только в совсем немного другом месте, это действительно не имеет значения.

Вызывающий и вызываемый должны использовать одно и то же соглашение в момент вызова - только так это может надежно работать. И вызывающий, и вызываемый следуют заранее определенному протоколу — например, кто должен очистить стек. Если соглашения не совпадают, ваша программа ведет себя неопределенно - скорее всего, просто эффектно падает.

Это требуется только для сайта вызова — сам код вызова может быть функцией с любым соглашением о вызовах.

Вы не должны заметить никакой реальной разницы в производительности между этими соглашениями. Если это становится проблемой, вам обычно нужно делать меньше звонков — например, изменить алгоритм.

Эти вещи зависят от компилятора и платформы. Ни в стандарте C, ни в стандарте C++ ничего не говорится о соглашениях о вызовах, кроме extern "C" в C++.

как вызывающий абонент узнает, должен ли он освободить стек?

Вызывающий знает соглашение о вызове функции и соответствующим образом обрабатывает вызов.

Знает ли вызывающая сторона на месте вызова, является ли вызываемая функция функцией cdecl или функцией stdcall?

да.

Как это работает ?

Это часть объявления функции.

Как вызывающая сторона узнает, должен ли он освободить стек или нет?

Вызывающий знает соглашения о вызовах и может действовать соответственно.

Или это ответственность линкеров?

Нет, соглашение о вызовах является частью объявления функции, поэтому компилятор знает все, что ему нужно знать.

Если функция, объявленная как stdcall, вызывает функцию (которая имеет соглашение о вызовах как cdecl) или наоборот, будет ли это неуместным?

Нет. Почему?

В общем, можно ли сказать, какой вызов будет быстрее — cdecl или stdcall?

Я не знаю. Попробуй это.

а) Когда функция cdecl вызывается вызывающей стороной, как вызывающая сторона узнает, следует ли ей освободить стек?

Модификатор cdecl является частью прототипа функции (или типа указателя функции и т. д.), поэтому вызывающая сторона получает оттуда информацию и действует соответствующим образом.

б) Если функция, объявленная как stdcall, вызывает функцию (которая имеет соглашение о вызовах как cdecl) или наоборот, будет ли это неуместным?

Нет, все хорошо.

в) Вообще можно сказать, какой вызов будет быстрее - cdecl или stdcall?

В общем, я бы воздержался от подобных заявлений. Различие имеет значение, например. когда вы хотите использовать функции va_arg. Теоретически может быть так, что stdcall быстрее и генерирует меньший код, потому что позволяет комбинировать извлечение аргументов с извлечением локальных переменных, но OTOH с cdecl, вы тоже можете сделать то же самое, если вы умны.

Соглашения о вызовах, которые стремятся быть более быстрыми, обычно выполняют некоторую передачу регистров.

Соглашения о вызовах не имеют ничего общего с языками программирования C/C++, а скорее относятся к тому, как компилятор реализует данный язык. Если вы постоянно используете один и тот же компилятор, вам не нужно беспокоиться о соглашениях о вызовах.

Однако иногда нам нужно, чтобы двоичный код, скомпилированный разными компиляторами, корректно взаимодействовал. Когда мы это делаем, нам нужно определить что-то, называемое бинарным интерфейсом приложения (ABI). ABI определяет, как компилятор преобразует исходный код C/C++ в машинный код. Это будет включать в себя соглашения о вызовах, изменение имен и макет v-таблицы. cdelc и stdcall — это два разных соглашения о вызовах, обычно используемых на платформах x86.

Поместив информацию о соглашении о вызовах в заголовок исходного кода, компилятор будет знать, какой код необходимо сгенерировать для корректного взаимодействия с данным исполняемым файлом.