Hi Joe,
On June 29, 2007 8:40:11 AM EDT Joe Buehler wrote:
The processor is PA-RISC 2.0 running on HPUX 11.0...
If you know of any GHC experts with PA-RISC assembly expertise
it would be a huge help if they could fix the mangler. I can supply
plenty of sample input assembly files....
I'll feed my patches back and make the built GHC available when
I'm done.
Right now it looks as if Ian Lynagh is the maintainer for the Debian
Linux hppa port although the Gentoo Haskell Team may have done some
work for PA-RISC2.0. They might be able to help update the Mangler.
(Other responses follow what you wrote below.)
Cheers,
Pete
...
I looked into this further after asking for help and it became clear
that GHC was passing arrays to gmp ("limbs" I think is what
gmp calls them) that were not 8-byte aligned.
The processor is PA-RISC 2.0 running on HPUX 11.0 in
32-bit mode, but the processor still requires 8-byte alignment
for 8-byte types. It turned out that the gmp I was using (4.1.4)
was in fact using 8-byte types, thus the alignment traps.
I spent some time trying to get GHC to pass aligned data
to gmp, but that's not an easy task for someone who knows zip
about GHC internals, so I didn't spend a whole
lot of time on it. What I eventually did was recompile gmp to
use 4-byte types -- which its configure script supports --
and everything now runs fine. No doubt there is a performance
hit involved...
I can identify with the inscrutability of GHC internals--the compiler
is based on translating a higher level language into several other
languages before outputting C-code or assembler. Were you able to
test 'align 8;' in the Cmm code?
I have GHC bootstrapped for hppa1.1-hp-hpux at the moment
and am working on the registerised build. Thankfully hppa was
ported long ago, the code has been left in GHC, and all I am
having to do is update it. At the moment I am up against the
(aptly-named) evil mangler, which will take me some days to
understand and fix.
...
It would probably take me weeks :) I would find it easier to update
the Native Code Generator (NCG) and compile everything by giving GHC
the -fasm option instead of -fvia-C. Unfortunately ghc-6.2's NCG
does not have many of the changes that are in ghc-6.6. As it is, you
may find it easier to use the unregisterised build of ghc-6.2 and try
to do a full build from the ghc-6.6.1 sources using -fasm (I would
not recommend HEAD; whether it builds cleanly varies by the day).
This would bypass the Mangler entirely.
It has been interesting -- GHC builds seem to be
easily able to absorb vast amounts of CPU -- it takes 5 hours
for the bootstrapped GHC to build just the stage 1 compiler on
the box I have.
Same here. I test my changes to GHC on three machines:
1. PowerBook G4, 1.25GHz, 1GB RAM (OS X 10.4)
2. Sony laptop, Pentium III, 500 MHz, 128MB RAM (Ubuntu Linux)
3. PC, Pentium III, 600 MHz, 384 MB RAM (Windows XP)
4. (only for testing compiled programs): PC, Pentium 4 2GHz 1GB RAM--
not mine.
I tend to go through changes very carefully to avoid having to rebuild.
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
