On 19 April 2010 05:29, Don Stewart 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).

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.h... Cheers. ~Liam On 19 April 2010 14:33, Liam O'Connor 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 wrote:

...

On 19 April 2010 05:29, Don Stewart 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).

Whatever happened to the JVM backend for GHC? That might actually be a relatively straightforward solution to the whole "interface to Java" problem. On Sun, Apr 18, 2010 at 11:42 PM, Don Stewart wrote:

liamoc:

...

On 19 April 2010 05:29, Don Stewart 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.

More work also in that you need to port the runtime system to Java... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Well the other issue is of course that Android being available on a wide variety of phones, not all of which run ARM (the phone I am about to get for example has a custom built CPU), although I guess one could use a "generic" ASM branch for "mobile" devices (if one exists). btw the phone I am about to receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what Assembler Instruction set it uses, I believe its a closed chip) In my opinion the most "reliable" approach would actually to produce the C that wraps around NDK (for any code that could be possible) which would obviously interface with the Java libraries. Probably the biggest bane of Android is the fact that its able to run on almost all machines means that there *would* be issues using LLVM to just produce code for the generic ARM. Using the NDK + Java would mean any app written in Haskell would work on any android device. Of course as mentioned above, there are issues with this. Its a lot of work for one thing, and the GC for Java is probably not the best suited for Haskell structured programs. Also iirc, in order to make "official" Android apps which can go on the market place, you are basically forced to use the Java API + NDK for any native code, and you have to use the Java API to interface with the android GUI/World (you can't make an proper Android app just using NDK which complicates things further). The GC issue I guess could be solved by generating JVM code (instead of Java "code") which would give more freedom for GHC to generate code more suited to Haskell If this ever ended up happening, it does have the advantage that when one would develop an app for Android using Haskell, GHC (or whatever compiler we would use) can use NDK for as much code as possible and only resorting to Java libraries when required which can of course equate to creating very fast Android Apps using a productive language (Haskell) As Don mentioned through, we need a java runtime for GHC.

Although I know that ARM basically has monopoly for chipsets on mobile devices, that doesn't mean there couldn't be a chipset used that isn't ARM and runs android (and what if that device happened to be really popular in the future?) The main issue however, as I mentioned before, is the fact that from what I read on the Android site, proper Android apps (as in ones that you can get through the market place), you are forced to use the Java API to interface with android (and the NDK for native code generation if required). I believe what people would want the option of creating proper Android apps So it would just be a difference between using Java + ARM ASM (through LLVM I suppose) or Java + NDK (through FFI??). The latter, actually being supported by Google, is "guaranteed" to work on any android device, ARM or not The other option is we could just wait for someone to make an Android backend through LLVM :), That of course is the last option, which would also mean that any language that compiles down to LLVM would be able to run on Android as well. On Sun, Aug 8, 2010 at 1:14 AM, Daniel Peebles wrote:

The Hummingbird is still ARM. ARM doesn't actually build any chips themselves, and just license the architecture design out to people who do make them. Most of the iPhone ARM chips are built by Samsung too.

Almost all the mobile devices I know of run ARM, so I think having a native ARM generator would still be very beneficial. And if it isn't ARM on a device, it's almost certainly going to be Intel, these days. Sure, Android doesn't specify that this has to be the case, but realistically, it will be.

On Sun, Aug 8, 2010 at 3:08 AM, Mathew de Detrich wrote:

...

Well the other issue is of course that Android being available on a wide variety of phones, not all of which run ARM (the phone I am about to get for example has a custom built CPU), although I guess one could use a "generic" ASM branch for "mobile" devices (if one exists). btw the phone I am about to receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what Assembler Instruction set it uses, I believe its a closed chip)

In my opinion the most "reliable" approach would actually to produce the C that wraps around NDK (for any code that could be possible) which would obviously interface with the Java libraries. Probably the biggest bane of Android is the fact that its able to run on almost all machines means that there *would* be issues using LLVM to just produce code for the generic ARM.

Using the NDK + Java would mean any app written in Haskell would work on any android device. Of course as mentioned above, there are issues with this. Its a lot of work for one thing, and the GC for Java is probably not the best suited for Haskell structured programs. Also iirc, in order to make "official" Android apps which can go on the market place, you are basically forced to use the Java API + NDK for any native code, and you have to use the Java API to interface with the android GUI/World (you can't make an proper Android app just using NDK which complicates things further). The GC issue I guess could be solved by generating JVM code (instead of Java "code") which would give more freedom for GHC to generate code more suited to Haskell

If this ever ended up happening, it does have the advantage that when one would develop an app for Android using Haskell, GHC (or whatever compiler we would use) can use NDK for as much code as possible and only resorting to Java libraries when required which can of course equate to creating very fast Android Apps using a productive language (Haskell)

As Don mentioned through, we need a java runtime for GHC.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I just did some further talking with Liam, and it appears that the NDK really just produces an ARM binary which ends up getting linked into the Dalvik VM files (it isn't platform independant as I thought) which means that using LLVM to produce an ARM ASM output is a fine choice. By the sounds of it the NDK is designed to be platform dependant (not independent) so it appears that if any Android system does come out in the future that doesn't use ARM, you would have the same issue with NDK There still however leaves the problem with what to do with Java, because a proper Android app (not a linux app compiled for ARM) needs to link with Java to interface with Android On Tue, Aug 10, 2010 at 8:21 PM, Karel Gardas wrote:

On 08/08/10 03:08, Mathew de Detrich wrote:

...

Well the other issue is of course that Android being available on a wide variety of phones, not all of which run ARM (the phone I am about to get for example has a custom built CPU), although I guess one could use a "generic" ASM branch for "mobile" devices (if one exists). btw the phone I am about to receive is a Samsung Galaxy-S, which has a hummingbird chip (no idea what Assembler Instruction set it uses, I believe its a closed chip)

This should be S5PC110 if I google correctly which is "just" yet another ARM Cortex A8:

http://www.samsung.com/global/business/semiconductor/newsView.do?news_id=104...

Karel

On Sun, Aug 08, 2010 at 01:08:30AM +0000, Mathew de Detrich wrote:

In my opinion the most "reliable" approach would actually to produce the C that wraps around NDK (for any code that could be possible) which would obviously interface with the Java libraries. Probably the biggest bane of Android is the fact that its able to run on almost all machines means that there *would* be issues using LLVM to just produce code for the generic ARM.

I have heard anecdotal reports that the output from jhc can be compiled with the NDK to android aps with minor changes. If anyone wanted to run with this, I'd add it as a first class target platform for jhc. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/