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

[Liam O'Connor]

Ah, looks as though we'll have to write a C layer between Java and
Haskell.. doing all of this in  the FFI seems like hard:

http://www.koushikdutta.com/2009/01/jni-in-android-and-foreword-of-why-jni.html

Cheers.
~Liam



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