RFC: Changes to help GHCJS, GHC API multi-target cross compile

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Changes to help GHCJS, GHC API multi-target cross compile

Luite Stegeman
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/src-bin/Compiler/Main.hs#L544
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-custom-way.patch
Type: application/octet-stream
Size: 3110 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/1c37cdab/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-primiface-override.patch
Type: application/octet-stream
Size: 2312 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130208/1c37cdab/attachment-0001.obj>

Reply | Threaded
Open this post in threaded view
|

Changes to help GHCJS, GHC API multi-target cross compile

Simon Peyton Jones
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 at haskell.org [mailto:ghc-devs-bounces at haskell.org]
| On Behalf Of Luite Stegeman
| Sent: 08 February 2013 18:53
| To: ghc-devs at 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