GHC Alpha port?

Ken Shan
Wed, 18 Jul 2001 22:08:16 -0400

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

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

> > The assertion in question is:
> >       /* make sure the info pointer is into text space */
> >                    || 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

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

Edit this signature at
Little can be said for Luxembourg.

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

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see