- ghc-devs - Haskell.org

RE: Fwd: GHC internals
by Simon Peyton-Jones 30 Apr '13

30 Apr '13

Fantastic. As Simon says, what would be most helpful is better documentation on the wki, in the Commentary. The root is here http://hackage.haskell.org/trac/ghc/wiki/Commentary and the rudimentary GHCi docs are here http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/GHCi If that's too awkward, a link to a PDF would be good, but it's clearly not editable by others. Simon From: William Kenyon [mailto:wk249@cam.ac.uk] Sent: 30 April 2013 10:28 To: Simon Marlow; Simon Peyton-Jones Cc: Norman Ramsey; ghc-devs(a)haskell.org Subject: Re: Fwd: GHC internals > If you mean the details of bytecode compilation and the bytecode interpreter, I'm really not sure that there is. That's bad; there > should be. I'm ccing Simon M in case he knows of something. I'm just starting to write detailed documentation for the bytecode generator and interpreter as part of my Masters project, What format would be most useful for you guys? I could do it in haddock and then include it into my project? Or just do it in plain latex and make my report publicly available? Will On 30 April 2013 10:02, Simon Marlow <marlowsd(a)gmail.com<mailto:marlowsd@gmail.com>> wrote: From: *Simon Peyton-Jones* <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com> <mailto:simonpj@microsoft.com<mailto:simonpj@microsoft.com>>> Norman | - Is there anything published about the implementation of GHCi? | Or perhaps something on the Developers' Wiki that explains how it works? If you mean the details of bytecode compilation and the bytecode interpreter, I'm really not sure that there is. That's bad; there should be. I'm ccing Simon M in case he knows of something. Julian Seward wrote some notes on the way GHCi works, which are in the commentary: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/GHCi It's not much, but there are some technical details about stacks and suchlike there. The bytecode itself is a pretty simple stack machine, I can probably answer questions if there's anything you need some help with. Cheers, Simon _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

Re: Fwd: GHC internals
by Simon Marlow 30 Apr '13

30 Apr '13

On 30/04/13 10:27, William Kenyon wrote: >> If you mean the details of bytecode compilation and the bytecode interpreter, I'm really not sure that there is. That's bad; there >> should be. I'm ccing Simon M in case he knows of something. > > I'm just starting to write detailed documentation for the bytecode > generator and interpreter as part of my Masters project, > > What format would be most useful for you guys? I could do it in haddock > and then include it into my project? > Or just do it in plain latex and make my report publicly available? Wiki documentation in the commentary would be the best for us. That doesn't have to be the format you write in, as long as you can translate it into Trac markup and put it in the commentary somehow. Cheers, Simon > > Will > > > On 30 April 2013 10:02, Simon Marlow <marlowsd(a)gmail.com > <mailto:marlowsd@gmail.com>> wrote: > > From: *Simon Peyton-Jones* <simonpj(a)microsoft.com > <mailto:simonpj@microsoft.com> > <mailto:simonpj@microsoft.com <mailto:simonpj@microsoft.com>>__> > > > Norman > > | - Is there anything published about the implementation of GHCi? > | Or perhaps something on the Developers' Wiki that > explains how it > works? > > If you mean the details of bytecode compilation and the bytecode > interpreter, I'm really not sure that there is. That's bad; there > should be. I'm ccing Simon M in case he knows of something. > > > Julian Seward wrote some notes on the way GHCi works, which are in > the commentary: > > http://hackage.haskell.org/__trac/ghc/wiki/Commentary/__Compiler/Backends/G… > <http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/GHCi> > > It's not much, but there are some technical details about stacks and > suchlike there. The bytecode itself is a pretty simple stack > machine, I can probably answer questions if there's anything you > need some help with. > > Cheers, > Simon > > > > _________________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org <mailto:ghc-devs@haskell.org> > http://www.haskell.org/__mailman/listinfo/ghc-devs > <http://www.haskell.org/mailman/listinfo/ghc-devs> > >

1 0

Re: Fwd: GHC internals
by Simon Marlow 30 Apr '13

30 Apr '13

> From: *Simon Peyton-Jones* <simonpj(a)microsoft.com > <mailto:simonpj@microsoft.com>> > > Norman > > | - Is there anything published about the implementation of GHCi? > | Or perhaps something on the Developers' Wiki that explains how it > works? > > If you mean the details of bytecode compilation and the bytecode > interpreter, I'm really not sure that there is. That's bad; there > should be. I'm ccing Simon M in case he knows of something. Julian Seward wrote some notes on the way GHCi works, which are in the commentary: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/GHCi It's not much, but there are some technical details about stacks and suchlike there. The bytecode itself is a pretty simple stack machine, I can probably answer questions if there's anything you need some help with. Cheers, Simon

1 0

HEAD not building on OS X
by Nicolas Frisby 30 Apr '13

30 Apr '13

