status of template haskell + cross compiling plans for 7.8?

[Simon Peyton-Jones]

Luite

Via HWN I read your GHCJS post<http://weblog.luite.com/wordpress/?p=14&date=2013-06-03> this morning.   Great work.

It's silly that you should need to patch GHC.  One alternative is to absorb your patch<https://github.com/ghcjs/ghcjs.github.com/blob/master/patches/ghc-ghcjs.patch>, or a successor.  I think it mostly just extends the FFI and target types with new cases.  The patch doesn't actually include any JS generation, so I'm far from sure how that happens.

But it would be even better to make it easier to people to add new backends without modifying GHC, via some kind of plugin interface.

I'm underwater with POPL right now, but do discuss on ghc-devs any details that would help you.

Simon

From: ghc-devs-bounces at haskell.org [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Luite Stegeman
Sent: 14 June 2013 21:12
To: Carter Schonwald
Cc: ghc-devs at haskell.org
Subject: Re: status of template haskell + cross compiling plans for 7.8?


We've had TH working in GHCJS [1] for a few months now, compiling once for the host platform, and once for the target.

Our GHCJS GHC patch [2] (that we hope to get merged before 7.8) adds, among other things, WayCustom to the Ways in DynFlags, which just adds a custom token to the filename extension. This, uhm, way (sorry), we generate native files ".o" and ".hi", and ArchJavaScript files ".js_o" and ".js_hi" in the same directory. TH always uses the native files.

We had to patch Cabal [3] to install the extra files (but we needed to patch Cabal anyway to add the GHCJS compiler flavour), but other than that it seems to work. GHC loads the native .a files when running TH, we do our own JavaScript linking.

Another thing we patched is the GHC.Prim interface, which is different for 32 and 64 bit code. When we generate code for ArchJavaScript, we load a custom GHC.Prim for 32 bit, while we use the regular GHC.Prim when we generate the native code.

It's all a bit hacky, but maybe this approach can be used as a basis for getting TH working in a real GHC. We could take some shortcuts to make a pseudo-mutltitarget compiler by just tacking an extra code generator onto a non-crosscompiling GHC. I'd be happy to help or discuss to make it more general.

Luite

[1] https://github.com/ghcjs / http://weblog.luite.com/wordpress/?p=14
[2] https://github.com/ghcjs/ghcjs.github.com/blob/master/patches/ghc-ghcjs.patch
[3] https://github.com/ghcjs/ghcjs.github.com/blob/master/patches/cabal-ghcjs.patch

On Thu, Jun 13, 2013 at 11:43 PM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
Hey All,
Whats the story planned for template haskell + cross compiler support come ghc 7.8?
I understand theres a lot of Template Haskell design underway, some of which will help support tools like Manuel's Inline-Objective-C work. Does this mean that factored out within this reorganization is a better story for cross compilation?

Especially since one kill "app" for the Inline-Objective-C template haskell work would be writing IOS applications. Though I guess that also touches on the need to sort out supporting "FAT" ARM binaries too, right?

This intersects with a few different large subsets of tickets, so i'm not sure if any single ticket is the right fora for this question.

thanks!
-Carter

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130704/8bb5cbb5/attachment-0001.htm>