Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARM64 code for Apple iOS devices supporting ARM64 #3

Open
wernerd opened this issue Jun 2, 2017 · 5 comments
Open

ARM64 code for Apple iOS devices supporting ARM64 #3

wernerd opened this issue Jun 2, 2017 · 5 comments

Comments

@wernerd
Copy link

wernerd commented Jun 2, 2017

The Apple A7 - A10 processors are ARM64 compatible and run iOS. I know that the SIDH code was designed for Linux/Windows, however it should not be a big issue to make it ready for iOS based ARM64 systems ;-) . I did a quick check (no testing yet) about the iOS requirements for ARM64 assembler code and found one issue regarding usage of register x18:
https://developer.apple.com/library/content/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html

Currently the ARM64 assembler code uses x18 which is reserved if the code runs on iOS. Maybe the code can use some other register? Maybe not a high priority issue yet :-) .

@dburbani
Copy link

dburbani commented Jun 2, 2017

I'm the author of the ARM64 assembler code. There's at least two reasons why the code uses x18:

  1. I don't have an iOS device, but rather a linux machine and an Android device, and on those using x18 seems to work fine.
  2. The asm code is designed to be as efficient as possible to demonstrate the viability of SIDH. Moving data on and off the stack is inefficient, and in this case because multiplication involves 12 + 12 + 24 = 48 words, there is more data involved in the computation then there are registers to hold it. Hence every extra register helps.

It's of course possible to modify the code to avoid using x18. But figuring out the most efficient, cleanest way to do so takes some time, and because this code is primarily to demonstrate viability rather than for use in production, I'm not sure that it's worth doing right now. SIDH is still under active research and there is some expectation that the code may change in the future as people either discover problems with the system or find better ways of doing things. You seem to have gotten the code working with reasonable performance, and that's really all that it's intended for, in my view. Of course I can't speak for everyone.

@wernerd
Copy link
Author

wernerd commented Jun 2, 2017

Fully understood. I also treat this as a pre-production :-) code. I just added the comment as something to remember if somebody is going to do it for iOS. In this case somebody with more knowledge needs to check this. Maybe it's just OK to save the register and restore it when entering/leaving the function.

@dburbani
Copy link

dburbani commented Jun 2, 2017

Maybe it's just OK to save the register and restore it when entering/leaving the function.

I doubt it, otherwise it would simply be classified as callee-save like x19-x28. For instance, from page 15 of [1] we have:

Software developers creating platform-independent code are advised to avoid using r18 if at all possible. Most compilers provide a mechanism to prevent specific registers from being used for general allocation; portable hand-coded assembler should avoid it entirely. It should not be assumed that treating the register as callee-saved will be sufficient to satisfy the requirements of the platform.

  1. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf

@Ko-
Copy link

Ko- commented Oct 13, 2018

Just in case anyone's looking for an ARM64 optimized implementation that also runs on iOS: this one does. But it requires Go.

@evandrix
Copy link

evandrix commented Feb 9, 2020

Just in case anyone's looking for an ARM64 optimized implementation that also runs on iOS: this one does. But it requires Go.

Where's the link to the exact repo built for iOS/arm64?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants