stdcall und cdecl

Es gibt (unter anderem) zwei Arten von Aufrufkonventionen – Standardanruf und cdekl. Ich habe ein paar Fragen dazu:

1. Woher weiß ein Aufrufer, wenn eine cdecl-Funktion aufgerufen wird, ob er den Stack freigeben soll? Weiß der Aufrufer auf der Aufrufseite, ob die aufgerufene Funktion eine cdecl- oder eine stdcall-Funktion ist? Wie funktioniert es ? Woher weiß der Anrufer, ob er den Stack freigeben soll oder nicht? Oder ist es die Verantwortung des Linkers?
2. Wenn eine Funktion, die als stdcall deklariert ist, eine Funktion aufruft (die eine Aufrufkonvention als cdecl hat) oder umgekehrt, wäre dies unangemessen?
3. Können wir im Allgemeinen sagen, welcher Anruf schneller sein wird – cdecl oder stdcall ?

Raymond Chen gibt einen schönen Überblick darüber, was __stdcall und __cdecl tut.

(1) Der Aufrufer “weiß”, dass er den Stack nach dem Aufruf einer Funktion bereinigen muss, da der Compiler die Aufrufkonvention dieser Funktion kennt und den erforderlichen Code generiert.

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();
}

Es ist möglich, dass die Aufrufkonvention nicht übereinstimmtso was:

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);

So viele Codebeispiele machen das falsch, dass es nicht einmal lustig ist. So soll es sein:

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

Unter der Annahme, dass der Programmierer Compilerfehler nicht ignoriert, generiert der Compiler jedoch den Code, der zum ordnungsgemäßen Bereinigen des Stapels erforderlich ist, da er die Aufrufkonventionen der beteiligten Funktionen kennt.

(2) Beide Wege sollten funktionieren. Tatsächlich passiert dies zumindest in Code, der mit der Windows-API interagiert, ziemlich häufig, weil __cdecl ist der Standardwert für C- und C++-Programme gemäß dem Visual C++-Compiler und Die WinAPI-Funktionen verwenden die __stdcall Konvention.

(3) Es sollte keinen wirklichen Leistungsunterschied zwischen den beiden geben.

In CDECL werden Argumente in umgekehrter Reihenfolge auf den Stapel geschoben, der Aufrufer löscht den Stapel und das Ergebnis wird über die Prozessorregistrierung zurückgegeben (später werde ich es “Register A” nennen). Bei STDCALL gibt es einen Unterschied, der Aufrufer löscht den Stapel nicht, der Angerufene tut es.

Sie fragen, welches schneller ist. Niemand. Sie sollten so lange wie möglich die native Aufrufkonvention verwenden. Ändern Sie die Konvention nur, wenn es keinen Ausweg gibt, wenn Sie externe Bibliotheken verwenden, die die Verwendung einer bestimmten Konvention erfordern.

Außerdem gibt es andere Konventionen, die der Compiler als Standard auswählen kann, dh der Visual C++-Compiler verwendet FASTCALL, was theoretisch schneller ist, da Prozessorregister umfassender verwendet werden.

Normalerweise müssen Sie Callback-Funktionen, die an eine externe Bibliothek übergeben werden, z. B. Callback to, eine ordnungsgemäße Aufrufkonventionssignatur geben qsort aus der C-Bibliothek muss CDECL sein (wenn der Compiler standardmäßig eine andere Konvention verwendet, müssen wir den Rückruf als CDECL markieren) oder verschiedene WinAPI-Rückrufe müssen STDCALL sein (die gesamte WinAPI ist STDCALL).

Ein anderer üblicher Fall kann sein, wenn Sie Zeiger auf einige externe Funktionen speichern, dh um einen Zeiger auf eine WinAPI-Funktion zu erstellen, muss ihre Typdefinition mit STDCALL gekennzeichnet sein.

Und unten ist ein Beispiel, das zeigt, wie der Compiler das macht:

