Version franÁaise
Home ††† About ††† Download ††† Resources ††† Contact us †††
Browse thread
arm backend
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Nathaniel Gray <n8gray@g...>
Subject: Re: [Caml-list] Re: arm backend
On Fri, May 1, 2009 at 3:12 PM, Jeffrey Scofield <dynasticon@mac.com> wrote:
> Nathaniel Gray <n8gray@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/