Some of my code reference a library which use arm_neon.h; when I tried to compile using "Simulator", I received a bunch of errors.
I am using LLVM 4.2 compiler, what should I do to get it compiled with arm neon?
You can't compile ARM NEON code for the simulator because the simulator doesn't execute ARM machine code, it executes i386 machine code. See here for more info, but here is a snippet:
Don’t forget that you’ll need to disable the NEON code at compile time when building for the simulator, as your application is compiled for x86 when targeting the simulator, and NEON code will cause build errors in this context. This means you always need to also write a generic C version of the algorithm, even if you only target the iPad, or you won’t be able to run your application in the simulator.
Related
Basically, my question is if Xamarin IOS is statically compiled or compiled ahead of time (AOT), why do we need Mono Runtime within ipa?
May be I do not understand how does xamarin ios work in the ios devices?
Please can anybody shed some light?
When you compile any Xamarin platform application, the Mono C# (or F#)
compiler will run and will compile your C# and F# code into Microsoft
Intermediate Language (MSIL). If you are running a Xamarin.Android, a
Xamarin.Mac application, or even a Xamarin.iOS application on the
simulator, the .NET Common Language Runtime (CLR) compiles the MSIL
using a Just in Time (JIT) compiler. At runtime this is compiled into
a native code, which can run on the correct architecture for your
application.
However, there is a security restriction on iOS, set by Apple, which
disallows the execution of dynamically generated code on a device. To
ensure that we adhere to these safety protocols, Xamarin.iOS instead
uses an Ahead of Time (AOT) compiler to compile the managed code. This
produces a native iOS binary, optionally optimized with LLVM for
devices, that can be deployed on Apple’s ARM-based processor.
iOS App Architecture this link may be useful to you for more detail.
why do we need Mono Runtime within ipa?
The native ARM code that is generated by Xamarin.iOS (mtouch) AOT process depends upon the Mono runtime as the AOT process is not a transcoding compiler.
This dependency is mainly for the garbage collector but it also provides the runtime interface from the low level .Net/Mono framework calls to the iOS|tvOS|watchOS operating system.
In my search for how Dart AOT works, I have not found many resources except this video. I would like to know how it is that code can be compiled down to native machine code, such as Android or iOS, when there exists different pieces of hardware that code needs to run on.
From what I understand, there are only descriptions of apps produced in Flutter. That description (written in Dart) is then compiled down to native machine code, but how? A program written in Swift is different from a program written in Kotlin.
A compiler creates the binary code from Dart source code.
For mobile applications the source code is compiled for multiple processors ARM, ARM64, x64 and for both platforms - Android and iOS. This means there are multiple resulting binary files for each supported processor and platform combination.
From what I understand, there are only descriptions of apps produced in Flutter.
Not sure what you mean by that. The concept of source code and compilation to a target platform is basically the same for each programming language.
JIT (Just in Time) compiles at runtime on-the-fly while AOT (Ahead of Time) compiles before the application is deployed and launched.
A program written in Swift is different from a program written in Kotlin.
Also not sure what you mean by that.
Swift can compile to native code and Java to Java bytecode. Swift is AoT while Java is JiT. The end result is always binary code for the target platform and CPU.
What are the necessary steps I need to take to compile VLFeat (an open source C library) and include it in my iOS project? Here is what I found out so far:
I am not too familiar with the compilation and linking procedures, but from what I currently understand, I need to compile VLFeat for the arm64 architecture in order for it to run on the iPhone.
There is a severely outdate guide on how to include VLFeat in XCode:
http://www.vlfeat.org/xcode.html
But when I follow these steps I get the following error:
Undefined symbols for architecture arm64:
"_vl_get_printf_func", referenced from:
-[OpenCVWrapper createMatrixFromImage:] in OpenCVWrapper.o
ld: symbol(s) not found for architecture arm64
I suspect this is because the library is actually built for OSX (hence for a different architecture). I have not been able to figure out how to build this for iOS (arm architecture) and get it running on a physical iPhone.
When I open the XCode project that is included in the VLFeat download and go to build settings for one of the Targets and change the Base SDK to iOS and Supported platforms to iOS and Valid Architectures to arm64 and then try to build, a bunch of errors come up for the VLFeat source code such as:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mmintrin.h:64:12: Invalid conversion between vector type '__m64' (vector of 1 'long long' value) and integer type 'int' of different size
and
"Compiling with SSE2 enabled, but no __SSE2__ defined"
These errors make me suspect that actually its not possible to build this library for arm and that, short of porting the library over (modifying code), it is an impossible task. I am not sure whether the conclusions I reached are correct so any input on this would be helpful.
The VLFeat library does not currently (January 2023) support ARM architectures, and seems to no longer be maintained, as the last commit was in January 2018.
However, this commit to a copy of the library updates the host.h and host.c files to add basic support for the Clang compiler and ARM architectures. This has enabled me to compile binaries for the Apple M1 Pro processor running MacOS, and these perform as expected.
Performance will not be as good as on Intel CPUs because the SIMD Neon instruction set for ARM is not yet supported, whereas SSE2 (on Intel) is.
I tried to use the float16_t type in my iOS app to save memory space. It seems to work perfectly on device, but it does not build on simulator.
In the simulator build it fails with
Unknown type name 'float16_t'; did you mean 'float_t'?
The float16_t seems to be defined in arm_neon.h.
Can this be fixed so that I can use that type on simulator?
Very obvious!
float16_t is declared in "arm_neon.h" means the type is strictly for ARM based CPU instructions (specifically ARM CPUs with supported NEON instruction set).
Till date, all iOS devices run on ARM based CPU. So your code is good when compiled for device (Though, possibly won't run in some very old iOS device with older ARM cpus without NEON).
However, iOS Simulator runs on a Mac, which is built on top of x86/x64 CPU architecture, not ARM. So ARM types simply don't work here.
I'm not sure why you do really want to work with some ARM NEON optimized data types like float16_t, when float_t works great, everywhere. But if you still want to use it and want your app to run everywhere, you should use conditional compilation directives to compile your code:
#if TARGET_IPHONE_SIMULATOR
float_t x;
#else
float16_t x;
#endif
Hope it helps.
I'm trying to use libXl for iOS and it is giving me a linker error.
"missing required architecture x86_64"
I've changed the Architechture to standard but when I try to build for a 64 bit simulator, it gives me the linker error.
What needs to be changed to fix this error if I don't have the source code for the library?
Unfortunately, if you don't have the source code for the library and the library doesn't have a 64-bit slice, then you can't compile a 64-bit version of your app. (By the looks of things, even the commercial version of LibXL doesn't support 64-bit yet.)
Additionally, you can't mix 32 and 64 bit code/libraries within an app, I'm afraid. (If your app is 32 bit, the OS will load a 32 bit version of UIKit, etc. but that's as far as it goes.)
However, if you simply build your app as 32-bit if will run perfectly fine on 64-bit (i.e.: A7 processor+) devices.