ANN / CFP - LLVM bindings for Haskell

This is an early release of Haskell bindings for the popular LLVM compiler infrastructure project. If you don't know what LLVM is, it's a wonderful toybox of compiler components, from a complete toolchain supporting multiple architectures through a set of well-defined APIs and IR formats that are designed for building interesting software with. The official LLVM home page is here: http://llvm.org/ The Haskell bindings are based on Gordon Henriksen's C bindings. The C bindings are almost untyped, but the Haskell bindings re-add type safety to prevent runtime crashes and general badness. Currently, the entire code generation system is implemented, with most LLVM data types supported (notably absent are structs). Also plugged in is JIT support, so you can generate code at runtime from Haskell and run it immediately. I've attached an example. Please join in the hacking fun! darcs get http://darcs.serpentine.com/llvm If you want a source tarball, fetch it from here: http://darcs.serpentine.com/llvm/llvm-0.0.2.tar.gz (Hackage can't host code that uses GHC 6.8.2's language extension names yet.) There's very light documentation at present, but it ought to be enough to get you going.

bos:
This is an early release of Haskell bindings for the popular LLVM compiler infrastructure project.
If you don't know what LLVM is, it's a wonderful toybox of compiler components, from a complete toolchain supporting multiple architectures through a set of well-defined APIs and IR formats that are designed for building interesting software with.
The official LLVM home page is here:
The Haskell bindings are based on Gordon Henriksen's C bindings. The C bindings are almost untyped, but the Haskell bindings re-add type safety to prevent runtime crashes and general badness.
Currently, the entire code generation system is implemented, with most LLVM data types supported (notably absent are structs). Also plugged in is JIT support, so you can generate code at runtime from Haskell and run it immediately. I've attached an example.
Please join in the hacking fun!
darcs get http://darcs.serpentine.com/llvm
If you want a source tarball, fetch it from here:
Woot. More codegen fun!
(Hackage can't host code that uses GHC 6.8.2's language extension names yet.)
{-# LANGUAGE XYZ #-} pragmas? If so, I'm pretty sure they're supported, since xmonad uses them, and is on hackage. -- Don

Don Stewart wrote:
(Hackage can't host code that uses GHC 6.8.2's language extension names yet.)
{-# LANGUAGE XYZ #-} pragmas? If so, I'm pretty sure they're supported, since xmonad uses them, and is on hackage.
Language pragmas in general are fine, but I believe I'm using a few that are new to Cabal 1.2.3.0, which isn't being used to power Hackage yet. Or thus quoth Duncan.

bos:
Don Stewart wrote:
(Hackage can't host code that uses GHC 6.8.2's language extension names yet.)
{-# LANGUAGE XYZ #-} pragmas? If so, I'm pretty sure they're supported, since xmonad uses them, and is on hackage.
Language pragmas in general are fine, but I believe I'm using a few that are new to Cabal 1.2.3.0, which isn't being used to power Hackage yet. Or thus quoth Duncan.
Ah yes, good point! There are some that can't be placed in the .cabal file -- though they can go in the .hs file (with -fglasgow-exts in the .cabal as needed). -- Don

In message <20080103185838.GC4775@scytale.galois.com> Don Stewart
bos:
Don Stewart wrote:
(Hackage can't host code that uses GHC 6.8.2's language extension names yet.)
{-# LANGUAGE XYZ #-} pragmas? If so, I'm pretty sure they're supported, since xmonad uses them, and is on hackage.
Language pragmas in general are fine, but I believe I'm using a few that are new to Cabal 1.2.3.0, which isn't being used to power Hackage yet. Or thus quoth Duncan.
Ah yes, good point!
There are some that can't be placed in the .cabal file -- though they can go in the .hs file (with -fglasgow-exts in the .cabal as needed).
Yes, this is what got fixed in Cabal-1.2.3.0 which comes with GHC-6.8.2 and is available on hackage for users of other GHC versions and other haskell implementations. Duncan

In message <20080104012308.GA4809@soi.city.ac.uk> Ross Paterson
On Thu, 03 Jan 2008 03:43:49 -0800, Bryan O'Sullivan wrote:
(Hackage can't host code that uses GHC 6.8.2's language extension names yet.)
It should be able to now.
Thanks very much Ross. BTW, I think we should put some HackageDB hacking and admin instructions on the hackage wiki so we don't have to pester you so much for this kind of routine admin stuff. Duncan

On Jan 3, 2008 3:43 AM, Bryan O'Sullivan
This is an early release of Haskell bindings for the popular LLVM compiler infrastructure project.
If you don't know what LLVM is, it's a wonderful toybox of compiler components, from a complete toolchain supporting multiple architectures through a set of well-defined APIs and IR formats that are designed for building interesting software with.
The official LLVM home page is here:
The Haskell bindings are based on Gordon Henriksen's C bindings. The C bindings are almost untyped, but the Haskell bindings re-add type safety to prevent runtime crashes and general badness.
Currently, the entire code generation system is implemented, with most LLVM data types supported (notably absent are structs). Also plugged in is JIT support, so you can generate code at runtime from Haskell and run it immediately. I've attached an example.
Please join in the hacking fun!
darcs get http://darcs.serpentine.com/llvm
If you want a source tarball, fetch it from here:
http://darcs.serpentine.com/llvm/llvm-0.0.2.tar.gz
(Hackage can't host code that uses GHC 6.8.2's language extension names yet.)
There's very light documentation at present, but it ought to be enough to get you going.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Maybe I am asking an uninformed n00b question but how come GHC has fvia-C and are also working on an asm backend. Is there any reason why they could not build off the work of LLVM (which supports various architectures) then ditch those two backends and call it a day? --ryan

Ryan Dickie wrote:
Maybe I am asking an uninformed n00b question but how come GHC has fvia-C and are also working on an asm backend. Is there any reason why they could not build off the work of LLVM (which supports various architectures) then ditch those two backends and call it a day?
You are not the first to think of it, and surely not the last! Whilst it's a very interesting idea, I believe there are reasons why it may not solve all our problems: http://www.haskell.org/pipermail/glasgow-haskell-users/2006-December/011794.... http://www.haskell.org/pipermail/glasgow-haskell-users/2006-December/011795.... and others in that thread. Jules
participants (6)
-
Bryan O'Sullivan
-
Don Stewart
-
Duncan Coutts
-
Jules Bean
-
Ross Paterson
-
Ryan Dickie