Jump to content
  • Advertisement
howie_007

Any plans on supporting 64-bit ARM native calling conventions?

Recommended Posts

Advertisement

Yes. I have plans for it. Unfortunately I just don't have the time to do it myself at the moment.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 :)

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!