64-bit calling conventions
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7

Thread: 64-bit calling conventions

  1. #1
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,242

    64-bit calling conventions

    I'm aware that Microsoft's 64-bit compilers now have only one calling convention. So __cdecl, __stdcall, __fastcall and (apparently) even __thiscall are now all equivalent.

    So what happens if I'm building some older code which explicitly declared a calling convention. If the compiler encounters a symbol that's explicitly declared as __cdecl, __stdcall or whatever is that regarded as an error or does it just get ignored?
    "A problem well stated is a problem half solved. - Charles F. Kettering

  2. #2
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,878

    Re: 64-bit calling conventions

    64bit code on MS only has "__fastcall"

    older compiled code is irrelevant, as it won't be 64bit code. the MS compilers never supported anything else.

    if you talk about using object code that was created with another compiler and you want to link it with MSVC code... Well that'll only work if that other compiler also used the MS methodology (which is also used for the Windows API calls btw).

    if that other compiler doesn't do it the MS __fastcall way... "anything could happen".


    if you're merely talking about compiling old C/C++ sources...
    the other conventions are ignored at compile time. this is mentioned in the help for those calling conventions. for __cdecl for instance:
    "On Itanium Processor Family (IPF) and x64 processors, __cdecl is accepted and ignoredby the compiler; on IPF, by convention, parameters are passed in register. "

  3. #3
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,242

    Re: 64-bit calling conventions

    Yes, I was talking about compiling older sources. I just wanted to make sure that if I encountered a header file like this (which I find to be reasonably common) the lines #define THE_DLL_CALLTYPE __stdcall aren't going to spoil a 64-bit build:-

    Code:
    #ifdef BUILDING_SOME_DLL
          #define THE_DLL_API  __declspec(dllexport)
          #define THE_DLL_CALLTYPE  __stdcall
    #else
          #define THE_DLL_API  __declspec(dllimport)
          #define THE_DLL_CALLTYPE  __stdcall
    #endif
    
    THE_DLL_API void THE_DLL_CALLTYPE somefunc(void);
    Also do you happen to know what the situation is for the gcc compiler? i.e. does it also use one common type for 64-bit builds or does it continue to differentiate between cdecl / fastcall etc? If my code needs to be cross-platform I guess I should find this out.!
    "A problem well stated is a problem half solved. - Charles F. Kettering

  4. #4
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    5,971

    Re: 64-bit calling conventions

    Best regards,
    Igor

  5. #5
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,242

    Re: 64-bit calling conventions

    Thanks Igor. What's interesting (if I'm reading the table correctly) is that Microsoft's x64 calling convention isn't (quite) __fastcall because __fastcall asks the callee to clean up the stack whereas the caller does the cleanup for MS x64. Interesting....
    "A problem well stated is a problem half solved. - Charles F. Kettering

  6. #6
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    5,971

    Re: 64-bit calling conventions

    See MSDN for the details behind the design: Overview of x64 Calling Conventions
    Best regards,
    Igor

  7. #7
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,878

    Re: 64-bit calling conventions

    calling conventions in dlls "don"t matter". That is to say, they matter only in that the caller needs to use the same method as what the dll was designed for, but other than that, you could use any method (even custom ones) in so far as caller and callee agree.

    __stdcall for dll's is popular because that's the system that is most commonly used in other languages. So if you wanted to use a dll from basic, pascal, ... then __stdcall makes that possible. the other calling conventions will either not work or will need a thunk written in assembly. So __stdcall (formerly called __pascal) is the go-to for libs and dll's which you want to be accessible from more than just C/C++.

    With x64, MS decided that having multiple conventions only makes things harder, so they opted for a single convention that tries to combine the best of everything.
    So they took __fastcall as a base (pass by register for performance/size)
    make it allow for variable arguments (the perk of __cdecl) by having the caller clean up the stack
    in addition they decided that some registers would be considered preserved and others volatile.
    And by making this the convention for the Win api. Any language that wants to work on windows would have to support the method anyway. So multiple conventions to support other languages isn't a requirement.

    The __stdcall perk which is smaller code by not requiring each caller to clean up the stack but make the callee be responsible isn't usefull because that means you can't have variable arguments.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center