AngelScript and Mac OS X

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

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 &#106avascript engine (which I currently use in my app Cheetah3D ) and AngleScript in AS_MAX_PORTABILITY mode was 4-6 time faster than &#106avascript. 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

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

Yes, you can. You just need to pass them a this pointer.

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.

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:

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.

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

Thank you very much for those complimenting words. Please tell everyone you know. [wink]

Of course, if I did have a Mac I would definitely be able to implement the native calling conventions. I would definitely appreciate a donation. [grin]

Though, I have to be honest with you. I would only buy a Mac if I had lots, and lots of money for which I had no better use. So unless I actually receive the Mac itself as a donation, I probably won't be going out buying one myself.

What I really want to buy right now, is a 64bit system. So that I can get the library working on that. If you made a donation it would get me a step closer to that purchase.

Regards,
Andreas

Quote:

Original post by WitchLord Thank you very much for those complimenting words. Please tell everyone you know. [wink]

I will.

Quote:

Original post by WitchLord Of course, if I did have a Mac I would definitely be able to implement the native calling conventions. I would definitely appreciate a donation. [grin]

That's what I wanted to hear. [grin]

Quote:

Original post by WitchLord So unless I actually receive the Mac itself as a donation, I probably won't be going out buying one myself.

That's actually what I thought about. So I can start saving money. [wink] But it might take some time since I first want to wait for the Intel Mac mini which allows the development and testing of Intel and PPC (via Rosetta emulator) code.

I don't know which ABI the three next generation game consoles (XBox 360, Playstation 3 and Nintendo) use since that also depends on the OS. But they all use the PPC processors. So maybe you could get compatibility to some of the new consoles for free.

Quote:

Original post by WitchLord What I really want to buy right now, is a 64bit system. So that I can get the library working on that. If you made a donation it would get me a step closer to that purchase.

You can probably understand that my personal interest is not so big for a 64 bit version yet. But I'm sure many people would appreciate it very much.


By,
Martin

I'd appreciate whatever donation you make. [smile]

The Mac Mini is a very cool machine that I would definitely love to be an owner of (though not enough to spend my money on it [wink]). I remember reading about it when it first arrived and thinking to myself how cool it would be to have one of those.

Hi,
so I guess we have a deal. I will buy you a Mac (once the Intel Mac minis become available, but it will happen this year for sure) and you make Angelscript run natively on OS X.
I've also found lots of additional ABI documentation, so I'm sure it won't be a problem for you to translate the necessary functions.

Meanwhile I use the excellent generic mode. And once the native function calls are available I can switch easily the performance critical functions (vector math) to native calls.

By,
Martin

Yayy!!!

Will you still buy the Mac for me, even if someone implements native support for PPC before the Intel Mac Mini comes out? *crossing my fingers* [wink]

Actually, when Code::Blocks started using AngelScript internally the AngelScript userbase increased immensely. There are even people using PPC, so it is quite possible that you may not actually have to wait until I have a Mac to get the native support. Let's hope someone with experience is willing to spend the time to do the necessary port.

Regards,
Andreas

Hi,
it would be nice if someone else makes the Mac port first. The earlier the better. Nevertheless I'm still convinced that it would be very positive for the Mac OS X support if the main developer has access to a Mac. So I would donate the Mac nevertheless. Now it's up to Apple to release the Intel Mac minis soon.

But I think PPC != MacOS compatibility since the native Windows Intel calls don't work on my Intel iMac too. That's why I'm not sure if a Linux PPC port would actually work on MacOS X. The ABI is probably different. I guess it has something to do that Mac apps are Mach-O files.

By,
Martin

You're right, a Linux PPC port wouldn't automatically add support for Mac OS X, but it would be a step closer. The native calling conventions differ between compilers on the same platform as well, at least on Windows. Perhaps on the Mac the compilers are more standardized in regards to calling conventions.

But even with a Linux PPC port I would at least have a notion of how the inline assembly would look like.

On a related note, I have recently attempted a port for my game Atomixer with the help of some Mac savvy friends but hit a wall due to lack of a Mac version of Angelscript. Unfortunately, the AS engine is integrated both in my game code and my engine code. Thus, compiling with MAX_PORTABILITY and switching both engine and actual game bindings to the scripts using asCALL_GENERIC is not an option I'd like to pursue. I will probably hold back on the Mac port until the Mac/PPC calls are implemented.

Perhaps your Mac savvy friends could help with the port?

What's needed for the port is an implementation of as_callfunc_x86.cpp for the Mac OS X platform. It would require knowledge of inline assembly, but not too much as most of the actual assembly code could be taken from disassemblies of compiled code.

While you're here, I might as well congratulate you on a great game. I meant to send you a note personally, but never got to it. I have played the game though, and I must say that I like it quite a bit. Everything worked smoothly and with great graphics. Please make more games with this quality. [wink]

Regards,
Andreas

Hi Andreas,

I'd like to avoid burdening them with this issue as it might consume too much of their time especially since they would need to familiarise with AS first. Perhaps the task could be simplified if you could provide a copy of "as_callfunc_x86.cpp" modified to include the code required to support Mac OS X but with a placeholder for the assembly code itself. I would have to ask them first though! :)

Thanks for your comments re Atomixer. I admit that using AS within the game was almost an overkill given its relative simplicity compared to larger commercial games. Still, I have found it handy for anything from simple configuration files to actual game logic. The the rules of the two game modes are implemented using scipts so in theory I can add more game modes simply by adding scripts with different rules for level completion and winning the game. I am glad to hear you liked Atomixer and hope that it contributes to the popularity of Angelscript.