
ARM is now a fully supported target platform for GHC Haskell - dons
http://www.haskell.org/pipermail/haskell-cafe/2012-June/101704.html
======
Cieplak
I just got my Raspberry Pi in the mail last week and was disappointed about
the Haskell support. Now I'm ecstatic!

~~~
djhworld
Don't get too excited just yet, here are my experiences so far attempting to
get GHC 7.4 on my R-Pi

[http://www.reddit.com/r/haskell/comments/u7cwv/some_observat...](http://www.reddit.com/r/haskell/comments/u7cwv/some_observationsproblems_of_getting_haskellghc/)

------
james4k
So...what would be needed to see native Haskell iOS apps? :)

~~~
eru
Doesn't Apple still forbid programs written in anything apart from Objective
C, JavaScript (and a third language, that I don't remember)?

~~~
shriphani
You can always compile scheme / haskell etc to C and then use it as a library.
(gambit-scheme users do this).

~~~
danieldk
Indeed. I did this with one program: I wrote some number crunching code in
Haskell, and exposed some functions to C via the FFI. Then I wrote the user
interface in Cocoa/Objective-C. The primary thing that requires some though is
how to pass data between C and Haskell. You usually end up
marshaling/unmarshaling some structs:

[http://www.haskell.org/haskellwiki/FFICookBook#Working_with_...](http://www.haskell.org/haskellwiki/FFICookBook#Working_with_structs)

~~~
Dn_Ab
Sounds quite interesting. Do you have a write up about this anywhere? Is the
gain rom Haskell worth the impedance mismatch of cross communication?

~~~
danieldk
_Do you have a write up about this anywhere?_

I used the following references:

[http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/ffi-g...](http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/ffi-
ghc.html)

[http://weblog.haskell.cz/pivnik/building-a-shared-library-
in...](http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell/)

I have just put up a small-ish example using my approx-rand-test package
(which implements approximate randomization tests):

<https://github.com/danieldk/haskell-library-example/>

 _Is the gain rom Haskell worth the impedance mismatch of cross
communication?_

I guess it depends on how much you love Haskell ;), and the usage scenario. I
think using Haskell's FFI in this direction is especially attractive if you
prefer to write most code in Haskell, but need some functionality that does
not map naturally to a pure functional language (such as GUIs in Cocoa). If
you want to mix a lot of imperative and functional code seamlessly, F#/C# or
Scala/Java are probably better options.

~~~
Dn_Ab
Thanks what's the size like? The last time I built a Haskell application it
was quite large. This is more of an issue for mobile apps.

FWIW I've done Scala/Java+Android and WP7+C#/F#, interestingly Wp7 is by far
the easiest mobile to get a good functional language running on.

~~~
danieldk
_Thanks what's the size like? The last time I built a Haskell application it
was quite large._

4969KB with the runtime and package dependencies linked in the dynamic library
(Darwin, 64-bit). Since I do not have dynamic libraries of its dependencies
installed, I cannot quickly try a completely dynamic version...

 _interestingly Wp7 is by far the easiest mobile to get a good functional
language running on._

I purchased a Windows Phone last week (iOS user here) to see how it works, and
I am surprised how good the integration is.

------
cheatercheater
The x86 and x64 have interesting hacks in the asm they generate. For example,
thread switching is done not by a conditional jump, but by self-modifying code
(there's some nops in the main loop, and they get overwritten with a jmp when
it's time to preempt). What cool architecture-specific hacks does the ARM
version use?

~~~
exDM69
I assume you refer to the co-operative thread switching done by the GHC
runtime to achieve co-operative multitasking with Haskell's green threads? I
thought this was done by trashing all the registers (pushing live regs to
stack) in the compiler back end and then swapping the stack pointer in the
runtime. Are you sure about the nop's in the main loop?

I, too, would like to know how this works on ARM and other non-x86 platforms.
Do they even have this feature supported on ARM? (ie. compile with ghc
--threaded and then add RTS parameters as needed when executing)

~~~
dons
GHC uses pre-emptive thread switching, not co-operative thread switching.
Threads are forced by the runtime to be switched out -- they have no choice in
the matter -- based on rts interrupts.

Typically, threads will be switched when they allocate.

See

<https://github.com/ghc/ghc/blob/master/rts/Schedule.c#L208>

and for low-level fun:

<https://github.com/ghc/ghc/blob/master/includes/stg/SMP.h>

~~~
exDM69
> GHC uses pre-emptive thread switching, not co-operative thread switching. >
> Threads may be switched when they allocate.

If threads are scheduled in and out when they allocate memory or are about to
issue a possibly blocking system call, it's called co-operative
multithreading, isn't it?

If the thread execution was stopped using external means like a timer
interrupt, that would be pre-emptive. Some definitions of pre-emptive involve
the ability to stop a lower priority thread in favor of a higher priority
thread that becomes ready when a syscall is finished.

The best I understand the situation, Haskell's green threads voluntarily (co-
operatively) give up their time slice (for another green thread) when
allocating memory or doing I/O. Haskell's green threads run on top of several
native threads that are pre-emptively scheduled by the operating system.

Please correct me if I'm wrong.

~~~
dons
The threads do not volunteer. They are pre-empted by an external authority -
the runtime system. They have no choice in the matter.

