December 2012 - Glasgow-haskell-users

Does GHC still support x87 floating point math?
by Johan Tibell 06 Dec '12

06 Dec '12

Hi, I'm currently trying to implement word2Double#. Other such primops support both x87 and sse floating point math. Do we still support x87 fp math? Which compiler flag enables it? -- Johan

4 3

Extending GHCi
by Dennis Felsing 06 Dec '12

06 Dec '12

Hi! I'm currently trying to extend ghc-vis[1], a tool to visualize live data structures in GHCi and GHC compiled programs, similar to GHCi's :print and vacuum. I want to show the type of a subexpression visualized in ghc-vis. As types aren't stored in GHC they have to be reconstructed. For this I need read access to internal GHC(i) information, like the type of data constructors. Type reconstruction is already happening inside GHCi's debugger[2]. Another concern is having a feature for binding a subexpression to a GHCi variable, so that it appears in ":show bindings" and can be used within the current GHCi session. To me it seems like neither is currently possible from a program running within GHCi. Therefore I just started an extensible GHCi, called eGHCi[3]. So far it should compile on GHC 7.4.2 and 7.6.1, but does nothing else than the regular GHCi. I took the relevant files to compile my own GHCi binary from the corresponding GHC versions, just as ghci-haskeline[4] did before. In order to get type reconstruction and bindings running I'm planning to provide a function > runInGhci :: GhciMonad a -> IO a which enables programs running in eGHCi to run commands inside the GhciMonad. Another change I'm planning is a function > setupHandler :: Event -> GhciMonad a -> IO () which sets an event handler up to be called whenever the specified event occurs. For now the only event I would need is PostEvaluation, which is evoked after an evaluation occured. I want to use this to update the view of ghc-vis automatically after the user entered a new command on the GHCi command line. My first thought was to define new GHCi commands (like :def) instead of functions, but then only the user could use them, and not the programs running inside of GHCi. Now I'm wondering whether the approaches I have in mind are sensible or if anyone can think of a better way to achieve my goals? Is there a way to extend GHCi without copying some of its source code? Is there a chance of having these features flow back into mainline GHCi once they are properly implemented? Thanks, Dennis Felsing [1] http://felsin9.de/nnis/ghc-vis [2] http://hackage.haskell.org/trac/ghc/wiki/GhciDebugger#TypeReconstruction [3] git clone git://r0q.ath.cx/eghci [4] http://hackage.haskell.org/package/ghci-haskeline

3 2

Generating a C call from a MachOp
by Johan Tibell 06 Dec '12

06 Dec '12