It seems this patch 50e78dafd0cac5ca3b28ef71559899f179343ddf changed some sed expressions in rts/ghc.mk that seem to be no longer firing on my Mac now. Mac has a different flavor of BSD sed and such. The resulting contents of rts/libs.depend on my build attempt is $ cat rts/libs.depend m dl /Users/nfrisby/Source/ghc-build-trees/vanilla/rts/dist/build It's missing the -l and -L prefices that the sed commands are supposed to add. I can hack around this on my Mac, but I'll leave the fix to someone with some portable sed fu. Thanks.

3 4

Cannot pull HEAD, error pulling Cabal
by Johan Tibell 30 Apr '13

30 Apr '13

Hi, I get this on OS X: == running git submodule update fatal: https://github.com/ghc/libraries/Cabal/info/refs not found: did you run git update-server-info on the server? Unable to fetch in submodule path 'libraries/Cabal' git failed: 256 at ./sync-all line 116. This happens even if I use darcs.haskell.org i.e. through ./sync-all --testsuite -r http://darcs.haskell.org/ --no-dph get If it helps, I do have this patch from earlier today: commit 8a1b7eb6add9d873a93f8e12ccf507bfe0d1df7e Author: Ian Lynagh <ian(a)well-typed.com> Date: Tue Apr 30 00:42:31 2013 +0100 Fix build on OS X sed on OS X doesn't handle \+ which doesn't seem to fix the problem.

1 0

GHC internals
by Simon Peyton-Jones 29 Apr '13

29 Apr '13

Norman | - Is there anything published about the implementation of GHCi? | Or perhaps something on the Developers' Wiki that explains how it works? If you mean the details of bytecode compilation and the bytecode interpreter, I'm really not sure that there is. That's bad; there should be. I'm ccing Simon M in case he knows of something. | - What is the best paper (or papers) to consult on the semantics | of GHC core? Many of these papers http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ give syntax, static semantics, and operational semantics of Core. Moreover, Richard Eisenberg has developed a specification of the Real Core in GHC, kept in the source tree in docs/core-spec I enclose a typeset version. Sadly it doesn't include operational semantics, but I don't think that'd be hard to add, would it Richard? The papers on the above link give several versions of the operational semantics, which is largely straightforward. Simon

2 3

libgmp-related build error
by Andreas Voellmy 28 Apr '13

28 Apr '13

I just tried to grab the latest GHC code so that I can test a bug fix for IO manager on OS X, but I ran into build errors. The failing command was: gcc -E -m32 -m32 -fno-stack-protector -Ilibraries/integer-gmp/gmp -Ilibraries/integer-gmp/mkGmpDerivedConstants/dist -MM libraries/integer-gmp/mkGmpDerivedConstants/mkGmpDerivedConstants.c -MF libraries/integer-gmp/mkGmpDerivedConstants/dist/build/.depend.c_asm.bit libraries/integer-gmp/mkGmpDerivedConstants/mkGmpDerivedConstants.c:15:17: error: gmp.h: No such file or directory It looks like it couldn't find gmp.h Looking over the build reports, I see a recent build on FreeBSD failed for exactly the same reason: http://darcs.haskell.org/ghcBuilder/builders/pgj/1016.html I checked some older (with commits up to March 29, 2013) build trees and I see that in libraries/integer-gmp/gmp there are files like gmp.h and libgmp.a that are not present in my latest build tree. Anyone know what's up here and how to fix this? -Andi

5 8

browsing on github
by Richard Eisenberg 27 Apr '13

27 Apr '13

Hi fellow devs, Do any of you use github for browsing the GHC code? I find it useful sometimes, especially when I'm collaborating with someone remotely and wish to send a link to some code, or when I don't have a particular branch to hand. As of October, github now renders all .lhs files as Markdown. It seems other Haskellers have requested this, but it wreaks havoc on GHC's code, which does not use Markdown. In particular, Markdown uses ~~~~ to delineate code segments, and GHC uses that to underline Notes. This has bothered me for months, but I finally rooted down the cause and opened a ticket. The ticket is here: https://github.com/github/markup/issues/196 If you have run into this problem and have an opinion about it, please share it there! Thanks, Richard

4 5

Re: Per-generation lists of weak pointers
by Akio Takano 25 Apr '13

25 Apr '13

