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 <lia...@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 <lia...@cse.unsw.edu.au> wrote: >> On 19 April 2010 05:29, Don Stewart <d...@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). >> > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
