[Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]

[Liam O'Connor]

On 19 April 2010 05:29, Don Stewart <dons at galois.com> wrote:
> That's great info -- we do have an unregisterised ARM port of GHC in
> Debian, iirc. (And the LLVM backend can generate ARM code too)


Sounds good. With regards to LLVM, what dependencies does LLVM ARM
code have? Android has gnu libraries not llvm, i don't know if that is
okay.

A superior approach would be to compile haskell to Java or Dalvik
bytecode (or even JVM bytecode if it doesn't use any JIT features;
then we can compile that to dalvik bytecode), but this is obviously
more work if we already have an ARM port.

Here's the docs about the ABI we need to conform to in order to use the NDK.

-- snip --

This is the name of an ABI for ARM-based CPUs that support *at* *least*
  the ARMv5TE instruction set. Please refer to following documentation for
  more details:

   - ARM Architecture Reference manual                (a.k.a  ARMARM)
   - Procedure Call Standard for the ARM Architecture (a.k.a. AAPCS)
   - ELF for the ARM Architecture                     (a.k.a. ARMELF)
   - ABI for the ARM Architecture                     (a.k.a. BSABI)
   - Base Platform ABI for the ARM Architecture       (a.k.a. BPABI)
   - C Library ABI for the ARM Architecture           (a.k.a. CLIABI)
   - C++ ABI for the ARM Architecture                 (a.k.a. CPPABI)
   - Runtime ABI for the ARM Architecture             (a.k.a. RTABI)

   - ELF System V Application Binary Interface
     (DRAFT - 24 April 2001)

   - Generic C++ ABI  (http://www.codesourcery.com/public/cxx-abi/abi.html)

  Note that the AAPCS standard defines 'EABI' as a moniker used to specify
  a _family_ of similar but distinct ABIs. Android follows the little-endian
  ARM GNU/Linux ABI as documented in the following document:

      http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf

  With the exception that wchar_t is only one byte. This should not matter
  in practice since wchar_t is simply *not* really supported by the Android
  platform anyway.

  This ABI does *not* support hardware-assisted floating point computations.
  Instead, all FP operations are performed through software helper functions
  that come from the compiler's libgcc.a static library.

  Thumb (a.k.a. Thumb-1) instructions are supported. Note that the NDK
  will generate thumb code by default, unless you define LOCAL_ARM_MODE
  in your Android.mk (see docs/ANDROID-MK.TXT for all details).