Thank you for your comments! On Wed, Apr 24, 2013 at 8:23 PM, Edward Z. Yang <ezyang(a)cs.stanford.edu>wrote: > Great, good to see. > > Some questions: > > - You seem to be stubbing out cfinalizers with stg_WEAK_IS_DEAD_closure > when a weak pointer gets finalized; your locking is predicated on > operations on this field being cas'es. Another design is to lock > the closure itself, via the info table header (using lockClosure). > I think both strategies should be sound, but I suspect lockClosure > is bound to be safer, in case you end up mutating other fields. > You are right, I updated the patches to use lockClosure. I was not aware of the existence of lockClosure when I wrote the previous patches, which is why I used cas(). > - Typo "Kill a weak poitner" > Now the comment is gone. > - There was a comment about LDV which was removed. Why is that comment > irrelevant in the new world order? > In that version of the patches finalizeWeak# didn't modify the infoptr, so the comment didn't apply. It is back in the latest version of the patches, though. > > Edward > > Excerpts from Akio Takano's message of Wed Apr 24 02:12:42 -0700 2013: > > Thank you very much for your help, I just updated the patches on the > ticket. > > > > On Sun, Apr 21, 2013 at 10:50 AM, Edward Z. Yang <ezyang(a)cs.stanford.edu > >wrote: > > > > > In your ticket, you mention this patch introduces a race condition. > One > > > possible fix is to have addCFinalizerToWeak# check if the pointer is > > > already > > > dead, and just run the finalizer immediately if it is. I think this > > > preserves the semantics, but this needs to be checked closely. > > > > > > Edward > > > > > > Excerpts from Akio Takano's message of Fri Apr 19 02:58:50 -0700 2013: > > > > I removed the invariant by adding a new primop, > addCFinalizerToWeak#. I > > > > opened a ticket for the issue. > > > > > > > > http://hackage.haskell.org/trac/ghc/ticket/7847 > > > > > > > > - Akio > > > > > > > > On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow <marlowsd(a)gmail.com> > > > wrote: > > > > > > > > > On 11/03/13 03:17, Akio Takano wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I'm working on implementing per-generation lists of weak pointers > to > > > > >> speed up garbage collection in programs that allocate a lot of > weak > > > > >> pointers. I have a patch [1] that validates and gives a 3x speed > up on > > > > >> a benchmark. However I'd like to ask for some advise before > finishing > > > > >> and submitting the patch. > > > > >> > > > > >> [1] https://github.com/takano-**akio/ghc/commit/** > > > > >> c7345c68eaa1e7f9572e693b5e352e**386df7d680< > > > > https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386… > > > > > > > > >> > > > > >> The problem is that since my patch splits the weak pointer list > > > > >> between generations, it no longer maintains the right order of > weak > > > > >> pointers. This could cause finalizers added with > > > > >> addForeignPtrFinalizer to run in the wrong order. > > > > >> > > > > >> I can think of one way to fix it; to make sure that when a WEAK > object > > > > >> gets promoted, it is always added to the front of the new list. > So my > > > > >> questions are: > > > > >> > > > > >> - Would it be a correct fix? > > > > >> - If so, is it an acceptable fix? For example, is it too fragile a > > > > >> reasoning to rely on? > > > > >> > > > > > > > > > > I don't like the way that we rely on the ordering of the weak > pointer > > > list > > > > > right now. I think this invariant arose accidentally when the > support > > > for > > > > > C finalizers was added. It was wrong for some time, see: > > > > > > > > > > http://hackage.haskell.org/**trac/ghc/ticket/7160< > > > http://hackage.haskell.org/trac/ghc/ticket/7160> > > > > > > > > > > and as per my comments in that commit log, I think we should do it > > > > > differently. I don't know how hard that would be though. > > > > > > > > > > Incidentally, I implemented per-generation weak pointers in the > > > local-gc > > > > > branch, but didn't get around to porting it back over into the > > > mainline (I > > > > > still have a ToDo for that). My version probably has the ordering > > > bug, but > > > > > you could always look at the branch to see how my approach > compares to > > > > > yours. > > > > > > > > > > Cheers, > > > > > Simon > > > > > > > > > > > > > >

1 0

Enabling debugging output
by Jan Stolarek 25 Apr '13

25 Apr '13

I have some problems with enabling debugging output. I have broken the compiler in such a way that for some programs I'm getting compiler panic when using some of the flags (-ddump-simpl, -fhpc): Main.h :: GHC.Types.Float -> GHC.Base.String [GblId, Arity=1, Str=DmdType] Main.h =ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130422 for x86_64-unknown-linux): Impossible case alternative I would like to get output from the assertions and warnings placed in the code, for example in this function in simplCore/Simplify.lhs (this is the source of my error message): missingAlt :: SimplEnv -> Id -> [InAlt] -> SimplCont -> SimplM (SimplEnv, OutExpr) missingAlt env case_bndr _ cont = WARN( True, ptext (sLit "missingAlt") <+> ppr case_bndr ) return (env, mkImpossibleExpr (contResultType cont)) I recompiled GHC with the -DDEBUG option, but when I add -debug flag during program compilation I see no output from WARN directive. Are there any additional options I need to enable? Janek P.S. My build.mk has these lines: BuildFlavour = quick ifeq "$(BuildFlavour)" "quick" SRC_HC_OPTS = -H64m -O0 -fasm GhcStage1HcOpts = -O -fasm -Werror -Rghc-timing -DDEBUG GhcStage2HcOpts = -O0 -fasm -Werror -Rghc-timing -DDEBUG GhcLibHcOpts = -O -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif

1 0