GHC Alpha port?

[Ken Shan]

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

For better or for worse, this message will be one full of questions...

It took a couple (one? two? I can't remember) iterations of ghc
building itself purely on the Alpha before the .hc files reached
fixpoint...  I suspect it's because the compiler on i386-linux didn't
realise that it could fit an entire double in one word.

I've been looking for test suites to run, to make myself more
confident of the port.  I found two likely suspects in the CVS
repository, namely fptools/testsuite and fptools/ghc/tests.  Neither
of them pass without unexpected failures on a clean i386-linux build,
though.  Any suggestions?

At what seems now to be a long time ago you said:

> Once you have an unregisterised build working (& bootstrapped), you can
> start trying to get the mangler going for full registerised support.
> The mangler has Alpha support, but it is old and bound to be rotten to
> some extent.

Any suggestions for how I should start on this, and what to watch out
for?  The mangler looks, well, evil.  (Time to glorify it, as was done
to the driver?)

Regarding our wanting to

>   - add some support for cross-compilation to the build system.

The only cross-compilation support I can see that isn't too hard to
add would be documented procedures for shipping the "three wrinkles"
between the build and target systems: ghc/includes/config.h, .hs
output from hsc2hs, and ghc/compiler/main/Config.hs.  Is this kind of
support basically what you meant, or did you have something else in
mind?

>   - write down exactly what one needs to do to make this work, and
>     put the instructions in the build system documentation.

I'd be happy to write down what I did in the near future.  It's
basically the standard steps for creating .hc files, with the
abovementioned "three wrinkles".  (Provided that the patches I just
sent are applied -- prod prod :).

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

I didn't overwrite the i386 config.h with the Alpha one -- I only
changed MachDeps.h and ArrayBase.hs.  Should I have taken the more
drastic route of overwriting?

By the way, why does MachDeps.h #define FLOAT_SIZE_IN_BYTES to be
SIZEOF_DOUBLE rather than SIZEOF_FLOAT if SIZEOF_DOUBLE =3D=3D
SIZEOF_VOID_P?

> > The assertion in question is:
> >       /* make sure the info pointer is into text space */
> >       ASSERT(q && (LOOKS_LIKE_GHC_INFO(GET_INFO(q))
> >                    || IS_HUGS_CONSTR_INFO(GET_INFO(q))));
> >
> > It seems that the GC code is sensitive to the layout of the virtual
> > memory address space.  In particular, I had to change HEAP_BASE from
> > 0x50000000 to 0x200000000L in MBlock.h to get GC to work even with
> > -static.
>
> So it doesn't work without -static?  A HEAP_BASE change is not
> unexpected, it all depends where the system puts its shared libraries.

Okay, so with -static, I easily found the seemingly working setting of
HEAP_BASE =3D=3D 0x180000000L (with the help of some Alpha assembly
programming documentation).  Without -static, is there some way to
(reliably?) know what HEAP_BASE should be set to?

I'm not even sure if the HEAP_BASE setting is the problem, but it
seems likely.  (Specifically: When I looked at the assert failure core
dump inside gdb, GET_INFO(q) did in fact look like ghc info to my
human eyes; the reason LOOKS_LIKE_GHC_INFO(GET_INFO(q)) was false was
that HEAP_ALLOCED(GET_INFO(q)) was true.)

The getMBlocks function in MBlock.c does not check to make sure that
the pointer returned by mmap() is the address it asked for.  Should
it?

An entirely separate question: Why are there both rts/Linker.h and
includes/Linker.h?

--=20
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Little can be said for Luxembourg.

--IrhDeMKUP4DT/M7F
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

iD8DBQE7VkEPzjAc4f+uuBURArj+AKD5ondg2TTzvHY2O/+xFLJItGL2twCgwxIw
2AhpfdR7G+jEsXfFAq6x8bQ=
=Irx/
-----END PGP SIGNATURE-----

--IrhDeMKUP4DT/M7F--