64 bit calling conventions run fine on 32 bit?

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?
Last edited on
is used only in 64 and 86 bit processors
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
only applies to the x86 architecture
[sic]
https://msdn.microsoft.com/en-us/library/6xa169sk.aspx

Which means it should only work on CPUs with 32-bit instruction sets.
Last edited on
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?
Last edited on
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.
Last edited on
I believe you may be trying to make all this harder than it is stav.

yeah you're probably right
i'm just gonna let the compiler handle the calling conventions

thanks alot to both of u :)
Topic archived. No new replies allowed.