/* 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)

STDCALL:

/* 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)

Mir ist ein Posting aufgefallen, das besagt, dass es egal ist, ob man einen anruft __stdcall von einem __cdecl oder umgekehrt. Es tut.

Der Grund: mit __cdecl Die Argumente, die an die aufgerufenen Funktionen übergeben werden, werden von der aufrufenden Funktion aus dem Stack entfernt, in __stdcall, werden die Argumente von der aufgerufenen Funktion aus dem Stack entfernt. Wenn Sie a anrufen __cdecl Funktion mit a __stdcallder Stapel wird überhaupt nicht aufgeräumt, also wenn die __cdecl verwendet eine stapelbasierte Referenz für Argumente, oder die Rücksprungadresse verwendet die alten Daten am aktuellen Stapelzeiger. Wenn Sie a anrufen __stdcall Funktion von a __cdecldas __stdcall Funktion bereinigt die Argumente auf dem Stack und dann die __cdecl Funktion wiederholt dies und entfernt möglicherweise die Rückgabeinformationen der aufrufenden Funktionen.

Die Microsoft-Konvention für C versucht dies zu umgehen, indem sie die Namen verstümmelt. EIN __cdecl Der Funktion wird ein Unterstrich vorangestellt. EIN __stdcall Funktionspräfixe mit einem Unterstrich und einem angehängten At-Zeichen „@“ und der Anzahl der zu entfernenden Bytes. Z.B __cdecl f(x) ist verknüpft als _f, __stdcall f(int x) ist verlinkt als _f@4 wo sizeof(int) ist 4 Byte)

Wenn Sie es schaffen, den Linker zu umgehen, genießen Sie das Debugging-Chaos.

Ich möchte die Antwort von @ adf88 verbessern. Ich habe das Gefühl, dass der Pseudocode für STDCALL nicht die Art und Weise widerspiegelt, wie es in der Realität passiert. ‘a’, ‘b’ und ‘c’ werden nicht aus dem Stapel im Funktionsrumpf entfernt. Stattdessen werden sie von der geknallt ret Anweisung (ret 12 würde in diesem Fall verwendet werden), der auf einen Schlag zum Aufrufer zurückspringt und gleichzeitig ‘a’, ‘b’ und ‘c’ aus dem Stapel holt.

Hier ist meine nach meinem Verständnis korrigierte Version:

STDCALL:

/* 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)

Es ist im Funktionstyp angegeben. Wenn Sie einen Funktionszeiger haben, wird davon ausgegangen, dass er cdecl ist, wenn nicht explizit stdcall. Das bedeutet, dass Sie einen stdcall-Zeiger und einen cdecl-Zeiger nicht austauschen können. Die beiden Funktionstypen können sich ohne Probleme gegenseitig aufrufen, es wird nur ein Typ abgerufen, wenn Sie den anderen erwarten. Was die Geschwindigkeit angeht, spielen beide die gleichen Rollen, nur an einem ganz geringfügig anderen Ort, das ist wirklich irrelevant.

Der Aufrufer und der Angerufene müssen am Aufrufpunkt dieselbe Konvention verwenden – nur so könnte es zuverlässig funktionieren. Sowohl der Aufrufer als auch der Angerufene folgen einem vordefinierten Protokoll – zum Beispiel, wer den Stack aufräumen muss. Wenn Konventionen nicht übereinstimmen, läuft Ihr Programm auf undefiniertes Verhalten – wahrscheinlich stürzt es einfach spektakulär ab.

Dies ist nur pro Aufrufstelle erforderlich – der Aufrufcode selbst kann eine Funktion mit jeder Aufrufkonvention sein.

Sie sollten keinen wirklichen Leistungsunterschied zwischen diesen Konventionen bemerken. Wenn das ein Problem wird, müssen Sie normalerweise weniger Anrufe tätigen – zum Beispiel den Algorithmus ändern.

Diese Dinge sind Compiler- und Plattform-spezifisch. Weder der C- noch der C++-Standard sagen etwas über Aufrufkonventionen aus, außer für extern "C" in C++.

Wie weiß ein Anrufer, ob er den Stack freigeben soll?

Der Aufrufer kennt die Aufrufkonvention der Funktion und behandelt den Aufruf entsprechend.

Weiß der Aufrufer auf der Aufrufseite, ob die aufgerufene Funktion eine cdecl- oder eine stdcall-Funktion ist?

Ja.

Wie funktioniert es ?

Sie ist Teil der Funktionsdeklaration.

Woher weiß der Anrufer, ob er den Stack freigeben soll oder nicht?

Der Anrufer kennt die Anrufkonventionen und kann entsprechend handeln.

Oder ist es die Verantwortung des Linkers?

Nein, die Aufrufkonvention ist Teil der Deklaration einer Funktion, sodass der Compiler alles weiß, was er wissen muss.

Wenn eine Funktion, die als stdcall deklariert ist, eine Funktion aufruft (die eine Aufrufkonvention als cdecl hat) oder umgekehrt, wäre dies unangemessen?

Nein. Warum sollte es?

Können wir im Allgemeinen sagen, welcher Anruf schneller sein wird – cdecl oder stdcall ?

Ich weiß nicht. Probier es aus.