On Fri, May 1, 2009 at 3:12 PM, Jeffrey Scofield <dynasti...@mac.com> wrote: > Nathaniel Gray <n8g...@gmail.com> writes: > >> Speaking of which, has anybody built an ocaml cross compiler for the >> iphone that can work with native cocoa touch apps built with the >> official SDK? It's probably too late for my current project but in >> the future I'd love to use ocaml for my iPhone projects. I tried >> following the instructions here[1] with some necessary >> modifications[2] to get the assembler to work but my test app crashed >> as soon as it entered ocaml code. I don't know enough about the ARM >> platform to say why. > > Yes, we have OCaml 3.10.2 cross compiling for iPhone OS 2.2.
Great! > There are at least two more problems, however. Presumably > this is due to differences between the iPhone ABI and the one that > the ARM port (the old one I guess you could say) is targeted for. > > 1. arm.S uses r10 as a scratch register, but it is not a scratch > register on iPhone. It has to be saved/restored when passing > between OCaml and the native iPhone code (I think of it as > ObjC code). Note, by the way, that gdb shows r10 by the > alternate name of sl. This is confusing at first. > > 2. arm.S assumes r9 can be used as a general purpose register, > but it is used on the iPhone to hold a global thread context. > Again, it has to be saved/restored (or at least that's what we > decided to do). > > We saw crashes caused by both of these problems. Ok, I'm glad I left this to people who are familiar with ARM assembly programming. :-) > I'm appending a new version of arm.S that works for us with > one OCaml thread. (Multiple threads will almost certainly > require more careful handling of r9.) It has the patches > from Toshiyuki Maeda mentioned above and a few of our > own to fix these two problems. Awesome, but now I'm confused because the arm.S you included has lots of .global pseudo-ops. Do you not compile it with Apple's as? > We have an application that has been working well for > a couple months, so there's some evidence that these > changes are sufficient. What's your app? How are you managing the interface between Cocoa and OCaml? > We also made a small fix to the ARM code generator > (beyond the patches from Toshiyuki Maeda). In essence, > it fixes up the handling of unboxed floating return > values of external functions. Things mostly work without > this change; I'll save a description for a later post (if > anybody is interested). I am very interested in any and all information needed to get a correct OCaml port suitable for use in App Store applications. Please share! BTW, I've added an issue in mantis[1] now that I know this is more than a configuration problem. Thanks, -n8 [1] http://caml.inria.fr/mantis/view.php?id=4782 -- Nathan Gray http://www.n8gray.org/ _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
