GHC Alpha port?

[Ken Shan]

--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2001-07-13T16:55:57-0400, Ken Shan wrote:
> Current hurdle: ghc-inplace doesn't seem to be finding its .hi files
> for basic stuff.
>=20
>     puffin:~$ cat Main.hs
>     module Main where
>     import IO
>     main =3D putStrLn "Hello, world!"
>=20
>     puffin:~$ u/ghc-port/alpha/ghc/compiler/ghc-inplace Main.hs
>     Main.hs:1:
>         failed to load interface for `Prelude':
>             Could not find interface file for `Prelude'
>=20
>     Main.hs:2:
>         failed to load interface for `IO':
>             Could not find interface file for `IO'

This problem was because struct dirent differs between i386-linux and
alpha-osf3.  I fixed it by running the intermediate C program
generated by hsc2hs remotely on our alpha machine instead of locally
on our linux machine.

"Hello, world!" works now!  Yay!

So far, I've discovered 3 reasons why .hc files are not entirely
portable across platforms.

 1. ghc/includes/MachDeps.h, which is #included by some Haskell source
    files, in turn #includes ghc/includes/config.h, which differs from
    platform to platform.

    SOLUTION: Modify MachDeps.h to #include the config.h from
    alpha-osf3, even when compiling on i386-linux.

 2. The .hs file produced by hsc2hs differs from platform to platform,
    because the intermediate C program it generates necessarily
    behaves differently on each platform.

    SOLUTION: Add "--keep-tmp-files" flag to hsc2hs.  Run the
    intermediate C program over on alpha-osf3.

 3. Liveness bitmaps are of different width (32 bits vs 64 bits)
    between platforms, and the compiler generates different HC code
    based on the width.

    SOLUTION: Make the compiler generate platform-independent HC code
    that uses newly defined preprocessor macros to switch between
    32-bit and 64-bit liveness bitmaps at C compilation time.

These fixes (especially #1) make me uneasy about the bootstrapping
process.  Here's my current limited understanding of the making of HC
files:

 a. First we use the existing GHC to compile a new compiler (that
    produces unregisterised code)

 b. Second we use the new compiler to compile a new library (keeping
    the unregisterised HC files)
    -- This new library is compiled for use on alpha-osf3, not
       i386-linux, in terms of issues (1) and (2) above.

 c. Third we use the new compiler from (a), in conjuction with the new
    library from (b), to compile a doubly new compiler (that produces
    unregisterised code) (keeping the unregisterised HC files)
    -- This doubly new compiler is compiled for use on alpha-osf3, not
       i386-linux, in terms of issues (1) and (2) above.

 d. Finally we ship the HC files kept from steps (b) and (c) for use
    on the target platform

Note that, in step (c), we run the i386-linux compiler from (a) with
the alpha-osf3 library from (b).  The library produced in (b) is
incorrect as i386-linux code, but that's okay because all we want from
(b) are the HC files anyway.  Consequently, the doubly new compiler
produced in (c) is also incorrect as i386-linux code.  That's again
okay because all we really want from step (c) are the HC files anyway.
Just to make sure, though, could you please confirm the following:?

    In step (c), the once-new compiler uses (b) only as data, not as
    code.  In other words, even though (b) is incorrect as i386-linux
    code (and so (c) is incorrect as i386-linux code), the HC files
    produced in (c) are still perfectly correct as alpha-osf3 code.

--=20
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
See the sun in the midst of the rain.=20
Scoop clear water from the heart of the fire.

--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7UjNSzjAc4f+uuBURAtoeAKC2jdFqKFxWeis+LY+btf5XBR6stwCfe466
DsJhvDMz9z2p/GchswqNKrc=
=loyd
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--