Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Andreas Jonsson

Member Since 26 Mar 2000
Offline Last Active Yesterday, 12:56 PM

#5006588 Angelscript with Objective-C

Posted by Andreas Jonsson on 03 December 2012 - 07:23 AM

After reading up a little on Objective-C and Objective-C++ I understand that it is not possible to bind Objective-C class methods directly with AngelScript. Even if it is possible to somehow take the address of an Objective-C class method the way Objective-C works is completely different from C++. In Objective-C communication between classes are done through messaging and not direct calls of the class methods as is done in C++.

However, as Objective-C++ can include C++ code in the same program it should be straightforward to write global proxy functions that bridge the AngelScript to Objective-C interface. If you're using Objective-C then you will have to use the C interface for AngelScript, as Objective-C don't understand C++ code.

Regards,
Andreas


#5006331 Marmalade: Angelscript runs fine on x86, crashes on ARM

Posted by Andreas Jonsson on 02 December 2012 - 12:01 PM

From loboWu's makefile I see that exceptions are enabled like this:

#!/usr/bin/env mkb


options
{
   enable-exceptions=1
   lib
   module_path="../../source"
}

Did you try defining AS_ARM directly? Like loboWu does in his makefile? What was the result of that?


#5006299 Marmalade: Angelscript runs fine on x86, crashes on ARM

Posted by Andreas Jonsson on 02 December 2012 - 09:43 AM

From what we've learned earlier from papirosnik and loboWu, when compiling for ARM scons must be used, so I suggest you concentrate your efforts on that and leave trying to get it to work with MSVC for later.

Do you expect this to run on iOS or Android? I don't think Marmalade defines either when compiling for arm, which will leave the configuration in AngelScript only partly defined.

Try including ANDROID or __APPLE__ and TARGET_OS_IPHONE, i.e.

defines
{
MARMALADE
_ARM_
ANDROID
}

or

defines
{
MARMALADE
_ARM_
__APPLE__
TARGET_OS_IPHONE
}

In loboWu's makefile I see he defined AS_ARM directly to enable the as_callfunc_arm.cpp. But this would bypass all other configuration in as_config.h so this is not recommended. However, if none of the above works, you might try that as well.

