Embedded funcional programming?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Embedded funcional programming?

Maurí­cio CA
Hi, all,

I've beeing working with some people who do programming for
wireless devices. 100% of their code uses C, and I would like to
show them nice things they could do with funcional programming
(not necessarily Haskell. I believe, say, Standard ML could be
also very nice.)

I'm new to this, so the only problems I see are finding a compiler
that targets the platform (ARM7, for instance, or others) and
uploading the compiled firmware to the device.

Do you think this can be a straightforward path?

Thanks,

Maurício

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Embedded funcional programming?

Stephen Tetley-2
Hello Maurício


> I'm new to this, so the only problems I see are finding a compiler
> that targets the platform (ARM7, for instance, or others) and
> uploading the compiled firmware to the device.


You might find that the extra RAM requirements for a non-C language
becomes a problem - especially when it manifestly translates to extra
euros/dollars on the "BOM" costs (aka bill-of-materials).

Best wishes

Stephen
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Embedded funcional programming?

Jeffrey Scofield
In reply to this post by Maurí­cio CA
Maurí­cio CA <[hidden email]> writes:

> I've beeing working with some people who do programming for
> wireless devices. 100% of their code uses C, and I would like to
> show them nice things they could do with funcional programming
> (not necessarily Haskell. I believe, say, Standard ML could be
> also very nice.)
>
> I'm new to this, so the only problems I see are finding a compiler
> that targets the platform (ARM7, for instance, or others) and
> uploading the compiled firmware to the device.
>
> Do you think this can be a straightforward path?

With one other guy, I got OCaml working on the iPhone.  I don't
know that I'd call it straightforward, exactly.  The hardest part was
the interface to the existing libraries (Cocoa Touch).  This
included making some tweaks to the OCaml ARM back end so
that its register and calling conventions match what is used by
Apple's C and ObjC compilers.

At any rate, we were really very happy with the results until
a week or so ago when Apple apparently saw fit to forbid the
use of languages other than C, C++, and ObjC.

Your associates might have a much easier time if they're working
closer to bare metal.  If their hardware is up to it, I would really
suggest looking into it.

As a side comment, I haven't noticed any reaction in the
Haskell/iPhone community about Apple's recent policy change.

Regards,

Jeffrey Scofield
Seattle

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Darrin Chandler
On Sat, Apr 17, 2010 at 08:21:06PM -0700, Jeffrey Scofield wrote:
> As a side comment, I haven't noticed any reaction in the
> Haskell/iPhone community about Apple's recent policy change.

I've seen some reaction in other language communities, and I'm sure you
can imagine what it's like. Understandable sentiments, but not very
productive.

I recently purchased an Android phone and spent a little time looking
around to see if Haskellers were doing anything there, but no luck so
far. Has anyone here done anything with Android?

--
Darrin Chandler            |  Phoenix BSD User Group  |  MetaBUG
[hidden email]   |  http://phxbug.org/      |  http://metabug.org/
http://www.stilyagin.com/  |  Daemons in the Desert   |  Global BUG Federation
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

James Britt
Darrin Chandler wrote:

> On Sat, Apr 17, 2010 at 08:21:06PM -0700, Jeffrey Scofield wrote:
>> As a side comment, I haven't noticed any reaction in the
>> Haskell/iPhone community about Apple's recent policy change.
>
> I've seen some reaction in other language communities, and I'm sure you
> can imagine what it's like. Understandable sentiments, but not very
> productive.
>
> I recently purchased an Android phone and spent a little time looking
> around to see if Haskellers were doing anything there, but no luck so
> far. Has anyone here done anything with Android?

I've done a simple app in Java, and some experiments with JRuby.

I've not done any thing Android with Haskell, but would love to give it
a shot.  However, I don't know where to begin.


James


--

Neurogami - Smart application development

http://www.neurogami.com

[hidden email]




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Embedded funcional programming?

Ivan Lazar Miljenovic
In reply to this post by Jeffrey Scofield
Jeffrey Scofield <[hidden email]> writes:
> As a side comment, I haven't noticed any reaction in the
> Haskell/iPhone community about Apple's recent policy change.

>From the Haskell reddit:

http://www.reddit.com/r/haskell/comments/bouxy/more_on_the_iphone_applications_must_be/
http://www.reddit.com/r/haskell/comments/boc3t/does_this_mean_we_cant_use_haskell_for_iphone/

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Liam O'Connor
In reply to this post by James Britt
Our best bet is to compile to ARM native code and then use the NDK to
talk to the Java APIs.
Cheers.
~Liam
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Embedded funcional programming?

