How to Write Inline Assembly in Swift

Is it possible to write inline assembly in Swift?

To expand on what Robert Levy said, you can just use the Swift/Obj-C interop feature, and write an Obj-C class that does the ASM stuff, which you can then call from Swift.

It's an annoying workaround, but it should work nonetheless.

You can read more about how to do it [here]

How to write assembly in swift

No you can't if you want this you can do this in objective c and expose your objective- c code to Swift with a bridging header.
Objective-C code:

inline void assemblyFunc() {
    __asm__(/*Assembly*/);
}

More info on bridging: https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html

How to call Objective-C code from Swift

I also asked this question here: Is it possible to write inline assembly in Swift?

How do I do inline assembly on the IPhone?

I've gotten this to work, thanks to some inside help over at the Apple Devforums, you should sign up if you're a dedicated IPhone developer.

First thing's first, it's __asm__(), not plain asm().

Secondly, by default, XCode generates a compilation target that compiles inline assembly against the ARM Thumb instruction set, so usat wasn't recognized as a proper instruction. To fix this, do "Get Info" on the Target. Scroll down to the section "GCC 4.0 - Code Generation" and uncheck "Compile for Thumb". Then this following snippet will compile just fine if you set the Active SDK to "Device"

inline int asm_saturate_to_255 (int a) {
  int y;
  __asm__("usat %0, #8, %1\n\t" : "=r"(y) : "r"(a));
  return y;
}

Naturally, now it won't work with the IPhone Simulator. But TargetConditionals.h has defines you can #ifdef against. Namely TARGET_OS_IPHONE and TARGET_IPHONE_SIMULATOR.

Using inline assembler in iOS aarch64 application

Here is how you do it:

-(int) roundff:(float)a {
    int y;
    __asm__("fcvtzs %w0, %s1\n\t" : "=r"(y) : "w"(a));
    return y;
}

Take care,

/A

calling a function defined in assembly from swift

Create the bridge header.h file and put the prototype of the function in that file.

For example your assembly code:

.globl _add // make it global so that others can find this symbol
....
_add: // int add(int a, int b)
  movl %esi, %eax
  addl %edi, %eax
  ret

Then in bridging header.h file

int add(int a, int b);

OR

define this at the top of the swift module

@_silgen_name("add") func add(a: Int32, b: Int32) -> Int32

Then in swift you can use it:

let a = add(1, 2);

Xcode 10.2 GNU-style inline assembly is disabled

In your WatchKit Extension target (or whatever target it's complaining this for), add -fgnu-inline-asm to the Other C Flags build options. You'll need to file a radar as well as it looks like a bug.

Assembler on 64-bit iOS (A64)

1. The .align 2 directive is required for program correctness. A64 instructions need to be aligned on 32-bit boundaries.
2. The documentation you linked seems clear to me and unfortunately this isn't the place to ask for recommendations.
   
   • You can determine that registers lhs and rhs get stored in X0 and X1 by by following the instructions given in section 5.4.2 (Parameter Passing Rules) of the Procedure Call Standard for the ARM 64-bit Architecture (AArch64) document you linked. Since the parameters are both pointers the only specific rule that applies is C.7.
   • You can determine which register is used to return values in by following the instructions given section 5.5 (Result Return). This just has you following the same rules as for parameters. Since the function returns an integer only rule C.7 applies and so the value is returned in X0.
   • It's safe to change the values stored in registers X9 through X12 because they're listed as temporary registers in the table given in section 5.1.1 (General-purpose Registers)
   • The question is really whether the function is called the same way in Swift as in C. Both the Procedure Call Standard document and the Apple specific exceptions document you linked are defined in terms of C and C++. Presumably Swift follows the same conventions but I don't know if Apple has made that explicit anywhere.
     
3. The purpose of R8 is described in section 5.5 (Result Return). It's used when the return value is too big to fit into the registers used to return values. In that case the caller creates a buffer for the return value and puts it address in R8. The function then copies the return value in to this register.
4. I don't believe you need anything else in your example assembly program.
5. You've asked too many questions. You should post a separate and more detailed question describing your problem.

I should say one advantage of writing your code using inline assembly is that you wouldn't have to worry about any of this. Something like the following untested C code shouldn't be too unwieldy:

bool eq256(const UInt256 *lhs, const UInt256 *rhs) {
     const __int128 *lv = (__int128 const *) lhs->value;
     const __int128 *rv = (__int128 const *) rhs->value;

     uint64_t l1, l2, r1, r2, ret;

     asm("ldp       %1, %2, %5\n\t"
         "ldp       %3, %4, %6\n\t"
         "cmp       %1, %3\n\t"
         "ccmp      %2, %4, 0, eq\n\t"
         "ldp       %1, %2, %7\n\t"
         "ldp       %3, %4, %8\r\n"
         "ccmp      %1, %3, 0, eq\n\t"
         "ccmp      %2, %4, 0, eq\n\t"
         "cset      %0, eq\n\t",
         : "=r" (ret), "=r" (l1), "=r" (l2), "=r" (r1), "=r" (r2)
         : "Ump" (lv[0]), "Ump" (rv[0]), "Ump" (lv[1]), "Ump" (rv[1])
         : "cc")

     return ret;
}

Ok, maybe it's a little unwieldy.

What problems are to be expected for Swift and C developers when developing applications for Apple Silicon (ARM) processors?

This answer will focus on C, as I don't have any experience with Swift.
If you write a normal application (no cross platform library), only using platform independent libraries (Those will handle this for you)+libc, you won't have any problem.

But if you use (inline-)assembly or intrinsics (like __builtin_ia32_pminsb256), you would have to either translate it to ARM or write it new (==>To support x86, too).

Furthermore x86 devices with MacOS will stay around some years, so you have either have to support two architectures for a few years or simply drop support for x86.

---

Related Topics