February 2002 - Glasgow-haskell-users

RE: SGI-Port // Mnagler-Gcc Interface...
by Simon Marlow 27 Feb '02

27 Feb '02

Hi there, > I'm trying to run GHC in a mips-SGI-irix platform, more > accurately Irix > 6. > > The last binary version avalaible > (ftp://ftp.dcs.glasgow.ac.uk/pub/haskell/glasgow/) is for ghc-2.10 > (ghc-2.10-mips-sgi-irix6.tar.gz) . > > > In order to reach the actual ghc-5-XX step by step, I will start by > porting ghc-3.02, ghc-4.08.... This is one way, but as you noticed you need to be careful about gcc versions. There are 4 porting steps involved: 2.10 (should just work given the right gcc version), 3.02, 4.08, and finally 5.02. Each step will require a particular gcc and perhaps changes to the mangler. This is a long and tortuous route to getting GHC working. There is a better way, as suggested by Keith, namely to bootstrap from .hc files. The best version to start from is 4.08(.2) (later versions have problems with .hc bootstrapping). One can bootstrap the compiler using "unregisterised" .hc files, which avoids the mangler. The process has been discussed on one of the lists before, but I just did a search and couldn't find it - maybe you'll have better luck. Anyhow there are three stages: first you generate the unregisterised .hc files using a two-stage bootstrap on a machine with a working 4.08 GHC (eg. a Linux box). Then you compile these on the target machine to generate a working unregisterised compiler. Finally you can use this compiler to experiment with getting registerised builds working - i.e. modifying the mangler. Cheers, Simon

1 0

Re: SGI-Port // Mnagler-Gcc Interface...
by Rafael Martínez Torres 27 Feb '02

27 Feb '02

> > The other way to do the port is to bootstrap from HC files; i.e., > forget that any ghc build exists on your architecture, and start from > scratch. The method is discussed briefly at > > http://www.haskell.org/ghc/docs/latest/building/sec-booting-from-c.html > > but basically involves using pre-built, non-gcc-specific C files that > don't need mangling to build the first stage GHC compiler. Well, I may be wrong, but I think booting .hc files doesn't avoid mangling step ... .hs ->| hsc |-> .hc -> |cc| -> .s -> |mangling| -> .s' -> |assembler| -> .o -> | linker | -> a.out am I right ? I tried booting from .hc files in linux, sun, and now irix... Look at the table: platform sparc-sunos sparc-sunos i386-linux i386-linuxmips-sgi-irix mips-sgi-irix gcc-version 2.7.2.3 2.95.1 2.7.2.3 2.95.1 2.95.1 2.7.2.3 ghc-3.02-booting-hcOK NOK OK NOK OK ¿OK? We should distinguish conceptually the next "model": - compiler properly said (hsc) : .hs -> .hc ( writen in Haskell (.hs) !! , so I need to mangle !) - the run-time suport (-l<something>.a , It's almost written in C, something in Haskell .) - the mangler (ghc-asm.prl) .s -> .s' (mangles prelude functions, destroying C -stack model ) - the linker ( -lruntimea, .o -> a.out) - the driver (ghc.prl) . The master overall guide process... The key point I must concentrate is the gcc-mangler interface...That would explain the previous table. Booting .hc doesn't avoid mangling...as I understand the process.( I may be wrong ) The older mangler (ghc-3.02) seems to be dessigned closely to the gcc 2.7.2.3 output... ( The ghc-4.08 runs on gcc-2.95.1 ) That's why I'm trying to find which one was used to build and run ghc-2.10-mips-sgi-irix6.tar.gz . Any other e-mail or reference to consult MIPS-port would be acknowledged... Sorry if my previous mail was large and a bit dark... > From > there, you have a Haskell compiler that can be used to compile the > real GHC natively, and you can work on the mangler etc as necessary. > No doubt one of the GHC Team will give more details. > > In general, the GHC Team is very happy to help with this kind of > thing, because they want GHC to be available on as many platforms as > possible. >

2 1

RE: Straightforward conversion from Int <-> Word
by Simon Marlow 27 Feb '02

27 Feb '02

> Simon Marlow notes: > > But fromIntegral *does* do the right thing, doesn't it? > > > > > Numeric.showHex (fromIntegral (-1 :: Int32) :: Word32) "" > > "0xffffffff" > > Interesting. The fact that this fooled Julian as well as me suggests > the behavior needs to be better documented. Interestingly, > hugs yields > an error. I'm going to follow up in more detail to haskell, as this > is really about the behavior of "fromInteger", and has nothing to do > with Word32 or Int32 per se at all. There's this paragraph which talks about the behaviour of fromIntegral in GHC: http://www.haskell.org/ghc/docs/latest/set/vs-haskell-defn.html#HASKELL98-U… but it suggests that this only happens for Int. I'll expand it to cover the sized integral types. Cheers, Simon

