How to get started with a new backend?

Simon Peyton-Jones simonpj at microsoft.com
Mon Jan 28 12:21:21 CET 2013


I would like to explore making a backend for .NET. I've done a lot of background reading about previous .NET and JVM attempts for Haskell. It seems like several folks have made significant progress in the past and, with the exception of UHC, I can't find any code around the internet from the previous efforts. I realize that in total it's a huge undertaking and codegen is only one of several significant hurdles to success.

Someone should start a wiki page about this!  It comes up regularly.  (That doesn't mean it's a bad idea; just that we should share wisdom on it.)  Maybe there is one, in which case perhaps it could be updated?

Some thoughts (which, if someone would like to transfer these to the wiki page, perhaps in more coherent form):

*        Check out Frege.  Maybe others.  I think several folk are working on .NET or JVM projects.

*        Do you want to inter-operate with .NET, or compile to .NET bytecode.  These are very different?  I'll assume the latter.

*        Do you want to compile to verifiable .NET bytecode?  This is hard.  GHC's type system is more expressive than .NET's in many ways (higher kinded type variables, kind polymorphism...).  And less expressive in others (sub-typing). Compiling to verifiable bytecode would require lots of run-time type-tests (which we know will succeed) to reassure .NET that it's all kosher.  Figuring out how to minimise these tests would be a challenge in itself.

*        And of course this affects whether you can go via C#, since that requires the program to be well typed in the .NET sense.

*        Do you want simply to run Haskell programs on .NET or do you want Haskell programs to call .NET libraries?  I assume the latter.  But that means that .NET types must be manifested somehow as Haskell types.   A big issue is how much of .NET's type system you want to suck into Haskell.  A stressful example: can you define in Haskell a type that sub-classes an imported .NET type.

Daan and Mark and Sigbjorn and I wrote papers about this stuff. Look at the papers under "Foreign language integration" on http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html.  Oh, and this: http://research.microsoft.com/en-us/um/people/simonpj/papers/oo-haskell/index.htm

*        I'd be inclined to start from Core rather than STG, perhaps the output of CorePrep.  STG is a bit encrusted (though we're about to simplify it a bit).  But honestly they are pretty similar.

Cmm would be a bad choice. It's far too low level.

*        Another major issues is that of primops (prelude/primops.txt.pp).  Things like add Int# or Float# are fine, but what about forking a thread, or throwing an exception?

o   One possibility is to try to emulate them all.  I have no idea how hard that would be, but GHC's I/O libraries rely heavily on lightweight concurrency.

o   Another is to trim the list of PrimOps, and only support some of them.  That's easier, but you'd have to dump a lot of the 'base' package (particularly I/O) and re-implement it using the .NET libraries instead.



I hope this is of at least some use

Simon


From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Jason Dagit
Sent: 28 January 2013 01:16
To: glasgow-haskell-users at haskell.org
Subject: How to get started with a new backend?

I would like to explore making a backend for .NET. I've done a lot of background reading about previous .NET and JVM attempts for Haskell. It seems like several folks have made significant progress in the past and, with the exception of UHC, I can't find any code around the internet from the previous efforts. I realize that in total it's a huge undertaking and codegen is only one of several significant hurdles to success.

I would like to get a very, very, very simple translation working inside GHC. If all I can compile and run is fibonacci, then I would be quite happy. For my first attempt, proof of concept is sufficient.

I found a lot of good documentation on the ghc trac for how the compilation phases work and what happens in the different parts of the backend. The documentation is excellent, especially compared to other compilers I've looked at.

When I started looking at how to write the code, I started to wonder about the "least effort" path to getting something (anything?) working. Here are some questions:
  * Haskell.NET seems to be dead. Does anyone know where their code went?
  * Did lambdavm also disappear? (JVM I know, but close enough to be useful)
  * Would it make sense to copy&modify the -fvia-C backend to generate C#? The trac claims that ghc can compile itself to C so that only standard gnu C tools are needed to build an unregistered compiler. Could I use this trick to translate programs to C#?
  * What stage in the pipeline should I translate from? Core? STG? Cmm?
  * Which directories/source files should I look at to get familiar with the code gen? I've heard the LLVM codegen is relatively simple.
  * Any other advice?

Thank you in advance!
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20130128/3fe77ff3/attachment.htm>


More information about the Glasgow-haskell-users mailing list