Nathaniel Gray <n8gray@gmail.com> writes:

> Ok, I'm glad I left this to people who are familiar with ARM
> assembly programming.  :-)

We've done a lot of assembly programming, but none of us is an
ARM expert.  We looked at ARM documents and the assembly (.s)
files generated by ocamlopt and gcc, and spent some long sessions
with gdb.

> 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?

At around line 36, you'll see:

  #define global globl

As I said in private mail, you could call this a hack, but it's a
way to avoid making lots of small changes everywhere in the file.

> What's your app?

We're working on a collection of card games for casual play.

> How are you managing the interface between Cocoa and OCaml?

This is a big topic.  The summary is that we model Cocoa objects
as OCaml objects.  We have a layer that wraps OCaml objects in
smallish ObjC objects for use on the ObjC side, and wraps ObjC
objects in smallish OCaml objects for use on the OCaml side.  The
layer then translates between these representations as required
for calls into iPhoneOS and Cocoa Touch from OCaml (asking for
iPhone OS services) and into OCaml from iPhoneOS (for event
handling).

> > We also made a small fix to the ARM code generator
>
> 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!

OK, I'll gather up our patch and send it to the list.  I want to
separate out our changes from those of Toshiyuki Maeda [1].

As I said, our patch fixes calls to external C float functions
such as floor(), sin(), and so on.  There is special handling in
ocamlopt to allow them to be unboxed, but the ABI of the existing
ARM code generator doesn't match the iPhone ABI.

Regards,

Jeff Scofield
Seattle

[1] http://web.yl.is.s.u-tokyo.ac.jp/~tosh/ocaml-on-iphone/