GHC Alpha port?

[Simon Marlow]

> 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'
>=20
> 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.

well tracked down.

> "Hello, world!" works now!  Yay!

:-)  great work!

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

There are quite a few bootstrapping and cross-compilation issues to be
resolved, and things got harder recently due to the use of hsc2hs to
generate some of the Haskell sources, which means the .hs files and
therefore the .hc files have platform-dependent content.  This is
somewhat unfortunate, but using careful cross-compilation techniques (as
you suggest) we can work around it.

I'm hoping that after this experience(!) we can do two things:

  - add some support for cross-compilation to the build system.
  - write down exactly what one needs to do to make this work, and
    put the instructions in the build system documentation.

>  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.
>=20
>     SOLUTION: Modify MachDeps.h to #include the config.h from
>     alpha-osf3, even when compiling on i386-linux.

Yep: for cross compilation of the .hc files, the first thing to do is
run ./configure on the target platform and take the output back to the
host.  In general, the sources and build system should make the
distinction between the host platform's config and the target platform's
config, but it's probably a lot of work to get this right.

>  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.
>=20
>     SOLUTION: Add "--keep-tmp-files" flag to hsc2hs.  Run the
>     intermediate C program over on alpha-osf3.

Yes.

>  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.
>=20
>     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.

yes, we should definitely do this.  The .hc files are supposed to be
independent of word size, so hopefully this is the only wrinkle.

> These fixes (especially #1) make me uneasy about the bootstrapping
> process.  Here's my current limited understanding of the making of HC
> files:
>=20
>  a. First we use the existing GHC to compile a new compiler (that
>     produces unregisterised code)
>=20
>  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.
>=20
>  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.
>=20
>  d. Finally we ship the HC files kept from steps (b) and (c) for use
>     on the target platform
>=20
> 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:?
>=20
>     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.

This should be the case, but we need to be careful about which settings
from the environment are used when compiling the compiler itself.  I can
see the following dependencies at the moment:

  - the compiler has a few #ifdefs for Windows.  As long as neither
    the host nor the target in a cross compilation are Windows machines,
    we're ok.

  - the native code generator is platform-dependent.  Doesn't affect
    unregisterised compilation, so we escape again.

Cheers,
	Simon