GHC Alpha port?
Ken Shan
ken@digitas.harvard.edu
Fri, 13 Jul 2001 16:55:57 -0400
--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Good news first -- the .hc files now compile, link and run.
puffin:~$ ls -l u/ghc-port/alpha/ghc/compiler/ghc-5.00.2
-rwx------ 1 ccshan shieber 51665680 Jul 13 16:07 u/ghc-port/alpha=
/ghc/compiler/ghc-5.00.2*
puffin:~$ u/ghc-port/alpha/ghc/compiler/ghc-inplace --version
Alloc Collect Live GC GC TOT TOT Page Flts
bytes bytes bytes user elap user elap
The Glorious Glasgow Haskell Compilation System, version 5.00.2
147784 0.00 0.00
2,016,408 bytes allocated in the heap
403,024 bytes copied during GC
29,584 bytes maximum residency (1 sample(s))
7 collections in generation 0 ( 0.02s)
1 collections in generation 1 ( 0.03s)
1 Mb total memory in use
INIT time 0.00s ( 0.00s elapsed)
MUT time 0.00s ( 0.00s elapsed)
GC time 0.05s ( 0.07s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 0.05s ( 0.07s elapsed)
%GC time 1.7% (1.7% elapsed)
Alloc rate 0 bytes per MUT second
Productivity 0.0% of total user, 0.0% of total elapsed
'twas fun! Fixing-up of the GC code, some ghc/lib/std wrapper code,
one line in a Happy template, etc. were involved. In particular--
On 2001-07-11T10:28:33+0100, Simon Marlow wrote:
> I think it's right not to define SUPPORT_LONG_LONGS - as far as I can
> tell, that symbol means "we need the long long type for
> StgWord64/StgInt64 on this architecture", which isn't true on Alpha.
>=20
> On a 64-bit machine, int64ToIntegerzh_fast and word64ToIntegerzh_fast
> are identical to intToIntegerzh_fast and wordToIntegerzh_fast
> respectively (as long as GMP is using a 64-bit limb type, which
> fortunately it does). The folllowing (untested) patch should be along
> the right lines...
I realised that the Haskell side (PrelPrimopWrappers.hs, PrelInt.hs,
etc.) correctly makes no use of int64ToInteger# and friends if
WORD_SIZE_IN_BYTES is defined to be 8 rather than 4. The problem was
that the .hc files were generated on an i386 machine, so they thought
they would have access to int64ToInteger# and friends when they are
moved over to the Alpha and compiled.
Accordingly, I changed MachDeps.h to #include not the i386 ("host")
config.h but the Alpha ("target") config, then regenerated all the .hc
files. This seems to have solved the problem.
On 2001-07-11T10:28:33+0100, Simon Marlow wrote:
> > I wonder if it matters whether PLATFORM_CC_OPTS is set to -static in
> > mk/bootstrap.mk? The comments there say that the flags "should match
> > the list in machdepCCOpts in ghc/compiler/DriverFlags.hs", and
> > DriverFlags.hs does set -static for alpha.
>
> I'm not sure whether -static is needed; try it without and see what
> happens.
I have no idea why, but...
puffin:~/u/ghc-port/alpha/ghc/compiler$ ./ghc-inplace
Alloc Collect Live GC GC TOT TOT Page Flts
bytes bytes bytes user elap user elap
ASSERTION FAILED: file GC.c, line 1347
IOT/Abort trap (core dumped)
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.
=3D=3D=3D
Current hurdle: ghc-inplace doesn't seem to be finding its .hi files
for basic stuff.
puffin:~$ cat Main.hs
module Main where
import IO
main =3D putStrLn "Hello, world!"
puffin:~$ u/ghc-port/alpha/ghc/compiler/ghc-inplace Main.hs
Alloc Collect Live GC GC TOT TOT Page Flts
bytes bytes bytes user elap user elap
Main.hs:1:
failed to load interface for `Prelude':
Could not find interface file for `Prelude'
Main.hs:2:
failed to load interface for `IO':
Could not find interface file for `IO'
115240 0.00 0.00
6,000,344 bytes allocated in the heap
1,272,096 bytes copied during GC
29,992 bytes maximum residency (1 sample(s))
22 collections in generation 0 ( 0.02s)
1 collections in generation 1 ( 0.03s)
2 Mb total memory in use
INIT time 0.00s ( 0.02s elapsed)
MUT time 0.12s ( 0.12s elapsed)
GC time 0.05s ( 0.07s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 0.17s ( 0.20s elapsed)
%GC time 0.5% (0.6% elapsed)
Alloc rate 51,431,520 bytes per MUT second
Productivity 70.0% of total user, 58.3% of total elapsed
I assume it is supposed to be able to find these .hi files? The
hc-build script calls for
./configure
$MAKE -C ghc/utils clean boot
# ...
(the "./configure" in which I interpret as um, shorthand for
GHC=3D<the ghc-inplace I just built from the .hc files> \
HappyCmd=3D<a fake happy that simulates happy -v output> \
./configure
), but making boot in ghc/utils involves "ghc-inplace -M", which
fails:
$ .../ghc-inplace -M -optdep-f -optdep.depend -osuf o -cpp -DPKG_TO=
OL -DWANT_PRETTY -package lang -package util -package text Main.hs Packa=
ge.hs
Main.hs: can't find one of the following: `IO.hi' `IO.hs' `IO.lhs'
So... perhaps it would be obvious to you what I am missing?
--=20
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
See the sun in the midst of the rain.=20
Scoop clear water from the heart of the fire.
--wac7ysb48OaltWcw
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
iD8DBQE7T2BczjAc4f+uuBURAndHAKD4pVNBKktQzbx7BVAqdUL2wxT4hACeOIKB
TwosSnp8MVDyWBuqC24WEG0=
=DjsS
-----END PGP SIGNATURE-----
--wac7ysb48OaltWcw--