Re: C/C++ calling convention
On Aug 26, 6:55 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:ef1763bb-d598-49f6-8ab1-7f32a22f6f50@k10g2000yqa.googlegroups.com...
On Aug 26, 12:25 am, "BGB / cr88192" <cr88...@hotmail.com> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:13533014-dba5-456f-a857-5f2ef2b676f0@l6g2000yqb.googlegroups.com...
On Aug 25, 3:44 pm, Goran Pusic <gor...@cse-semaphore.com> wrote:
On Aug 25, 4:18 pm, Stanis=B3aw Findeisen <nore...@eisenbits.com> wro=
te:
[...]
Any compiler provides you with a way to specify what calling
convention you want from a list of calling conventions chosen by that
compiler (look for e.g. __cdecl).
<--
On most machines, there is only one reasonable way to pass
arguments when calling a function, and most compilers do not
need or have extensions to specify many different calling
conventions---they use the standard ``extern "language"''.
-->
well, if one excludes 32 bit Windows, where in practice 4 calling
conventions are commonly used:
cdecl; stdcall; fastcall; and thiscall (modified cdecl).
<--
By "most machines", I meant most types of machines. Windows is
a bit of an exception, although even here, it's only really an
exception when using VC++, who decided not to use the standard
mechanism. (cdecl and stdcall resolve to ``extern "C"'' and
``extern "Pascal"'', I think. And thiscall is an extension of
cdecl, only relevant for ``extern "C++"''. The language also
allows a compiler to define something like ``extern "Fast"'',
although why one would use a slow call when a fast one is
available is beyond me.)
-->
yeah.
most compilers I have seen have used the "__callconv" type keywords,
The only one I've seen which does this is the Microsoft
compiler.
although granted my experience is mostly limited to Windows (where this
convention would likely be default as MS uses it),
Most of my experience is Unix. I've only really aborded Windows
in the last year (and only with the Visual Studios).
and Linux (where generally there is only a single calling
convention in use, hence no real need to use it...).
I've not seen this under Linux. G++ does have a __attribute__
keyword, but this covers a lot more than linkage. It allows
declaring, for example, that a function never returns, or is
pure. Things so useful for the optimizer that the next version
of the standard will provide a similar mechanism.
Under Windows, this technique is used for things like dllimport
and dllexport as well (since it is necessary), and on Intel
processors, there is an attribute cdecl, which will override any
compile line option telling the compiler to use a different
calling convention (which no one in their right mind would use,
since it means that you can't link with any number of other
programs---although by all rights, the "optional" form should be
the default for C++).
this notation makes a little more sense IMO than the 'extern
"lang" ' notation in many cases, as it allows defining the
calling convention of function pointers, ... which the former
can't do effectively,
Why not? Function pointers do have language binding as part of
their type; you can't assign the address of a C++ function to a
function pointer with ``extern "C"'' in its type. (At least two
compilers are broken in this regard, however, and don't enforce
the rule: Microsoft VC++ and g++.)
however, the 'extern "lang" ' notation does have the
usefulness that it can be applied to an entire block of
definitions, rather than having to be endlessly repeated for
each declaration.
hence:
void (__stdcall *foo)(int x, double y);
and:
extern "C"
{
...
}
Or also:
extern "C" void foo(void* (*)(void*));
Which can only be called with a pointer to an ``extern "C"''
function.
in most cases, fastcall can be ignored (it is almost never
used for external linkage AFAICT), and thiscall can simply be
regarded as a special case of cdecl.
this is a major reason for modifier tags like WINAPI and
similar: they wrap the calling convention keywords.
on 64-bit Windows, there is a single calling convention (Win64);
on 64-bit Linux and OSX, there is a single calling convention (AMD64);
<--
As is the case under Solaris, HP/UX and AIX. And probably every
other system around.
-->
most non-Windows systems on x86-64 AFAIK use AMD64.
Only those running on AMD 64 bit hardware and the Intel clones
of them. Sparc has completely different conventions, as does
HP/UX on HP's PA based machines. IIRC, 32 bit Linux uses an
adaptation of Intel's Itanium 64 bit conventions.
admittedly, I personally like Win64's design a little more, as
AMD64 seems a bit complicated and over-engineered and likely
to actually reduce performance slightly in common use cases vs
Win64's design.
on 32-bit Linux, in practice pretty much everyone just uses
cdecl...
<--
On 32-bit Linux, I've never used anything.
-->
on 32-bit Linux, there is only a single calling convention in
single use, so no one needs to... doesn't mean the calling
convention is not there, only that it is not needed to specify
it.
Rather that the default is universal. I think the difference is
that under Windows, the default may be something like cdecl, but
many (most) of the OS interface functions use something else.
IIRC, MS-DOS was a mess though, with many compilers doing
things differently, so code from one compiler would not
normally link correctly with code produced by another.
<--
Yes and no. All of the C compilers I tried did the same thing.
All of the C++ compilers were different. But that's the case
almost universally today as well.
-->
there were differences. many C compilers used OMF (as the
object format), and some used others (including COFF, but this
was typically for DPMI-based compilers, as well as I think I
remember there being 32-bit OMF, ...); there were a few others
as well IIRC.
although, all this was long ago, and my memory is faded.
Most of the compilers I used under MS-DOS used Microsoft's
object format, which was originally based on Intel's. The one
exception, Intel's own compiler, used the Intel format, but
could link the Microsoft object format as well.
[...]
but, Windows and x86 (or Windows and x64 / x86-64) represent
the vast majority of total systems (desktop and laptop at
least) in use...
You notice that you have to qualify it. I'd be surprised if
there were more Windows than Symbian or VxWorks, in terms of
numbers of machines running the system. And of course, Unix
still dominates servers and large scale embedded systems
(network management, telecoms, etc.).
Linux and OSX (on x86 or x86-64) are most of the rest.
ARM and PPC are used in many embedded systems. (not sure the
OS popularity distribution for embedded systems, from what I
have seen I would guess: Linux, FreeDOS, and various
proprietary OS's...).
VxWorks dominates, I think. Except on portable phones, where
Symbian dominates.
most other architectures and operating systems can be largely
safely ignored...
Unless you're doing something important: a large scale server,
network management, etc. I've done far more work under Solaris
than under Windows.
--
James Kanze