I have a little game running on windows that I've used AngelScript for and I'm now trying to port to iOS. A bit of googling showed native calling isn't currently supporting on 64bit arm devices so I looked into the generic calling convention.  However since I don't want to give up native calling on windows I'm going to either have to re-write all my existing code to try to maintain two different calling conventions (native+generic).... or take you up on this very old offer:

Quote

unfortunately native calling conventions on iOS 64bit is not yet supported (nor is any other 64bit ARM platform). I don't have access to any 64bit ARM platform so I can't implement this support myself, but if you want to give it a try on your own I can guide you through it. It usually doesn't take more than a week or two to get it to work. Although it involves assembler code it doesn't require a lot of understanding of assembler code since most of the time it is just a matter of copying existing code obtained by disassembling C++ compiled functions :).

My assembly skills are very limited but I can follow instructions.  If the offer to guide someone through the process is still available I'd love to try.  Just let me know where to start.  I have a mac with xCode installed and an iPhone 8 that I can install builds on (and PC with VC 2017 if that's at all helpful).

If however you're not able to help at the moment for any reason, no worries at all.  Thanks for creating angel script in the first place I've had a blast using it recently.  If however you are, hopefully this can help out anyone else who wants/needs this in future.

You might also find some useful information in the source code for dyncall. It seems to support arm64 as well.

Sidenote - would it be interesting to implement dyncall into Angelscript directly so that Angelscript itself doesn't need to maintain architecture calling code? I don't know exactly if there are any massive differences.

@WitchLord : Thanks for the steps, I'll give it a try and post back any results or issues.  Hopefully I can get somewhere useful without taking up to much of anybodies time.

@Miss : Thanks for the link - I'll definitely check that out.

Just now, WitchLord said:

While dyncall is an interesting library, it is out of the question to add any dependency to thirdparty libraries from AngelScript. It is one of the main principles that I follow.

Ah yes, that is indeed the impression I've always had and one that I really appreciate a lot.

Sadly I'm still not up to native calling, I'm just trying to get the whole thing working with AS_MAX_PORTABILITY to ensure I'm starting from a solid base.  I've got the 64bit iOS app setup, it's building and running on device and all but one of the tests pass.  Annoyingly though TestExecuteString() fails on an assert:

       assert(*reinterpret_cast<void**>(ref) != 0);

on line 193 of scripthelper.cpp.  The assert is not even part of the test - just part of the Script Helper add-on.  'ref' is a pointer to a std::string so I'm not sure what this assert is even doing here.  Casting to a double pointer then de-referencing back to it's original single pointer to check if it's null?  The code works if I remove this, so not sure why the assert is triggering, but I'm clearly not understanding something.  For now I'm just going to move on to native calling next week, but if that assert is in some way important let me know.

line 193 seems to be for when the execution return type is not a handle (pointer).
You can see that the handle version has the opposite assert.
I guess it just assumes that the first 64bits of the return type should not be all 0 and tries to catch instances where people incorrectly used return values by handle.
I think the return address will be treated as a fully constructed object and some form of assignment will be used on it.
Make sure that having the first 64bits of 0 in your object instance is valid before removing that assert.
 

On 4/15/2019 at 11:20 PM, WitchLord said:

Which test is triggering this assert?

Which test doesn't pass?

Sorry I wasn't clear in my initial post.  TestExecuteString() is the test that trigger the assert.  The assert triggering inside TestExecuteString() is the only issue I had when AS_MAX_PORTABILITY defined.  I'm not sure if triggering an assert is technically a failure or not but that's what I meant when I said a test failed.  As I mentioned if I simply comment out the assert it all worked and everything passed including TestExecuteString().

After Easter break I got back to it and I removed AS_MAX_PORTABILITY and set up the two Arm64 files ('as_callfunc_x64_arm.cpp' and 'as_callfunc_x64_arm_xcode.S') as instructed.  In the .cpp I was able to get it compiling based on what I saw in the other x64 files, and fixing a few other minor compiler issues (mostly just changing any asDWORD types to asQWORD ).  So the .cpp now compiles and I think it's doing what it's meant to do.

I'm left with a whole heap of assembly errors for the .S.  Currently it's just a cut+paste of the original ARM native call without any changes for 64bit.  This is where my programming knowledge ends.  I don't know any arm assembly and certainly not enough to re-write the .S.

I've attached my two new files and the compiler errors generated by the assembly.  This is kind of as far as I can go on my own.  Any help appreciated and if anyone wants I try to zip up my test project for someone else to look at (but to get it working I had to change a few things so it's not a simple as just getting a new version of the xcode project sadly).

as_callfunc_x64_arm_xcode.S

as_callfunc_x64_arm.cpp

compile_errors.txt