1 0

RE: problem compiling GUM
by Simon Peyton-Jones 27 Feb '02

27 Feb '02

There is a GPH mailing list in fact. http://www.cee.hw.ac.uk/~dsg/gph/ It's not listed on the "comprehensive" list of mailing lists at haskell.org, which is surely an oversight. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 26 February 2002 19:44 | To: GHC Users Mailing List | Subject: problem compiling GUM | | | Hi all, | | I'm not sure if this is the appropriate place to ask about | this, but there's no GPH mailing list. I recently downloaded | the source for GUM-4.06-291100 and am having difficulty | getting it to compile. The complaint it gives is: | | utils/Argv.lhs: can't locate import `Addr' | <<ghc: 1972928 bytes, 2 GCs, 112168/112168 avg/max bytes | residency (1 samples),\ 5M in use, 0.02 INIT (0.02 elapsed), | 0.04 MUT (0.23 elapsed), 0.07 GC (0.11 el\ | apsed) :ghc>> | gmake[2]: *** [depend] Error 1 | gmake[1]: *** [boot] Error 1 | gmake: *** [boot] Error 1 | | But I don't really know anything about what's going wrong :). | I'm hoping someone can help me out. I've attached full | transcripts of the build process (gzipped so people don't | complain about huge attachments). Please please help me out | here :). I already have ghc5.02.1 installed, so on one of | the builds i specified --with-hc to use this; on the other i | didn't. neither worked. | | Thanks! | | - Hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume |

1 0

SGI-Port // Mnagler-Gcc Interface...
by Rafael Martínez Torres 27 Feb '02

27 Feb '02

Hello: I'm trying to run GHC in a mips-SGI-irix platform, more accurately Irix 6. The last binary version avalaible (ftp://ftp.dcs.glasgow.ac.uk/pub/haskell/glasgow/) is for ghc-2.10 (ghc-2.10-mips-sgi-irix6.tar.gz) . In order to reach the actual ghc-5-XX step by step, I will start by porting ghc-3.02, ghc-4.08.... 1) Is it really ghc-2.10 the last version avalaible ? If any newer, where to get it from (Any other discussing group) ? I tried unsuccesfully to run the ghc-2.10 on a Irix6 . The mangler-phase seems to fail and aborts the process. I had been told that for newer ghc-versions I should rearrange the mangler to make GHC run, but I hoped the 2.10 binary version to run succesfull. >From a Unix-programmer external point of view ,(exclude STG or run-time dessigner scope) my empirical experience by running several versions (ghc-3.02,ghc-4.08 ) among different platforms ( sparc-sunos, i386-linux ) suggest me the next: ( I may be wrong or confused. My STG computation model is not very mature (Four months ) Enlightment would be acknowledged ) - Obtaining a succesfull image doesn't depend so much from the run time system implementation varying from ghc-[2345]-XX as from the gcc-mangler interface.(At least for "Hello world" programs, differ subtility from correctness in larger projects, where the run-time system takes more relevance )( Read next) - The mangler is closely bound to the gcc output. As a matter of versioning problem, when gcc goes upwards the mangler may not to operate correctly. Mangler reduces well for gcc-2.7.2.3 and fails for gcc-2.95.1 ( Test source: ghc-3.02 on both i386-linux and sparc-sun. both linked, but a faulty image was generetaed. The O.S sends the runtime a signal and aborted the program). - As a consequence of the previous point, the original idea for using C as a "transparent macro-assembler" among different platforms is now discussed again. In practical terms, not only the C compiler used (I have tried only GNU CC) but the compiler version may interfere the entire ghc-compiling process. This should be of special interest for making binary distributions (rpm, pkg...) The first time I ran the ghc-3.02 (installed from chack's rpm's ) on a i386-linux it failed. Reason: my Linux distribution installed the ghc-2.95.1. Reinstalling downwards the gcc to 2.7.2.3 solved the problem. Hence, 2) Should the binary versions be distributted with the specific gcc version attached ,like other compiler packets do (i.e Ada ) ? This would help to portability among different platforms, though C-compiler transparency would be compromised. Only Gcc should be used and specific version... Unless you want a normal user to hack the mangler piece... 3) Specific question: As a porter, I have two choices in order to make GHC run in a mips-SGI-irix platform... - To hack the mangler: discarded since I have no deep knowledge about how the mangler operates. :-| - To retrieve (from this mailing list) which a configuration was last used to make ghc-2.10 run on a mips-SGI-irix. Instead of rearrenge the mangler to match the environment, I will rearrange the environment to match the mangler. Which gcc version was the ghc-2.10 mangler designed for ? Or The highest gcc version the binary (ghc-2.10-mips-sgi-irix6.tar.gz) ran sucessfull last time : The gcc-2.95 seems to fail... 4)Once I have got it : should I install the GNU assembler for MIPS or use the propietary one ? This is because I have read the gcc modifies its output according to the asssembler to be used in the next step (--with-gnu-as in the configure ). Was this considered during the mangler dessign ? 5) I think once you have the final .o files, choice between GNU or propietary linker shouldn't matter grosso modo. True ? Cheers.

