Advertisement

Native calling config for more BSD platforms

Started by October 13, 2010 12:18 PM
7 comments, last by WitchLord 14 years, 1 month ago
I finally got around to testing some additional BSD platforms, and they work just fine with the same config for FreeBSD:

#elif defined(__FreeBSD__) || defined(__DragonFly__) || defined(__OpenBSD__)


I haven't been able to test NetBSD, having issues getting it to work in qemu. However OpenBSD is based on it, and it should work fine. I will try to get it tested soon.

I'm also working on getting native calling working on Linux using ARM processors. So far TestScriptString fails, still running the tests with that one skipped to see what else (if any) fails.

Update: All other tests pass.
Thanks. I've added this configuration to the SVN (rev 725)

Any idea why the TestScriptString fails on Linux/ARM? What kind of error do you get?

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Advertisement
I don't get any error message, just says "One of the tests failed, see details above.". I just got home from work and plan to step through it with gdb.
I know the first place it fails is here (line 246):
	printOutput = "";	ExecuteString(engine, "print(\"a\" + 1.2)");	if( printOutput != "a1.2") fail = true;


Tomorrow I will have some time, and will be able to investigate some more.
Probably the constant 1.2 is formatted differently in the string for some reason.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

I've been busy and haven't gotten a chance to really see whats happening. When I get a some free time I will try to figure out why it's failing.
Advertisement
Quote: Original post by WitchLord
Probably the constant 1.2 is formatted differently in the string for some reason.


You are correct, the string contains:
a8.81144e-308

The next check in that test adds 1.2 + "a", that ends up being:
5.30084e-315a

Any idea as to why this would happen?
This test passes when using max portability So either it's a difference between the CPU that I'm compiling for, and what the native calling was tested on. Or this is a bug across all arm platforms that no one has noticed?

I assume it's the first one, but unfortunately I don't own a android or iphone to run the tests. I guess my next step will be to install the android emulator to see if the test passes on it.
It's possible that this scenario hasn't been tested on other ARM devices with Linux.

The functions that are being called are (from add_on/scriptstring):

static CScriptString *AddStringDouble(const CScriptString &str, double f){	char buf[100];	sprintf(buf, "%g", f);	return new CScriptString(str.buffer + buf);}static void AddStringDouble_Generic(asIScriptGeneric *gen){	CScriptString *str = (CScriptString*)gen->GetObject();	double f = gen->GetArgDouble(0);	CScriptString *out = AddStringDouble(*str, f);	gen->SetReturnAddress(out);}static CScriptString *AddDoubleString(double f, const CScriptString &str){	char buf[100];	sprintf(buf, "%g", f);	return new CScriptString(buf + str.buffer);}static void AddDoubleString_Generic(asIScriptGeneric *gen){	double f = gen->GetArgDouble(0);	CScriptString *str = (CScriptString*)gen->GetObject();	CScriptString *out = AddDoubleString(f, *str);	gen->SetReturnAddress(out);}


As you can see the generic function is just a wrapper for the native function.

The problem seems to be with arguments of the type double in as_callfunc_arm.cpp or as_callfunc_arm_GCC.S.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

This topic is closed to new replies.

Advertisement