GHC Alpha port?
Wed, 18 Jul 2001 22:08:16 -0400
Content-Type: text/plain; charset=us-ascii
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
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
> > 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
An entirely separate question: Why are there both rts/Linker.h and
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Little can be said for Luxembourg.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----