RFC: Changes to help GHCJS, GHC API multi-target cross compile
Hi all, I'm looking for comments on two minor patches that would greatly help GHCJS [1]. The goal is to make a cabal-installable GHCJS compiler that uses the GHC API to generate both JavaScript (always 32 bit) and native code (to run Template Haskell). This way we can release updates frequently and have an easy installation procedure for users. I have an experimental branch [2] that uses the patches below to make working compiler that can generate 32 bit JavaScript from a 64 bit host compiler, with working TH. 1. Add a Way for custom build tags. Since we generate code for two architectures, we need to make sure that we don't mix the native and JavaScript .hi files. Setting the buildTag manually in DynFlags does not work, because it gets reset every time a file is preprocessed (due to OPTIONS pragma handling). This patch adds an extra Way that just adds something to the build tag, it could be extended to also add custom program options and extras. 2. Make GHC.Prim interface overridable. Since JavaScript does not support 64 bit integers, we want to generate 32 bit code, even if our host platform is 64 bit. HEAD has wORD_SIZE_IN_BITS already configurable though DynFlags, but unfortunately the primop interface (GHC.Prim) is also platform dependent, some primops have a different type on a 64 bit system. This patch makes it possible for a GHC API user to supply a custom interface for GHC.Prim. It's rather hacky, requires an extra hs-boot file and requires the user to mess with the NameCache to make it work correctly [3]. Probably a stopgap measure until GHC supports multitarget cross compilation out of the box. Is there a better way of doing this? Luite [1] https://github.com/ghcjs [2] https://github.com/ghcjs/ghcjs/tree/gen2-64 [3] https://github.com/ghcjs/ghcjs/blob/1a84f82fa149b4e9510586c10864694efe7820bf...
I've had a look. As you say, the changes are modest. For (2), I'd like to see a Note [Overriding the GHC.Prim interface] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ with the field decl for sOverridePrimIface in DynFlags, with enough commentary to explain what is going on. In particular, this DynFlag field is never altered from the command line flags etc; it is only used via the GHC API. This point needs to be made so that we don't remove it again as dead code! Similarly (1): a Note with the CustomWay constructor Then I'm happy for Ian to commit, if Ian is happy too. Simon | -----Original Message----- | From: ghc-devs-bounces@haskell.org [mailto:ghc-devs-bounces@haskell.org] | On Behalf Of Luite Stegeman | Sent: 08 February 2013 18:53 | To: ghc-devs@haskell.org | Subject: RFC: Changes to help GHCJS, GHC API multi-target cross compile | | Hi all, | | I'm looking for comments on two minor patches that would greatly help | GHCJS [1]. The goal is to make a cabal-installable GHCJS compiler that | uses the GHC API to generate both JavaScript (always 32 bit) and native | code (to run Template Haskell). This way we can release updates | frequently and have an easy installation procedure for users. | | I have an experimental branch [2] that uses the patches below to make | working compiler that can generate 32 bit JavaScript from a 64 bit host | compiler, with working TH. | | 1. Add a Way for custom build tags. | Since we generate code for two architectures, we need to make sure that | we don't mix the native and JavaScript .hi files. Setting the buildTag | manually in DynFlags does not work, because it gets reset every time a | file is preprocessed (due to OPTIONS pragma handling). | This patch adds an extra Way that just adds something to the build tag, | it could be extended to also add custom program options and extras. | | 2. Make GHC.Prim interface overridable. | Since JavaScript does not support 64 bit integers, we want to generate | 32 bit code, even if our host platform is 64 bit. HEAD has | wORD_SIZE_IN_BITS already configurable though DynFlags, but | unfortunately the primop interface (GHC.Prim) is also platform | dependent, some primops have a different type on a 64 bit system. | | This patch makes it possible for a GHC API user to supply a custom | interface for GHC.Prim. It's rather hacky, requires an extra hs-boot | file and requires the user to mess with the NameCache to make it work | correctly [3]. Probably a stopgap measure until GHC supports multitarget | cross compilation out of the box. Is there a better way of doing this? | | Luite | | [1] https://github.com/ghcjs | [2] https://github.com/ghcjs/ghcjs/tree/gen2-64 | [3] | https://github.com/ghcjs/ghcjs/blob/1a84f82fa149b4e9510586c10864694efe78 | 20bf/src-bin/Compiler/Main.hs#L544
participants (2)
-
Luite Stegeman -
Simon Peyton-Jones