stegeman at gmail.com
Fri Jan 25 13:37:22 CET 2013
I've been working on GHCJS  for a while and am trying to get it to
work on 64 bit GHC.
A quick background: GHCJS uses the GHC API to generate STG, which it
the integer-gmp, base and ghc-prim libraries and supports many GHC
features, including arrays and threading.
point. With some tricks (using bitwise operators) it's possible to get
reasonable 32 bit integer emulation out of it, but emulating 64 bit
integers would be very slow. Therefore, if we compile Haskell to
Now this is a problem, with GHC 7.6 and lower, generated STG depended
on the word size of the host, so it was simply impossible to do this
with a 64 bit host. In HEAD, wORD_SIZE_IN_BITS is now in DynFlags, so
I decided to have another go. I'm aiming for the following procedure
to install GHCJS and build a package:
# cabal install ghcjs -- installs `ghcjs`, `ghcjs-boot`, `ghcjs-pkg`,
# ghcjs-boot -- build ghc-prim, integer-gmp, base for
GHCJS and register them in its package db
# ghcjs-cabal install myPackage -- cabal wrapper that uses ghcjs instead of ghc
GHCJS instructs the GHC API to build 32 bit code  and sets
preprocessor definitions so that libraries also expect 32 bit code.
Library patches include PrimOpWrappers in ghc-prim, which is generated
from the 32 bit primops. But here's the problem: When typechecking
PrimOpWrappers, the GHC API appears to use its own built-in types for
everything in GHC.Prim, and there are differences between 32 bit and
64 bit (for example popCnt64# :: Word64# -> Word# on 32 bit, :: Word#
-> Word# on 64), so you get lots of errors.
Now I'm wondering, is there a way around this, or would it be
reasonable to modify GHC to somehow have the primop types in DynFlags,
instead of them being hardcoded in the compiler?
 https://github.com/ghcjs/ghcjs (I'm mostly working in the Gen2
branch, an experimental faster code generator)
More information about the Glasgow-haskell-users