July 2001 - Glasgow-haskell-users

linking with c++ libraries
by Corneliu Popeea 21 Jul '01

21 Jul '01

I'm trying to use from Haskell a C++ library (Omega Calculator). I'm using the following command: ghc -c -fglasgow-exts -package lang main.hs ghc main.o mylib.o -lomega -lstdc++ -fglasgow-exts -package lang Do I need to add more options? The compilation went fine (after I added -lstdc++ which is invoked by default by "g++", but not by "ghc"), but the executable generates a core. Omega library used from a C++ file, with the same call, and same parameters runs ok. Best regards, Corneliu

2 1

New InstallShield: GHCi 5.01 "Borag Thungg"
by Reuben Thomas 19 Jul '01

19 Jul '01

I've updated the test Windows InstallShield of GHCi 5.01 available from http://www.haskell.org/ghc/dist/5.00.2/ghc-5-01.exe (There's no link to it on the web site) In case you missed the previous announcement, this is a test release, but seems fairly stable (I use it all the time). It has the following features: * GHCi: now you can use GHC interpretively under Windows. You can just run the InstallShield, and double-click on GHCi to get going. * Complete install: everything you need to use GHC is included; Cygwin is no longer required; also, unlike recent 4.08.2 releases, it doesn't interfere with any Cygwin installation you may already have Changes from the previous test release, "Zarjaz": * Now installs in Program Files by default (supports paths containing spaces). * Installs the profiling libraries and imports (the previous test release included them, but for mysterious reasons they weren't actually installed). Also note that as one user found, the supplied gcc doesn't like identifiers containing top-bit-set characters, so if you want to use them you must use the native code generator.

1 0

RE: GHC Alpha port?
by Simon Marlow 19 Jul '01

19 Jul '01

