OCaml 4.00.0 on iOS: Progress Report
After finding and resolving some problems, two of which were very interesting, I’m getting close to releasing a version of OCaml 4.00.0 that cross-compiles for iOS devices. I’ve tested it with all the OCaml iOS apps I can, and my colleagues at SEAiq have tested with their iOS apps also.
I call the compiler OCamlXARM because it runs on a Mac, and cross-compiles for ARM-based iOS devices. You can read about the current release of OCamlXARM in Compile OCaml for iOS.
Initially the new version will compile only for armv7/Thumb, which means the generated apps will only run on moderately recent iOS devices (including all iPads). I’ll release an update that compiles for armv6/ARM, which will be able to create apps for all the historical iOS devices.
If you’re interested in trying a prerelease of the OCaml 4.00.0 cross compiler, send me an email. I recommend this for the adventurous only, but it’s extremely useful to me to get feedback on what works and doesn’t. The less adventurous can try the current release, linked above. The current release is based on OCaml 3.10.2 (a pretty old version admittedly), and has been used to create production iOS apps for a few years now.
For those interested in the ups and downs of doing the port, I wrote about earlier development stages in OCaml 4.00.0 Working on iOS. Here are the two interesting problems that came up recently.
While running a test version of our Cassino app I uncovered a code generation bug in the OCaml 4.00.0 compiler. It turned out to be in the scheduling pass, which reorders instructions to make them execute faster. This has been fixed by the experts at OCaml HQ—you can read about it as Mantis issue 5731. The fix will appear in the next bugfix release of OCaml (scheduled to be 4.00.1), but I’ve also merged the fix into OCamlXARM. Many thanks to (the illustrious) Xavier Leroy for looking at and fixing the problem.
I also had the pleasure to discover what I consider a bug in Apple’s iOS
assembler (or possibly it’s a problem with the link editor). You can
see the problem in this simple example, using the cross-development
versions of the assembler and the link editor—
Xcode 4.3.3 iOS toolchain:
$ cat diffplus.s
.word Lsym - . + 0x80000000
$ as -arch armv7 -o diffplus.o diffplus.s
$ otool -d diffplus.o
00000000 80000008 00001966 00001967
$ otool -rv diffplus.o
Relocation information (__DATA,__data) 2 entries
address pcrel length extern type scattered symbolnum/value
00000000 False long n/a SECTDIFFTrue 0x00000008
False long n/a PAIR True 0x00000000
otool output shows is that the three generated 32-bit values
have the proper values. However, the first of the values is marked as a
(somewhat strange) relocatable value. This is incorrect—all of the
values are assembly-time constants, and no relocation is required. This
error seems to prevent some types of linking of the generated object
$ ld -r -o ldr1.o diffplus.o
$ ld -r -o ldr2.o ldr1.o
ld: in ldr1.o, in section __DATA,__data reloc 0: sectionForAddress(0x80000000) address not in any section for inferred architecture armv7
The purpose of
ld -r is to do incremental linking, that is, to
combine several object files (
.o files) into one. For files like
ld generates an invalid object file as output.
If you try to process the file with a later run of
ld, you get the
Unfortunately, the OCaml compiler creates output that looks exactly like
diffplus.s above. Lines like this are used in the frame tables that
describe OCaml function call sites, used by the garbage collector to
avoid collecting values that will still be live when the call returns.
ld -r is used internally to implement the OCaml
After some experimentation I found a workaround. The following assembly
code avoids the (seeming) bug in
$ cat diffplusok.s
offset001 = Lsym - . + 0x80000000
$ as -arch armv7 -o diffplusok.o diffplusok.s
$ otool -d diffplusok.o
00000000 80000008 00001966 00001967
$ otool -rv diffplusok.o
$ ld -r -o ldrok1.o diffplusok.o
$ ld -r -o ldrok2.o ldrok1.o
This transformed version convinces the assembler that the value is
constant at assembly time, so there are no relocation markings in the
generated file. This doesn’t present any problems for
ld, and so
incremental linking works OK.
If no other big problems appear, the new release will be available shortly. The new version will be OCamlXARM 3.1. I’m looking forward to trying out some of the more modern OCaml features in my iOS programming, and I’d also like to do some timing tests. I wonder whether armv7/Thumb code is faster than the armv6/ARM code generated by the previous OCamlXARM release. I’ve also started to be curious how much the scheduling pass (where the recent bug was fixed) improves the speed of my code.
If you have comments or questions, please leave them below, or email me at firstname.lastname@example.org.
Posted by: Jeffrey