Just wondering. I know I can setup a generic calling convention wrapper.
🎉 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!
Any plans on supporting 64-bit ARM native calling conventions?
Yes. I have plans for it. Unfortunately I just don't have the time to do it myself at the moment.
Author
Perhaps I can try adding 64-bit Arm native calling convention support and providing the changes when I'm done? Could you point me in the right direction as to where to start? Perhaps there's a current similar implementation you can suggest I look at, to get a sense of how this would be done?
That would be perfect. There is another initiative going on here:
The directions for how to get started is already described there. Android and iOS are likely going to have some minor differences in the native ABI, but otherwise they will be very similar and both will benefit from each other, whichever is finished first.
The closest implementation already available in the code is for Arm 32bit with hardfloat (as_callfunc_arm.cpp/as_callfunc_arm_gcc.S). The C++ can probably serve as a base for the Arm 64bit too, but the assembler code will need to be fully replaced due to the different instruction set and CPU registers used by Arm 64bit.
Author
Thanks for pointing me to that thread. The new Raspberry Pie 4 with a 64-bit OS might be a good development platform to get this working. Just have to load on a 64-bit OS.
I took this opportunity to tinker with the generic calling convention and the wrapper macros you've provided. I'm assuming the native calling convention is much faster then the generic. Switching over to the generic calling convention (via the wrappers) seems pretty painless. Is there any drawback to do so?
Whether the native calling convention or the generic calling convention is faster depends on a lot of factors. The signature of the function itself (i.e. number and type of parameters), the complexity of the native ABI, etc.
There is no clear winner here. There will be cases where the generic calling convention is faster, and others where the native calling convention is the faster one.
There is no drawback to using the generic calling convention. At least not that I can think of right now 
I did some quick&dirty tests a while ago wrt generic vs native on linux/clang/x86-64.
I found out that the generic calling convention is noticeably faster when dealing with less parameters, but slows down as you add more parameters and return data.
This was a synthetic test, the actual overhead is probably much less important when the VM actually does more useful work.
When using blindmindstudio's JIT (which unfortunately for you does not support ARM64 and likely never will), native calls become much faster than generic calls as native calls usually bypass AS' system function calling.
AngelScript now has support for native calling conventions on Linux with arm64, thanks to Max Waine from Nightdive Studios.
This was added in revision 2666.
Other platforms are still pending, notably Android and iOS, but hopefully now that the first arm64 platform has been added the others will be much easier to add.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement