[Haskell-cafe] compilation to C, not via-C

Ryan Ingram ryani.spam at gmail.com
Fri Apr 24 13:14:03 EDT 2009


I work on graphics engine/pipeline for Spore at Electronic Arts, and
I've had some similar thoughts as you.  But I don't think this is the
right path for games right now.

The "via C" compiler does generate C code that it puts through GCC.
There is a post-process step after the code is converted to assembly
by GCC (see http://hackage.haskell.org/trac/ghc/wiki/Commentary/EvilMangler);
a perl script rewrites the calling convention of all the functions to
optimize for the code that GHC generates.  From what I understand,
performance is significantly worse without the mangler.  So
interoperability of the generated C-from-Haskell code directly with
your C code is tricky at best.

However, the generated code is only half the story.  The other half is
that you need the Haskell runtime to go with your program.  This
manages the garbage collector, multithreading-support, etc.  As a
middleware developer, I'm sure you're aware that it would be quite
difficult to sell "you need this big runtime with unpredictable memory
requirements" to your potential customers.

That said, don't lose hope.  Lots of Haskell development is being done
for embedded systems, and other things at a similar level as to what
you want.  But what these systems generally do is write a custom monad
that *outputs* code.  You can look at some of the CUFP2008 talks about
this topic (http://cufp.galois.com/2008/schedule.html); I recommend
"Controlling Hybrid Vehicles with Haskell".  There was another talk
about compiling Haskell into Excel spreadsheets for finance, but I
can't seem to locate it right now.

The basic strategy is to encapsulate all your operations in a monad,
then write "code generation" that converts the results into C code
which you can then compile and ship.  Unless you're willing to make
the jump to Haskell as a host language with FFI outcalls to native
code, I think this is the right strategy right now.

Good luck, and keep us informed how it goes.  I expect to hear from
you at CUFP next year :)

   -- ryan

P.S. I saw some demos of Geomerics products; it looks pretty cool.
What are you guys up to now?

On Fri, Apr 24, 2009 at 9:36 AM, Sam Martin <sam.martin at geomerics.com> wrote:
> Hi Everyone,
> It appears the GHC compiler (and other) compile Haskell *via-C* but not
> *to C*. I've never really understood why there isn't a C generation
> option, or why GDC ships with its own compulsory copy of gcc.
> I work in Games middleware, and am very interested in looking at how
> Haskell could help us. We basically sell C++ libraries. I would like to
> be able to write some areas of our libraries in Haskell, compile the
> Haskell to C and incorporate that code into a C++ library.
> As an example, I think Haskell would be great at doing geometry
> processing. I don't want to write all our geometry processing code in
> C++. I'd prefer to write a big chunk of it in Haskell and wrap that in
> C++.
> The pattern here is using Haskell to generate C code as the end result.
> It sounds like this end result isn't that far out of reach, so I'm
> curious as to why it doesn't appear to be possible at present.
> Have I missed something? Is there some fundamental reason this isn't
> possible? Has anyone wished for this before?
> Any thoughts/help much appreciated,
> Thanks,
> Sam Martin
> ---
> Lead Programmer
> www.geomerics.com
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list