NO

Author Topic: About calling conventions  (Read 4029 times)

bytecount

  • Guest
About calling conventions
« on: February 26, 2013, 02:03:26 AM »
I'm learning C and I am trying to understand calling conventions. I setup a win32 console application and set it to the C99 standard. The project is automatically set to __cdecl. I looked this up on wikipedia and found out a little about what calling conventions are. The usual calling conventions are __cdecl, __stdcall and __fastcall. There was not much information on what the programmers part is in this, so I tried selecting __stdcall. It automatically jumped back to __cdecl. I am not sure I understand why I am not allowed to select __stdcall. Could someone please explain this to me?

I have one other question about this.  The wikipedia article http://en.wikipedia.org/wiki/X86_calling_conventions states that the fastcall implementation is compiler vendor dependent. What does this mean for Pelles C (How is it implemented?). This brings me back to my first question. What determines if we can use a calling convention (if not the compiler vendor) since I also can't switch to __fastcall.

CLR

  • Guest
Re: About calling conventions
« Reply #1 on: February 26, 2013, 02:39:47 AM »
You can read this http://unixwiz.net/techtips/win32-callconv-asm.html
and this http://unixwiz.net/techtips/win32-callconv.html

Excerpt:

 In most cases, it makes no difference either which calling convention is used by default throughout the program, or what the convention is on any particular function, but there are a few exceptions of note when using other than __cdecl for the default.

    The function main() (and the wide version wmain()) must always be __cdecl.
    The function WinMain() — the starting point for GUI programs — is always __stdcall, though this is pre-declared by the <windows.h> include file to make this more or less automatic.

    Variadic ("printf-like") functions are __cdecl even if declared otherwise (e.g., the calling convention keyword is ignored). We are surprised that the compiler does not issue a warning against this misuse:

        int __stdcall myprintf(const char *fmt, ...); // it's really __cdecl


bytecount

  • Guest
Re: About calling conventions
« Reply #2 on: February 26, 2013, 05:07:44 AM »
It's starting to make more sense now. I will look over the links.

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: About calling conventions
« Reply #3 on: February 26, 2013, 05:08:06 AM »
This brings me back to my first question. What determines if we can use a calling convention (if not the compiler vendor) since I also can't switch to __fastcall.
Most importantly, the API//library you are linking against. And for Win32, the default is cdecl...

For learning C, the calling convention being used should be of no relevance, unless you explicitly need to change this for parts of your program in order to link for example against a 3rd party library. You just might distract yourself too much from your actual goal of learning C and wander off in the depth of Windows (or generally speaking, OS dependent) programming...

Ralf

CommonTater

  • Guest
Re: About calling conventions
« Reply #4 on: February 26, 2013, 02:10:26 PM »
I'm learning C and I am trying to understand calling conventions.

It's pretty simple really ... You will find lots of description of these calling conventions and how they work. The probably-too-obvious part they never state is that when a function is written in a given calling convention, that is how you have to call it if you want it to work.
 
Most of the C library is _cdecl ... which is why your projects default to that.
 
Windows and it's 32bit API is _stdcall ... If you check "Enable Microsoft extensions" in your settings you can then select that.
 
x64 code uses _fastcall ... and that will be your only choice for 64 bit projects.
 
Each of these conventions has a hidden "decoration" that tells the compiler how to call it, so pretty much as long as you get your entry points correct, the rest is automatic. 
 
As already pointed out, the guts of how this works is not meet for beginners. There are no major advantages of one over another. The best thing is to simply "Call em as they wrote em" and get on with the actual business of learning the language.  There will be lots of time to learn the finer points later...
 
 

Offline Vortex

  • Member
  • *
  • Posts: 797
    • http://www.vortex.masmcode.com
Re: About calling conventions
« Reply #5 on: February 26, 2013, 07:53:59 PM »
Hi bytecount,

Agner Fog wrote a very nice document on calling conventions :

Quote
Calling conventions for different C++ compilers and operating systems

This document contains details about data representation, function calling conventions, register usage conventions, name mangling schemes, etc. for many different C++ compilers and operating systems. Discusses compatibilities and incompatibilities between different C++ compilers. Includes information that is not covered by the official Application Binary Interface standards (ABI's). The information provided here is based on my own research and therefore descriptive rather than normative. Intended as a source of reference for programmers who want to make function libraries compatible with multiple compilers or operating systems and for makers of compilers and other development tools who want their tools to be compatible with existing tools.
 
File name: calling_conventions.pdf, size: 415677, last modified: 2012-Feb-29

http://agner.org/optimize/calling_conventions.pdf

http://agner.org/optimize/
Code it... That's all...