🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
AngelScript and Mac OS X
Author
Hi,
I just found AngelScript a few days ago and it looks absolutely amazing. Nice Syntax and a clean API. And no wrapper functions. Great.
I now have AngleScript up and running in AS_MAX_PORTABILITY mode but it looks like that some features are not available in that mode. Is it right that I have to write wrapper functions for all my C functions when I use the AS_MAX_PORTABILITY mode?
What other limitation do I have to expect if I use AngleScript in AS_MAX_PORTABILITY mode?
I'm just interested if anybody made some experiences with AngelScript on Mac OS X especially the PPC. Since it looks like that a as_callfunc_ppc.cpp file would be needed to use all the AngleScript features. Is that right?
By,
Martin
I'm really glad to hear that AngelScript works well on the Mac OS as well. I'll add that to the features page. :)
You've understood everything perfectly.
The AS_MAX_PORTABILITY mode was added because most compilers and platforms have different ways of implementing the various calling conventions that exist in C++. The only thing that is disabled with AS_MAX_PORTABILITY is the support for native calling conventions, thus all global functions and class methods must be registered through wrapper functions that follow the asCALL_GENERIC calling convention.
In order to be able to use AngelScript without AS_MAX_PORTABILITY on Mac OS X and PPC, the as_callfunc_ppc.cpp file must be implemented with all the necessary inline assembly routines. Since I do not have access to a system with Mac OS X I won't be able to do that implementation, but if you or someone else would be willing to do it for me I would be more than happy to accept that contribution.
If you decide to give it a shot, I suggest you start by implementing the asCALL_CDECL calling convention first, which is the easiest one. From that one it shouldn't be difficult to implement asCALL_CDECL_OBJLAST and asCALL_CDECL_OBJFIRST.
Regards,
Andreas
You've understood everything perfectly.
The AS_MAX_PORTABILITY mode was added because most compilers and platforms have different ways of implementing the various calling conventions that exist in C++. The only thing that is disabled with AS_MAX_PORTABILITY is the support for native calling conventions, thus all global functions and class methods must be registered through wrapper functions that follow the asCALL_GENERIC calling convention.
In order to be able to use AngelScript without AS_MAX_PORTABILITY on Mac OS X and PPC, the as_callfunc_ppc.cpp file must be implemented with all the necessary inline assembly routines. Since I do not have access to a system with Mac OS X I won't be able to do that implementation, but if you or someone else would be willing to do it for me I would be more than happy to accept that contribution.
If you decide to give it a shot, I suggest you start by implementing the asCALL_CDECL calling convention first, which is the easiest one. From that one it shouldn't be difficult to implement asCALL_CDECL_OBJLAST and asCALL_CDECL_OBJFIRST.
Regards,
Andreas
Author
Hi,
thanks for the fast reply. But please be careful with announcing OS X support because I only made a very small test. So I can't guarantee that everything works.
I've already found the documentation of the OS X Calling Conventions but to be honest I'm having serious problems with it since I have absolutely no experience with assembly.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Introduction.html
So I probably have to stay with the AS_MAX_PORTABILITY mode until someone else implements the as_callfunc_ppc.cpp file.
I've also tried the as_callfunc_x86.cpp file on my Intel iMac but it doesn't work. It causes a crash. So for the new Intel Macs the as_callfunc_x86.cpp file possibly also has to be adjusted.
What is the speed difference between native function calls and the generic function calls? Until now I more than happy with the generic speed. I made a small test against the Spidermonkey javascript engine (which I currently use in my app Cheetah3D ) and AngleScript in AS_MAX_PORTABILITY mode was 4-6 time faster than javascript. That is fantastic. But I'm sure the native calls are even faster.<br><br><br>By,<br>Martin
thanks for the fast reply. But please be careful with announcing OS X support because I only made a very small test. So I can't guarantee that everything works.
I've already found the documentation of the OS X Calling Conventions but to be honest I'm having serious problems with it since I have absolutely no experience with assembly.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Introduction.html
So I probably have to stay with the AS_MAX_PORTABILITY mode until someone else implements the as_callfunc_ppc.cpp file.
I've also tried the as_callfunc_x86.cpp file on my Intel iMac but it doesn't work. It causes a crash. So for the new Intel Macs the as_callfunc_x86.cpp file possibly also has to be adjusted.
What is the speed difference between native function calls and the generic function calls? Until now I more than happy with the generic speed. I made a small test against the Spidermonkey javascript engine (which I currently use in my app Cheetah3D ) and AngleScript in AS_MAX_PORTABILITY mode was 4-6 time faster than javascript. That is fantastic. But I'm sure the native calls are even faster.<br><br><br>By,<br>Martin
I'm sure your compiler for the Intel Mac is using different calling conventions than either MSVC and GNUC. This is likely why the as_callfunc_x86.cpp doesn't work directly out of the box for you.
I don't have any numbers to show how much faster native calls would be over the generic calls. But, considering that the native calls simply copy the parameters from the AngelScript stack to the native stack, whereas the generic calls need to manually copy each of the parameters via function calls with extra validation, the difference is quite big. Though, how much this difference affects the total performance is more difficult to preview. It may actually make a very small difference, especially if the number of bytecode instructions executed is large compared to the number of calls to application functions.
I'll save the calling convention article for future reference. I'm sure it will come in handy once I get at least a first version of the as_callfunc_ppc.cpp file.
I'm pleased to hear that AngelScript is faster than SpiderMonkey. Thanks for sharing that information with me. [grin]
Regards,
Andreas
I don't have any numbers to show how much faster native calls would be over the generic calls. But, considering that the native calls simply copy the parameters from the AngelScript stack to the native stack, whereas the generic calls need to manually copy each of the parameters via function calls with extra validation, the difference is quite big. Though, how much this difference affects the total performance is more difficult to preview. It may actually make a very small difference, especially if the number of bytecode instructions executed is large compared to the number of calls to application functions.
I'll save the calling convention article for future reference. I'm sure it will come in handy once I get at least a first version of the as_callfunc_ppc.cpp file.
I'm pleased to hear that AngelScript is faster than SpiderMonkey. Thanks for sharing that information with me. [grin]
Regards,
Andreas
Author
Hi,
Mac OS X is also using the gcc and I can also compile angelscript with the linux make file. But the engine crashes when I use it so there must be some more differences I can't figure out.
Now another problem. I've written a small C++ 3D Vector class. Which I use in AS_MAX_PORTABILITY mode. It contains the following functions
void csVec3D::set(asIScriptGeneric *gen)
{
vec[0]=gen->GetArgFloat(0);
vec[1]=gen->GetArgFloat(1);
vec[2]=gen->GetArgFloat(2);
}
and I registered the function to angelscript with
engine->RegisterObjectMethod("Vec3D", "void set(float,float,float)", asMETHOD(csVec3D,set),asCALL_GENERIC);
But that doesn't work. But if I write
set(asIScriptGeneric *gen)
{
csVec3D *v = (csVec3D*)gen->GetObject();
v->vec[0]=gen->GetArgFloat(0);
v->vec[1]=gen->GetArgFloat(1);
v->vec[2]=gen->GetArgFloat(2);
}
with
engine->RegisterObjectMethod("Vec3D", "void set(float,float,float)", asFUNCTION(set),asCALL_GENERIC);
it works.
So can I register object methods in in AS_MAX_PORTABILITY mode just with asFUNCTION() ?
By,
Martin
Mac OS X is also using the gcc and I can also compile angelscript with the linux make file. But the engine crashes when I use it so there must be some more differences I can't figure out.
Now another problem. I've written a small C++ 3D Vector class. Which I use in AS_MAX_PORTABILITY mode. It contains the following functions
void csVec3D::set(asIScriptGeneric *gen)
{
vec[0]=gen->GetArgFloat(0);
vec[1]=gen->GetArgFloat(1);
vec[2]=gen->GetArgFloat(2);
}
and I registered the function to angelscript with
engine->RegisterObjectMethod("Vec3D", "void set(float,float,float)", asMETHOD(csVec3D,set),asCALL_GENERIC);
But that doesn't work. But if I write
set(asIScriptGeneric *gen)
{
csVec3D *v = (csVec3D*)gen->GetObject();
v->vec[0]=gen->GetArgFloat(0);
v->vec[1]=gen->GetArgFloat(1);
v->vec[2]=gen->GetArgFloat(2);
}
with
engine->RegisterObjectMethod("Vec3D", "void set(float,float,float)", asFUNCTION(set),asCALL_GENERIC);
it works.
So can I register object methods in in AS_MAX_PORTABILITY mode just with asFUNCTION() ?
By,
Martin
Yes, you can. You just need to pass them a this pointer.
Or generic, whichever. In generic, I assume the this pointer will be carried along by the data structure somehow.
void foo(int i, object* this_pointer){ this_pointer->foo(i);}engine->RegisterObjectMethod("object","void foo(int)",asFUNCTION(foo),asCALL_CDECL_OBJLAST);Or generic, whichever. In generic, I assume the this pointer will be carried along by the data structure somehow.
Author
Quote: Original post by Deyja
Or generic, whichever. In generic, I assume the this pointer will be carried along by the data structure somehow.
Hi,
yes it looks like that in generic mode I have to use the pointer from the data structure. Since asCALL_CDECL_OBJLAST or asCALL_THISCALL are not available. I'm starting to understand how things work in generic mode. :)
By,
Martin
With asCALL_GENERIC the function must have the following signature:
It must be a global function, as class method pointers are not compatible between compilers.
Regards,
Andreas
void function(asIScriptGeneric *gen);It must be a global function, as class method pointers are not compatible between compilers.
Regards,
Andreas
Quote: It must be a global function
Remember that this does not mean the SCRIPTS have to see a global function.
Author
Hi,
thanks for your help. Now I have all the pieces together and was able to implement my first small class in generic mode with operator overloading, reference counting and all the other niceties Angelscript offers. :) And everything works perfectly.
I've checked out so many scripting engines (Phyton, Spidemonkey, LUA, Ruby, Ferit, ...) and this one is really the best. It's fast, light weight, easy to implement and uses a great syntax. Angelscript really shines in all these areas while other script engines only shine in one or two of them.
And it's becoming even better with the classes stuff in 2.5.1. Unbelievable WitchLord.
WitchLord do you think you would be able to implement the native function calls for OS X if you would have a Mac? Maybe I can help you out with a donation if it is just the missing Mac. ;-)
By,
Martin
thanks for your help. Now I have all the pieces together and was able to implement my first small class in generic mode with operator overloading, reference counting and all the other niceties Angelscript offers. :) And everything works perfectly.
I've checked out so many scripting engines (Phyton, Spidemonkey, LUA, Ruby, Ferit, ...) and this one is really the best. It's fast, light weight, easy to implement and uses a great syntax. Angelscript really shines in all these areas while other script engines only shine in one or two of them.
And it's becoming even better with the classes stuff in 2.5.1. Unbelievable WitchLord.
WitchLord do you think you would be able to implement the native function calls for OS X if you would have a Mac? Maybe I can help you out with a donation if it is just the missing Mac. ;-)
By,
Martin
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
