ARM is now a fully supported target platform for GHC Haskell | Hacker News Reader

ARM is now a fully supported target platform for GHC Haskell

haskell.org

115 pointsdons27 comments

I just got my Raspberry Pi in the mail last week and was disappointed about the Haskell support. Now I'm ecstatic!

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...

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

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

The guidelines say nothing about any particular programming languages.

No.

Knowing the Haskell community, they could probably convert GHC Core into idiomatic Objective-C if they really wanted to, but it's not necessary. RubyMotion and other platforms are accepted because they stick to Apple's guidelines. The same would go for a GHC-iPhone platform.

iPhone Monad, anyone?

Why would one need to, GHC can already compile Haskell/Core to C? But as you say, it's not a violation of Apple's terms anymore.

Because compiling to C would be too easy.

Nope, not anymore. http://daringfireball.net/2010/09/app_store_guidelines

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

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_...

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

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://weblog.haskell.cz/pivnik/building-a-shared-library-in...

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.

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.

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.

In theory, yes. In practice, no. The C emitted from compilers is usually an awful mess that looks like Assembly code and it might not have sane function entry points so it could be used as a library. Then you need to get the runtime system (garbage collector, etc) up and running to run your code. It's by no means impossible but it's very impractical.

Historically, C was used to implement many (functional) programming languages because it provided a convenient compiler back end and a well-defined intermediate representation between the front end and the back end. Not because you could compile to C and use your code from C.

Fortunately, GHC can build shared libraries on some platforms, which makes it fairly easy to expose Haskell functions to C:

- Using the FFI one can specify foreign exports.

- The runtime and garbage collector can be initialized/deinitialized by adding an object file that uses gcc's constructor/destructor attributes.

- Multiple calls to hs_init (one for each library) are allowed, as long as they are balanced by hs_exits.

- It's ok to have multiple root modules.

Indeed, the FFI in GHC is one of the best ones out there. It makes it convenient to call C from Haskell and vice versa(!). I wish every language had an FFI and RTS that good!

Saw this recently. https://github.com/ghc-ios/ghc/wiki

It looks like there is no prebuilt package of interfaces with iOS so still a ways to go. Still great work though.

Cross compilation is not yet supported. You want to build on osx/intel and target ios/arm. Not yet. ghc still needs to target the platform it was built on.

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?

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)

What you describe is the actual procedure of switching threads. What cheatercheater describes is the mechanics of initiating this switch. You have "checkpoints" in the thread, where the thread finds out if it is to be descheduled and performs a conditional branch to the code that does what you described. Apparently in GHC code, there is no conditional branch instruction, an unconditional jump is generated on the fly, probably to avoid branch mispredictions.

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

> 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.

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

Reply on news.ycombinator.com