[Haskell-cafe] iPhone/Android and Haskell [Was: Embedded
liamoc at cse.unsw.edu.au
Mon Apr 19 01:51:01 EDT 2010
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:
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.
> 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
>> 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:
>> 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).
More information about the Haskell-Cafe