> 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. Yes, I think that's because you were using the i386-linux config to build the first set of .hc files - it should have been possible to use the Alpha config.h at this point. > 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? We're in the process of transitioning from the old suite in ghc/tests to the new on in fptools/testsuite. Use ghc/tests for now, and look for failures that don't also fail on i386-linux. > 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?) It's evil, but I don't think we're going to glorify it (it's not clear that a Haskell version would be any less evil, anyhow). It's more likely that we'll eventually ditch it and do something else, but exactly what we don't know yet. It shouldn't be too hard to get the mangler going on Alpha again, given a working knowledge of Alpha assembly. It basically does the following things: it puts the info table next to the entry code for a closure, puts the fast entry point directly after the slow entry point and eliminates the jump in between, and removes the "prologue" and "epilogue" code from the C functions so that tail-calls work properly. To get a fully registerised compiler working, you also have to check the register assignment in includes/MachRegs.h, the tail call settings in includes/TailCalls.h, and the C<->Haskell glue code in rts/StgCRun.c. Let me know if you need any more help. > 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 > mind? Well, I guess a set of instructions would be fine. I had in mind some build system support for cross-compilation, but that probably has a low payoff to effort ratio. > > - 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 :). Great - if you write down the procedure, I'll mark it up for the build system documentation. > > > 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 > > host. > > 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? I suspect that overwriting is the right way to do it. But again, I'm sure there are one or two wrinkles to work out. > By the way, why does MachDeps.h #define FLOAT_SIZE_IN_BYTES to be > SIZEOF_DOUBLE rather than SIZEOF_FLOAT if SIZEOF_DOUBLE == > SIZEOF_VOID_P? That's a hangover from the way we used to do floats on 64-bit machines: they used to be the same size as a Double, because after all you have a full double word to store them in. We ditched that because you need to have a real float-sized object for communicating with external C functions. > > > 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 == 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? You need to get a memory map of a typical process and find a free spot, preferably at a higher address than the code of the process (shared libraries don't count). eg. on Linux, it's something like 'cat /proc/<n>/maps'. > 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 > it? It checks that the block is properly aligned, which is enough. I suspect that the case where mmap returns a block which is properly aligned but isn't at the address we asked for never happens, though. > An entirely separate question: Why are there both rts/Linker.h and > includes/Linker.h? Good question. I'll investigate. Cheers, Simon

1 0

RE: GHC Alpha port?
by Simon Marlow 18 Jul '01

18 Jul '01

> 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. well tracked down. > "Hello, world!" works now! Yay! :-) great work! > So far, I've discovered 3 reasons why .hc files are not entirely > portable across platforms. There are quite a few bootstrapping and cross-compilation issues to be resolved, and things got harder recently due to the use of hsc2hs to generate some of the Haskell sources, which means the .hs files and therefore the .hc files have platform-dependent content. This is somewhat unfortunate, but using careful cross-compilation techniques (as you suggest) we can work around it. I'm hoping that after this experience(!) we can do two things: - add some support for cross-compilation to the build system. - write down exactly what one needs to do to make this work, and put the instructions in the build system documentation. > 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. 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 host. In general, the sources and build system should make the distinction between the host platform's config and the target platform's config, but it's probably a lot of work to get this right. > 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. Yes. > 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. yes, we should definitely do this. The .hc files are supposed to be independent of word size, so hopefully this is the only wrinkle. > 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. This should be the case, but we need to be careful about which settings from the environment are used when compiling the compiler itself. I can see the following dependencies at the moment: - the compiler has a few #ifdefs for Windows. As long as neither the host nor the target in a cross compilation are Windows machines, we're ok. - the native code generator is platform-dependent. Doesn't affect unregisterised compilation, so we escape again. Cheers, Simon

2 1

RE: GHC 5.01 "Zarjaz": Test release for Windows
by Lescher Christian 18 Jul '01

18 Jul '01

Here's my first feedback concerning GHC 5.01 for Win: There are significant improvements of compilation speed (about 20% faster, sometimes even more) and the generated code's size (about 40% smaller). And the new "--make" option and GHCi are really great features! However, I already discovered some smaller problems, too: - The included version of HaXml (including dtdtohaskell.exe etc.) is not up-to-date. - I had some "Dr. Watson"s when leaving GHCi. I think, it was in a case with a possible heap overflow. I'll try to analyze it further. - When running GHC with the "--make" option, sometimes it stoppes with an error message ("the impossible happened" ...). I will also try to make this situations reproducable. Some smaller problems are: - When leaving out the "-o" option, GHC4.08.2 defaulted to "main.exe", but GHC5 doesn't anymore (produces "a.out"). - I didn't find a way yet to force GHCi to load a module in "interpreted" mode, even if an up-to-date object file is present. Is there a way to do this without deleting .hi/.o first? Christian

2 1

RE: do's and error messages
by Simon Peyton-Jones 16 Jul '01

16 Jul '01

Here's an example: f x = do { "c" ; putStrLn "x"; return () } Test.hs:3: Couldn't match `[]' against `IO' Expected type: [t] Inferred type: IO () In the application `putStrLn "x"' in a `do' expression pattern binding: putStrLn "x" I don't see an easy way to improve this. I suppose we could do some kind of "voting" thing, where we take a majority view about what the result type constructor of the monad is... but that would take a bit of work. Hmm. It's a good point, but I'm inclined to wait until there are more yells before investing effort here. Simon | -----Original Message----- | From: George Russell [mailto:ger@tzi.de] | Sent: 16 July 2001 15:56 | To: glasgow-haskell-users(a)haskell.org | Subject: do's and error messages | | | If you have a type error message at the very start of a "do" | statement, the result can be rather confusing, because the | typechecker doesn't "know" that do's are almost always have | type (IO (something)) and so tries to shoehorn the monad to | fit the type. This has actually happened to me several | times; the worst case is when the result is (for example) a | list, which allows the error to propagate further. Is there | some way of doing something about this? | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

do's and error messages
by George Russell 16 Jul '01

16 Jul '01

If you have a type error message at the very start of a "do" statement, the result can be rather confusing, because the typechecker doesn't "know" that do's are almost always have type (IO (something)) and so tries to shoehorn the monad to fit the type. This has actually happened to me several times; the worst case is when the result is (for example) a list, which allows the error to propagate further. Is there some way of doing something about this?

1 0

GHC 5.01 "Zarjaz": Test release for Windows
by Reuben Thomas 16 Jul '01

16 Jul '01

There's a test InstallShield for Windows of GHC 5.01 now available at http://www.haskell.org/ghc/dist/5.00.2/ghc-5-01.exe There is no link to this from the web pages, as it's not intended for general consumption. This is a thrill-seekers' release (hence the moniker). Please do try it out and report problems; I'm currently using it as my installed compiler, so I'm interested in fixing any. -- http://sc3d.org/rrt/ Reality is what refuses to disappear when you stop believing in it (Dick)

1 0

RE: GHC Alpha port?
by Simon Marlow 16 Jul '01

16 Jul '01

> 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. So it doesn't work without -static? A HEAP_BASE change is not unexpected, it all depends where the system puts its shared libraries. > 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=<the ghc-inplace I just built from the .hc files> \ > HappyCmd=<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_TOOL -DWANT_PRETTY -package lang -package util > -package text Main.hs Package.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? The hc-build script is a little broken. What you actually need to do is: - Take the .hs files generated from the .hsc files from the host to the target (these should be part of the .hc file bundle). - Build in ghc/lib/std and hslibs before ghc/utils, - Then build in ghc/utils using the newly built libraries. Cheers, Simon

1 0

RE: GHC Alpha port?
by Simon Marlow 15 Jul '01

15 Jul '01

> > 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 */

2 2