macOS Using Inline or External Assembler with Xcode ?

asm need is not only for speed...

Thank you, "gnasher729" for your hints. I'm struggling similarly like "Elhardt" with inline asm, but for a different reason: Porting a large C++ system that uses atomic instructions for synchronization to MacOS. And until C++11 is fully and consistently implemented by all major compilers and on all major platforms, inline asm is the only portable option (requiring just very few hardware-specific variations). Setting-up Xcode for this is just painful.

Q-chan said:

Thank you, "gnasher729" for your hints. I'm struggling similarly like "Elhardt" with inline asm, but for a different reason: Porting a large C++ system that uses atomic instructions for synchronization to MacOS. And until C++11 is fully and consistently implemented by all major compilers and on all major platforms, inline asm is the only portable option (requiring just very few hardware-specific variations). Setting-up Xcode for this is just painful.

Click to expand...

See libkern/OSAtomic.h

Inline assembler is _not_ an option at all. This stuff is complicated. The functions in OSAtomic.h use different implementations at runtime depending on exactly which processor they are running on. I haven't checked it, but I wouldn't be surprised if you get the new Haswell features for much faster atomic operations in the non-conflicting case if you run on a Haswell processor.

Please keep us Informed

Hello Elhardt!

I'm also looking for a straightforward way to add an Arm-assembler algorithm (already working in Android) to our iOs port, currently being written in XCode5. This particular assembler core routine resulted in a 25x increase from our C optimized version, so I really value your rationale and defense for well-tuned hand-crafted assembly code.

It was curious and very frustrating because after referencing the assembly language file, the compiler began spitting localised errors (mainly choking with the GCC style assembler directives and a refusal to use the LDR r, =32-bitconst pseudo-instruction.) This led me to believe that after fixing the syntax problems everything would be fine. Yet after fixing the last of these errors, a completely new batch of previously unreported errors, starting from the first uncommented assembly source code line, began to appear! In other words, the syntax was validated by some part of XCode, but then, a different layer completely refused to accept the syntax!


Please post if you succeed in your attempts. I'll do the same if I succeed in mine.

Cheers!
=)

sgorozco said:

Hello Elhardt!

I'm also looking for a straightforward way to add an Arm-assembler algorithm (already working in Android) to our iOs port, currently being written in XCode5. This particular assembler core routine resulted in a 25x increase from our C optimized version, so I really value your rationale and defense for well-tuned hand-crafted assembly code.

Click to expand...

Curious what you have been doing.

gnasher729 said:

Curious what you have been doing.

Click to expand...

I've got ARM assembly code in a similar situation. It's very similar to the stuff that Apple hand-coded in their own Accelerate/vDSP/mathlib frameworks for iOS. Unfortunately, it's not exactly identical to what Apple provides, and is significantly slower in compiled C.