2 1

problem compiling GUM
by Hal Daume III 26 Feb '02

26 Feb '02

Hi all, I'm not sure if this is the appropriate place to ask about this, but there's no GPH mailing list. I recently downloaded the source for GUM-4.06-291100 and am having difficulty getting it to compile. The complaint it gives is: utils/Argv.lhs: can't locate import `Addr' <<ghc: 1972928 bytes, 2 GCs, 112168/112168 avg/max bytes residency (1 samples),\ 5M in use, 0.02 INIT (0.02 elapsed), 0.04 MUT (0.23 elapsed), 0.07 GC (0.11 el\ apsed) :ghc>> gmake[2]: *** [depend] Error 1 gmake[1]: *** [boot] Error 1 gmake: *** [boot] Error 1 But I don't really know anything about what's going wrong :). I'm hoping someone can help me out. I've attached full transcripts of the build process (gzipped so people don't complain about huge attachments). Please please help me out here :). I already have ghc5.02.1 installed, so on one of the builds i specified --with-hc to use this; on the other i didn't. neither worked. Thanks! - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

Re: Straightforward conversion from Int <-> Word
by Jan-Willem Maessen 26 Feb '02

26 Feb '02

Simon Marlow notes: > But fromIntegral *does* do the right thing, doesn't it? > > > Numeric.showHex (fromIntegral (-1 :: Int32) :: Word32) "" > "0xffffffff" Interesting. The fact that this fooled Julian as well as me suggests the behavior needs to be better documented. Interestingly, hugs yields an error. I'm going to follow up in more detail to haskell, as this is really about the behavior of "fromInteger", and has nothing to do with Word32 or Int32 per se at all. -Jan

1 0

RE: multiple processes and threads
by Simon Marlow 26 Feb '02

26 Feb '02

> I have an application that uses multiple processes and > multiple threads > together. What's the best way to detect child process terminations? > > The initial thread in the inital process serves as driver of the > application. It creates child processes and threads to carry out > portions of the computation. A natural way to have the driver detect > termination of these child processes and threads would be to have the > driver "listen" on a single MVar to which termination notices are > "posted". Child threads would simply post their termination notices > directly. For child processes, I'd like to have a single > thread in the > initial process execute (getAnyProcessStatus True False) repeatedly, > posting a termination notice each time such a call returns. However, > with the current implementation of Concurrent Haskell, when the thread > pends on the getAnyProcessStatus call, the entire initial process > pends. The best solution I've come up with so far, which is > unsatisfying, is to have this thread poll periodically (that is, loop > over (getAnyProcessStatus False False) and (threadDelay)). Is there a > better way? One (possibly better) way is to listen for SIGCLD. This has been discussed a couple of times before, threads here: http://www.haskell.org/pipermail/glasgow-haskell-users/2001-July/002079.html http://www.haskell.org/pipermail/glasgow-haskell-users/2001-September/00227… The upshot is the GHC *should* provide a better mechanism than it does currently, but it doesn't, sorry :-) Cheers, Simon

1 0

RE: Building ghc-5.00.2 from .hc files
by Simon Marlow 26 Feb '02

26 Feb '02

> I have tried do build ghc-5.00.2 from .hc files. I run > ditrib/hc-build, > but it fails: > > -------------------------------------------------------------- > ---------- > ===fptools== Finished making `all' in cbits ... > PWD = /tmp/ghc-5.00.2/hslibs/lang > -------------------------------------------------------------- > ---------- > make[1]: *** No rule to make target `Addr.o', needed by `libHSlang.a'. > Stop. > make: *** [all] Error 1 > make: Leaving directory `/tmp/ghc-5.00.2/hslibs' > > My box is ix86 running Linux (but I could not use binary version of > ghc). > Could you tell me what I should do to compile it from .hc files ? Building from .hc files is not very well supported, and is a highly involved process in 5.xx. If you really can't use any of the binary distributions, I suggest starting from 4.08.2 which should be a lot smoother to bootstrap from .hc files. Cheers, Simon

1 0

RE: Doubts in GHC
by Simon Marlow 26 Feb '02

26 Feb '02

> I´m new in this list and I think that it´s a very good > idea, because we > can show our doubts. > I have a doubt in GHC: How can we include a folder in the compiling > process? Example: If one file called main.hs requires some > others modules > that are in one folder, how can compile it in GHC and include > this folder? ghc --make -i<folder> main.hs Cheers, Simon

1 0