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