so i wrote this basic program that just calls a functions with the "fastcall" calling convention which is used only in 64 and 86 bit processors
(if what i've learned so far is correct)
1 2 3 4 5 6 7 8 9 10 11 12
int __fastcall somefunc()
{
return 1;
}
int main()
{
int c = somefunc();
return 0;
}
now i press f11 in visual studio and it builds just fine, with no errors.
i then tried changing the build configuration to 32bit and pressed f11 to see what would happen
but to my surprise it build successfully with no errors?
but shouldn't i get an error when the 32bit compiler see's the 64/86 bit fastcall convention?
shouldn't i get an error when the 32bit compiler see's the 64/86 bit fastcall convention?
There is no "86" bit instruction set. x86 refers to a family of processor architectures based on the Intel 8086 CPU. "x86" has become a defacto name for CPUs with 32-bit instruction sets.
Also, MSDN says that __fastcall is a calling convention that
ah ok
but what will happen if i try to run a program that uses a x86 architecture calling convention on a processor that doesn't use that architecture?
(like an arm processor for example, because they dont use the x86 architecture, right?)
i assume they'll just crash or something right?
but how do i then go about making sure my program will run on any processor?
do i just have to use different compilers to make different versions for various processor architectures?
and just remove the calling conventions from the non x86 architecture processors?
I believe you may be trying to make all this harder than it is stav. I've been inter-operating with the 32 bit verses 64 bit compilers for years and I have to say the amount of work Microsoft put into making this seamless is truly amazing. Perhaps someone here more knowledgible than I can jump in if I'm mis-stating something, but nearly all, if not all the Windows Api functions are defined as __stdcall. I believe when using a 64 bit compiler there is a conditional define in the headers to just define __stdcall as nothing so it is essentially removed, and so the function would default to just __fastcall for 64 bit. The same code compiled for 32 bit would be treated as __stdcall. In that way you can code completely processor agnostic.
The only issue I ever had with this was when I was converting some PowerBASIC code to C++. The default calling convention for PowerBASIC is __stdcall. I converted the code and it worked perfectly in 64 bit but crashed in 32 bit. What I had done was forget to specify __stdcall in the code, so the 32 bit compile defaulted to __cdecl and crashed. The 64 bit didn't need the forgotten __stdcall because it was #defined away anyhow. Interesting, huh? Lost several hours on that one.