Patai Gergely
In reply to this post by Maurí­cio CA
Hello,

> I'm new to this, so the only problems I see are finding a compiler
> that targets the platform (ARM7, for instance, or others) and
> uploading the compiled firmware to the device.
I used Hume [1] to program Mindstorms NXT robots (ARM7) as well as Tmote
Sky sensors (MSP430). In both cases I ported the HAM virtual machine and
interpreted bytecode. In the case of NXT I used the hardware layer of
leJOS [2], simply ripping out the JVM and replacing it with HAM. As for
the Tmote Sky, the VM sat on top of Contiki [3], so it was possible to
send HAM bytecode over the air, and the sensor would intercept it, stop
the currently running program and execute the new one. Hume can also be
compiled directly to C, and I got it to run on a home-brew LPC2106 based
embedded platform (also with an ARM7 core) we use in education. The main
problem was the size of the generated code. See [4] for details.

My overall impression is that Hume could be a very nice language to
program embedded systems with, given proper tool support (for starters,
it's really crying for a visual editor) and a high-quality compiler.

Gergely

[1] http://www-fp.cs.st-andrews.ac.uk/hume/index.shtml
[2] http://lejos.sourceforge.net/
[3] http://www.sics.se/contiki/
[4] http://www-fp.cs.st-andrews.ac.uk/hume/papers/pg_thesis/

--
http://www.fastmail.fm - Email service worth paying for. Try it for free

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Embedded funcional programming?

Malcolm Wallace
In reply to this post by Stephen Tetley-2
>> I'm new to this, so the only problems I see are finding a compiler
>> that targets the platform (ARM7, for instance, or others) and
>> uploading the compiled firmware to the device.
>
>
> You might find that the extra RAM requirements for a non-C language
> becomes a problem - especially when it manifestly translates to extra
> euros/dollars on the "BOM" costs (aka bill-of-materials).

About 15 years ago, I wrote my PhD Thesis on the topic of "Functional  
Programming and Embedded Systems".
     ftp://ftp.cs.york.ac.uk/pub/malcolm/thesis.html

Back then, I was using the Gofer interpreter (a forerunner of Hugs),  
compiling Haskell to bytecode, and targetted at the M68000.  Bytecode  
is one important way to reduce the RAM requirements.  An interpreter  
can also be quite parsimonious with heap allocation - as I recall, I  
extended the embedded board from 256kb of RAM to 768kb (yes, note  
kilobytes, not Mb) in anticipation of heap pressure, but in the end  
came nowhere near needing all of that.

Regards,
     Malcolm

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Don Stewart-2
In reply to this post by Liam O'Connor
liamoc:
> Our best bet is to compile to ARM native code and then use the NDK to
> talk to the Java APIs.
> Cheers.
> ~Liam

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)
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Tom Davies-6
In reply to this post by Darrin Chandler

On 18/04/2010, at 1:39 PM, Darrin Chandler wrote:
> I recently purchased an Android phone and spent a little time looking
> around to see if Haskellers were doing anything there, but no luck so
> far. Has anyone here done anything with Android?

Not Haskell, but FP on Android: http://www.kablambda.org/blog/2009/07/27/functional-programming-on-android/

I don't have an Android, so all I did was a 'hello world' to see if it could be done.

Tom_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Embedded funcional programming?

Stefan Monnier
In reply to this post by Jeffrey Scofield
> As a side comment, I haven't noticed any reaction in the
> Haskell/iPhone community about Apple's recent policy change.

The stricter they make it, the better, since it hopefully gets us closer
to the point where people will see that they should stay the heel away
from any such handcuffs,


        Stefan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Liam O'Connor
In reply to this post by Don Stewart-2
On 19 April 2010 05:29, Don Stewart <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Liam O'Connor
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 <[hidden email]> wrote:

> On 19 April 2010 05:29, Don Stewart <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> wrote:
>> On 19 April 2010 05:29, Don Stewart <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Don Stewart-2
In reply to this post by Liam O'Connor
liamoc:

> On 19 April 2010 05:29, Don Stewart <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

scooter.phd@gmail.com
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 <[hidden email]> wrote:
liamoc:
> On 19 April 2010 05:29, Don Stewart <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Don Stewart-2

Only problem is rewriting the GHC runtime in Java... :-)

-- Don

scooter.phd:

> 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 <[hidden email]> wrote:
>
>     liamoc:
>     > On 19 April 2010 05:29, Don Stewart <[hidden email]> 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
>     [hidden email]
>     http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Mathew de Detrich
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Daniel Peebles
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12