Observe, iOS and Android uses slightly different calling conventions and I have no idea which Marmalade uses (or even if it isn't using a completely different calling convention) so you may need to try both to see which works best.


#5004217 AngelScript 2.25.2 is out

Posted by Andreas Jonsson on 26 November 2012 - 09:54 AM

I'm glad you see an improvement, even though it is only 10%.

Most users probably won't notice a big difference as the slow compilation times only happened with very large functions (thousands of lines) with lots of conditional code in it. If the functions are broken down to more reasonable sizes of at most hundreds of lines in each, then the problem wasn't noticeable.


#5003811 AngelScript 2.25.2 is out

Posted by Andreas Jonsson on 24 November 2012 - 02:37 PM

As promised with the previous release, this new version includes all the stuff that I didn't have the time to implement for version 2.25.1.


Most of the bytecode optimazations are now done locally for each statement that is compiled. This reduces the search time for uses of temporary variables. With this the compilation time should be close to linearly proportional to the size of the source code.

I've enhanced the bytecode optimizations to remove some more redundant code. Especially some common instruction sequences that would make unnecessary work on object handles has been improved a lot.


The engine has been improved to avoid notifying the garbage collector of internal objects, e.g. functions, object types, and properties, when it is known that they are still in use. This will reduce the amount of time the gc spends trying to detect garbage for these kind of objects, and thus allow it spend that time elsewhere.

Finally the script language has received an enhancement. The mixin classes can now implement interfaces. When a class includes a mixin class that class will also implement all the interfaces that are in the mixin class.

Regards,
Andreas


#5001593 Angelscript on Raspberry Pi

Posted by Andreas Jonsson on 16 November 2012 - 12:18 PM

The paramSize gives the number of dwords present in the paramBuffer. As such, the float args that are placed in the registers shouldn't increase the paramSize.

args = &paramBuffer[2], is because in some situations a pair of hidden arguments are passed before the explicit args, e.g. when an object is returned by value, then a pointer to the memory where that object should be initialized is passed before all other args, and when calling an object method, then the object pointer is also passed as a hidden argument before the rest.

Sounds like you're making good progress. I look forward to adding Raspberry Pi as yet another supported platform :)


#5001225 Angelscript on Raspberry Pi

Posted by Andreas Jonsson on 15 November 2012 - 08:22 AM

This is another use for disassembly. See how the compiler does it, and then copy that.

For example:

void TargetFunc(double d0, double d1, double d2, double d3, double d4, double d5, double d6, double, d7) { printf("",d0,d1,d2,d3,d4,d5,d6,d7); }

void DisassembleMe(asDWORD *floatArgs)
{
  TargetFunc(*(double*)&floatArgs[0],
                      *(double*)&floatArgs[2],
                      *(double*)&floatArgs[4],
                      *(double*)&floatArgs[6],
                      *(double*)&floatArgs[8],
                      *(double*)&floatArgs[10],
                      *(double*)&floatArgs[12],
                      *(double*)&floatArgs[14]);
}

I don't know much about assembly either. I wouldn't dream about attempting to write an assembly function from scratch. All the assembler routines I've written so far is from piecing together sequences I've gathered from disassemblies.


#5001027 Marmalade: Angelscript runs fine on x86, crashes on ARM

Posted by Andreas Jonsson on 14 November 2012 - 04:13 PM

Thanks for reminding me of the comments in the .S file, and for clarifying the need to use scons to build for Android and iOS.

I'll add this information to the manual in the article about compiling the library for Marmalade.

I don't want to remove the comments from the .S file. But perhaps there is another comment syntax that is acceptable when compiling with both Marmalade and gcc? Do you know what can be used instead of the C++ comments?


#4994886 AngelScript 2.25.1 is released

Posted by Andreas Jonsson on 28 October 2012 - 06:59 PM

I've released a new version. I haven't had a whole lot of time to spend on AngelScript this time, so it doesn't include as all the enhancements that I had originally planned. Still, the release is still worth it for the bug fixes alone.


Besides the bug fixes, the few enhancements that did make it include; support for inheritance by interfaces, meaning that one interface can inherit another interface; declaration of multiple class properties of the same type separated by comma; and improved algorithm for determining which function overload to call.

For the next release I'll continue working on the enhancements that got left out; allow mixin classes to implement interfaces; use of local bytecode optimizations to speed up compilation; and avoid notifying GC of script functions to improve runtime performance.

Regards,
Andreas


#4993996 Context state change

Posted by Andreas Jonsson on 25 October 2012 - 07:26 PM

I've added the extra call to the LineCallback in revision 1446.

This callback is done after the context's state is updated, but before the Execute() method returns. The line callback can thus differ between this call and the ordinary line callbacks by checking the context's state, e.g. if ctx->GetState() returns asEXECUTION_ACTIVE, then it is an ordinary line callback, otherwise the returned state is what will be returned to the application.


#4993440 Marmalade: Angelscript runs fine on x86, crashes on ARM

Posted by Andreas Jonsson on 24 October 2012 - 08:32 AM

You can use AS_MARMALADE instead of MARMALADE.

_MSC_VER really should be defined internally by the MSVC compiler, so defining it manually could definitely cause some troubles. I just asked you to define it because it seemed that it wasn't defined already.

I would really like to know what defines are given automatically by Marmalade when compiling for ARM with the MSVC compiler. If you can ask on the Marmalade forum if anyone knows how to find that out it would be good.

Without it I really don't know why as_config.h doesn't properly identify that the target platform is Marmalade with ARM.

If you look at the as_config.h it is really quite simple:

Line382: #if defined(_MSC_VER) && !defined(__MWERKS__)
Line404: #if defined(AS_MARMALADE) || defined (MARMALADE)
Line452: #ifdef _ARM_

These three conditions should be evaluated to true in order for it to work, but for some reason it doesn't seem to be the case for you.


#4993280 Marmalade: Angelscript runs fine on x86, crashes on ARM

Posted by Andreas Jonsson on 23 October 2012 - 05:51 PM

Apparently the as_config.h is not detecting that you're compiling for an ARM processor and automatically turn on AS_MAX_PORTABILITY.

As you're compiling with MSVC the following defines must be given in order for as_config.h to properly detect the target CPU.

_MSC_VER
MARMALADE
_ARM_

Try forcing those defines in the project settings when compiling the AngelScript library.


It would help a lot if there is a way to see what defines are predefined when compiling with Marmalade. This would require a lot less guesswork then.


#4992756 Marmalade: Angelscript runs fine on x86, crashes on ARM

Posted by Andreas Jonsson on 22 October 2012 - 07:26 AM

I'm not sure. asFunctionPtr is a template function to copy different function pointers into a common structure that AngelScript can use to determine how to call the application function. The implementation of asFunctionPtr is extremely simple, I don't see how it could fail inside this function.

Can you show the callstack when the assert happens?


#4992755 asIScriptGeneric with object method possible?

Posted by Andreas Jonsson on 22 October 2012 - 07:20 AM

Then the function must be implemented like this:

// Global function, or static class method
void MyGenericFunction(asIScriptGeneric *gen)
{
  for( asUINT n = 0; n < gen->getArgCount(); n++ )
  {
    int type = gen->GetArgTypeId(n);
    void *ptr = gen->GetAddressOfArg(n);

    ... reinterpret_cast the pointer according to its type
  }
}

Regards,
Andreas


#4992482 Marmalade: Angelscript runs fine on x86, crashes on ARM

Posted by Andreas Jonsson on 21 October 2012 - 10:56 AM

The biggest problem with Marmalade is that it appears to remove all predefines that are normally available. This makes the code in as_config.h fail to identify the target platform and thus doesn't properly set up the defines that the rest of the code need to compile properly.

When compiling for the ARM platform, you need to make sure the macro _ARM_ is defined globally. This should make as_config.h set up the proper macros for ARM, including AS_ARM define.

You will also have to include the as_callfunc_arm_msvc.asm in the project, so the armFuncXXX functions get compiled too. I'm not sure how Marmalade will handle the assembler code. However, as Marmalade can use MSVC10, it can probably also use custom build commands. For the assembler file you can probably use the following custom build command:

armasm -g $(InputPath)


Add to this the recommendations from our e-mail conversations:

1) Defined AS_NO_THREADS to avoid the problem with pthread_rwlock_t
2) Change angelscript.h to use typedef size_t asPWORD; instead of typedef uintptr_t asPWORD;


I'd very much like to see Marmalade working with native calling conventions too. Let me know if the above changes work, and I'll make them part of the official code.


Thanks,
Andreas




PARTNERS