The relevant makefile code is in fptools/mk/bootstrap.mk - I'm sure you'll be able to modify it to do the right thing. When you've got it working we'll think about how to set up the bootstrapping system so mangling is optional.
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.
(By the way, are *_hsc.[hc] files considered part of the ".hc distribution"? I needed them for compiling, say, Directory.hc.)
Anyway, the current hurdle is that ghc/lib/std/PrelInt.hc doesn't compile because int64ToIntegerzh_fast is not declared because ghc/includes/PrimOps.h did not declare it because SUPPORT_LONG_LONGS is not defined in ghc/includes/StgTypes.h because SUPPORT_LONG_LONGS is defined in ghc/includes/StgTypes.h if and only if HAVE_LONG_LONG && SIZEOF_VOID_P < 8, and SIZEOF_VOID_P is 8.
I'm not sure what the right fix is here. Why does StgTypes.h not define SUPPORT_LONG_LONGS if SIZEOF_VOID_P >= 8, anyway?
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... Cheers, Simon *** PrimOps.hc 2001/07/06 14:11:38 1.79 --- PrimOps.hc 2001/07/11 09:24:29 *************** *** 594,601 **** FE_ } ! #endif /* HAVE_LONG_LONG */ /* ToDo: this is shockingly inefficient */ --- 594,616 ---- FE_ } + #elif SIZEOF_VOID_P == 8 ! FN_(word64ToIntegerzh_fast) ! { ! FB_ ! JMP_(wordToIntegerzh_fast); ! FE_ ! } ! ! FN_(int64ToIntegerzh_fast) ! { ! FB_ ! JMP_(intToIntegerzh_fast); ! FE_ ! } ! ! #endif /* SUPPORT_LONG_LONGS || SIZEOF_VOID_P == 8 */ /* ToDo: this is shockingly inefficient */
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=
On 2001-07-13T16:55:57-0400, Ken Shan wrote:
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 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'
This problem was because struct dirent differs between i386-linux and alpha-osf3. I fixed it by running the intermediate C program generated by hsc2hs remotely on our alpha machine instead of locally on our linux machine. "Hello, world!" works now! Yay! So far, I've discovered 3 reasons why .hc files are not entirely portable across platforms. 1. ghc/includes/MachDeps.h, which is #included by some Haskell source files, in turn #includes ghc/includes/config.h, which differs from platform to platform. SOLUTION: Modify MachDeps.h to #include the config.h from alpha-osf3, even when compiling on i386-linux. 2. The .hs file produced by hsc2hs differs from platform to platform, because the intermediate C program it generates necessarily behaves differently on each platform. SOLUTION: Add "--keep-tmp-files" flag to hsc2hs. Run the intermediate C program over on alpha-osf3. 3. Liveness bitmaps are of different width (32 bits vs 64 bits) between platforms, and the compiler generates different HC code based on the width. SOLUTION: Make the compiler generate platform-independent HC code that uses newly defined preprocessor macros to switch between 32-bit and 64-bit liveness bitmaps at C compilation time. These fixes (especially #1) make me uneasy about the bootstrapping process. Here's my current limited understanding of the making of HC files: a. First we use the existing GHC to compile a new compiler (that produces unregisterised code) b. Second we use the new compiler to compile a new library (keeping the unregisterised HC files) -- This new library is compiled for use on alpha-osf3, not i386-linux, in terms of issues (1) and (2) above. c. Third we use the new compiler from (a), in conjuction with the new library from (b), to compile a doubly new compiler (that produces unregisterised code) (keeping the unregisterised HC files) -- This doubly new compiler is compiled for use on alpha-osf3, not i386-linux, in terms of issues (1) and (2) above. d. Finally we ship the HC files kept from steps (b) and (c) for use on the target platform Note that, in step (c), we run the i386-linux compiler from (a) with the alpha-osf3 library from (b). The library produced in (b) is incorrect as i386-linux code, but that's okay because all we want from (b) are the HC files anyway. Consequently, the doubly new compiler produced in (c) is also incorrect as i386-linux code. That's again okay because all we really want from step (c) are the HC files anyway. Just to make sure, though, could you please confirm the following:? In step (c), the once-new compiler uses (b) only as data, not as code. In other words, even though (b) is incorrect as i386-linux code (and so (c) is incorrect as i386-linux code), the HC files produced in (c) are still perfectly correct as alpha-osf3 code. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig See the sun in the midst of the rain. Scoop clear water from the heart of the fire.
participants (2)
-
Ken Shan -
Simon Marlow