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

[Liam O'Connor]

Also worth mentioning that the Android docs explicitly warn against
"allocating frequently" suggesting reuse of objects is by far more
preferable than regularly allocating stuff. If we go the Dalvik/Java
route, then we'll have alot of work to do to make the GC work for us
nicely, whereas compiling to native code gives us full control.

The problem (and why I believe compiling to Java would be better) is
that it is quite tedious and difficult to interact with Java APIs
using native code. You write a shell of your application in java and
put calls in to native code everywhere. It ruins alot of the glamor of
Haskelling for android. That said, if we can somehow expose some Java
functions to haskell (rather than the other way around) then we could
eventually write an android API library for native haskell, giving us
both the performance benefits and the android api.

Cheers.
~Liam



On 19 April 2010 14:25, Liam O'Connor <liamoc at cse.unsw.edu.au> wrote:
> 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).
>