Although I know that ARM basically has monopoly for chipsets on mobile devices, that doesn&#39;t mean there couldn&#39;t be a chipset used that isn&#39;t ARM and runs android (and what if that device happened to be really popular in the future?)<div>
<br></div><div>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</div>
<div><br></div><div>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 &quot;guaranteed&quot; to work on any android device, ARM or not</div>
<div><br></div><div>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.</div>
<div><div><br><div class="gmail_quote">On Sun, Aug 8, 2010 at 1:14 AM, Daniel Peebles <span dir="ltr">&lt;<a href="mailto:pumpkingod@gmail.com">pumpkingod@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The Hummingbird is still ARM. ARM doesn&#39;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.<div><br></div>

<div>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&#39;t ARM on a device, it&#39;s almost certainly going to be Intel, these days. Sure, Android doesn&#39;t specify that this has to be the case, but realistically, it will be.<br>

<br><div class="gmail_quote"><div><div></div><div class="h5">On Sun, Aug 8, 2010 at 3:08 AM, Mathew de Detrich <span dir="ltr">&lt;<a href="mailto:deteego@gmail.com" target="_blank">deteego@gmail.com</a>&gt;</span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
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 &quot;generic&quot; ASM branch for &quot;mobile&quot; 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)<div>


<br></div><div>In my opinion the most &quot;reliable&quot; 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.</div>


<div><br>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 &quot;official&quot; 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&#39;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 &quot;code&quot;) which would give more freedom for GHC to generate code more suited to Haskell</div>


<div><br></div><div>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)</div>


<div><br></div><div>As Don mentioned through, we need a java runtime for GHC.</div>
<br></div></div><div class="im">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div></div>