Hi, I'm trying to implement word2Double#, which I represent as a MachOp I call MO_UF_Conv (which is very similar to MO_SF_Conv). On some platform I need to implement this MachOp as a call to a C function. Here's what I did in the PPC backend (PPC/CodeGen.hs) for example: getRegister' dflags (CmmMachOp mop [x]) -- unary MachOps = case mop of MO_UF_Conv from to -> coerceWord2FP from to x coerceWord2FP :: Width -> Width -> CmmExpr -> NatM Register coerceWord2FP fromRep toRep x = do dflags <- getDynFlags (src, src_code) <- getSomeReg x -- This is not the type of register I need! dst <- getNewRegNat (floatSize toRep) targetExpr <- cmmMakeDynamicReference dflags addImportNat CallReference lbl let target = ForeignTarget targetExpr (ForeignConvention CCallConv [NoHint] [NoHint] CmmMayReturn) call_code <- genCCall target [src] [dst] let code' = src_code `appOL` call_code return (Fixed (floatSize toRep) dst code') where lbl = mkCmmCodeLabel primPackageId (fsLit $ word2FloatLabel toRep) This doesn't work. The issue is that to make a C call I need CmmFormals and CmmActuals. I cannot figure out how to get the former, as I need to get hold of a LocalReg, which I don't see any way of creating. I could try to make MO_UF_Conv a CallishMachOp, but then I'll have a more difficult time implementing this MachOp in e.g. the LLVM backend, where I don't want to generate a C call but instead output some instructions. I could use some pointers. Cheers, Johan

1 0

Re: Patch to enable GHC runtime system with thr_debug_p options...
by Joachim Breitner 06 Dec '12

06 Dec '12

Dear Michał, Am Sonntag, den 02.12.2012, 22:44 +0100 schrieb "Michał J. Gajda": > On 12/02/2012 09:20 PM, Joachim Breitner wrote: > >> I noticed that Ubuntu, as well as Debian and original packages come > >> without some variants of threaded debugging binaries. > >> A recent change added of printing a stack trace with -xc option requires > >> using both -ticky and profiling compile options, > >> which in turn forces program to be compiled in a -debug RTS way. > >> Since stack trace looks like indispensable debugging tool, and > >> convenient parallelization is strength of Haskell, > >> I wonder is there any remaining reason to leave beginners with a cryptic > >> error message > >> when they try to debug a parallel or threaded application, and want to > >> take advantage of stack trace? > >> > >> The resulting ghc-prof package would be increased by less than 1%. > >> > >> Here is a patch for Ubuntu/Debian GHC 7.4.2 package, as well as upstream --- ghc-7.4.2-orig/mk/config.mk.in 2012-06-06 19:10:25.000000000 +0200 +++ ghc-7.4.2/mk/config.mk.in 2012-12-01 00:22:29.055003842 +0100 @@ -256,7 +256,7 @@ # l : event logging # thr_l : threaded and event logging # -GhcRTSWays=l +GhcRTSWays=l thr_debug_p thr_debug # Usually want the debug version ifeq "$(BootingFromHc)" "NO" I notice that your patch modifies the defaults of GHC as shipped by upstream, and I wonder if there is a reason why these ways are not enabled by default. Dear GHC HQ: Would you advice against or for providing a RTS in the thr_debug_p and thr_debug ways in the Debian package? Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

3 2

GHC Performance Tsar
by Simon Peyton-Jones 06 Dec '12

06 Dec '12

| > While writing a new nofib benchmark today I found myself wondering | > whether all the nofib benchmarks are run just before each release, I think we could do with a GHC Performance Tsar. Especially now that Simon has changed jobs, we need to try even harder to broaden the base of people who help with GHC. It would be amazing to have someone who was willing to: * Run nofib benchmarks regularly, and publish the results * Keep baseline figures for GHC 7.6, 7.4, etc so we can keep track of regressions * Investigate regressions to see where they come from; ideally propose fixes. * Extend nofib to contain more representative programs (as Johan is currently doing). That would help keep us on the straight and narrow. Any offers? It could be more than one person. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of Simon Marlow | Sent: 30 November 2012 12:11 | To: Johan Tibell | Cc: glasgow-haskell-users | Subject: Re: Is the GHC release process documented? | | On 30/11/12 03:54, Johan Tibell wrote: | > While writing a new nofib benchmark today I found myself wondering | > whether all the nofib benchmarks are run just before each release, | > which the drove me to go look for a document describing the release | > process. A quick search didn't turn up anything, so I thought I'd ask | > instead. Is there a documented GHC release process? Does it include | > running nofib? If not, may I propose that we do so before each release | > and compare the result to the previous release*. | > | > * This likely means that nofib has to be run for the upcoming release | > and the prior release each time a release is made, as numbers don't | > translate well between machines so storing the results somewhere is | > likely not that useful. | | I used to do this on an ad-hoc basis: the nightly builds at MSR spit out | nofib results that I compared against previous releases. | | In practice you want to do this much earlier than just before a release, | because it can take time to investigate and squash any discrepancies. | | On the subject of the release process, I believe Ian has a checklist | that he keeps promising to put on the wiki (nudge :)). | | Cheers, | Simon | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

11 14

Re: lambda case
by Herbert Valerio Riedel 03 Dec '12

03 Dec '12

Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> writes: [...] > “\case” complicates lambda, using “of” simply breaks “case … of …” > into two easily understood parts. Just some observation (I'm rather late to the lambda-case discussion, so this might have been already pointed out previously): if the reserved keyword 'of' was to take the place of '\case', shouldn't then 'case' exp w/o the "'of' { alts }"-part become a separately valid expression (with 'case' essentially meaning 'flip ($)') to really break it up into two independent parts? Then 'case exp of { alts }' wouldn't be a special form anymore, but would just result from combining 'case' and 'of'; 'case' wouldn't even need to be a reserved keyword (and thus the grammar could be simplified), if it wasn't for the current grammar which requires to isolate a \case-expression by using () or $, consider e.g.: {-# LANGUAGE LambdaCase #-} import System.Environment case' :: b -> (b -> c) -> c case' = flip ($) main = do s <- getArgs case' s $ \case -- image '\case' was actually '\of' or 'of' [x] -> putStrLn ("Hello " ++ x) _ -> putStrLn "wrong number of arguments given" just my 2¢ cheers, hvr

5 5