- Glasgow-haskell-users

RE: how and where to {-# specialize #-} ?
by Simon Marlow 25 Jun '03

25 Jun '03

Alastair Reid writes: > One way of tackling it would be to change ghc so that > compilation doesn't > produce .o files containing machine code but, rather, files > containing a concise encoding of STG code. Yes, one could indeed do that. We've discussed various schemes like this in the past, and the bottom line is usually that it's a good idea but hasn't so far been compelling enough to warrant the effort it would take to implement. I will comment on one particular thing though: > This case ought to be easier because STG > code has already > had a very powerful optimizer applied to it so all that's > left is doing a good job with register allocation and pipelining. There's a lot more to do to get from STG code to fast machine code than just register allocation and pipelining. Even if we consider generating machine code from the intermediate C to be "just register allocation and pipelining", GHC does an awful lot of work to get from STG to C. The bytecode generator does a much more simplistic transformation from STG to bytecodes, but it loses many opportunities for optimisation in the process. So if one were to do something like this, the crucial decision is at what level to target the intermediate code. Something that can be directly interpreted *and* compiled to fast machine code (JITted?) would seem to be a good idea (Julian Seward was very keen on this). That would be at a level somewhat lower than STG, though. Cheers, Simon

1 0

RE: how and where to {-# specialize #-} ?
by Simon Peyton-Jones 25 Jun '03

25 Jun '03

| I am looking for some advice on | where to place specialize-pragmas for ghc | (to optimize speed - and heap usage) | | Typically I have some module A (containing polymorphic functions A.f, ..) | and a module B uses this. The interesting case is | when I want to specialize A.f (which is NOT exported) | to some types that are only defined in B | (but normally A should not know about B). | | Is there some kind of `deep specialisation' where one would say, | `specialize ALL the functions that are reachable from here'? - | or how can one get a similar effect? There are two questions here a) If module B defines a type B.T, and imports function A.f from module A can we specialise f at type B.T? b) If we specialise f at T, and f calls g, how can we specialise g at T? Unfortunately, GHC has no good way to do (a). It only specialises functions in the module being compiled, so it can't specialise f when compiling A because it can't see B.T it can't specialise f when compiling B because it can't see (all of) f It's not obvious how best to address this. Putting all of A's code in its interface file (not only f, but the things f calls), so that B can specialise it, seems a bit brutal; and f might then be specialised to the same type many times. But we can't specialise it in module A, because A can't see T. Maybe the Right Thing is some kind of whole-program specialisation, but GHC isn't set up to do that. The only workaround is to define T early, import it into A, and specialise A.f there. Relating to (b), GHC automatically does this specialisation propagation within one module, but if A.f calls A2.g (where A imports A2), then A2.g won't get automatically specialised; you'll have to add your own specialisation pragma in A2. Again this is far from ideal. One possible plan (totally unimplemented) is this: when compiling a module, dump specialisation guidance of the form A.f needs A2.g @ T or, more generally something like A.f @ t needs A2.g at [t] Now do a global analysis of all the specialization guidance info to generate SPECIALISE pragamas. Now recompile everything Simon

2 1

RE: @-bindings broken in 6.0?
by Simon Peyton-Jones 25 Jun '03

25 Jun '03

| > -farrows | | Is this switch documented somewhere? I looked through the docs in the | latest CVS version of GHC and couldn't find anything about it ... Not yet: I only put it in this week! And it's not documented yet. There are some examples, though in fptools/testsuite/tests/ghc-regress/arrows And the commit message contains many details (enclosed) Simon ---------------------------------------------- Add support for Ross Paterson's arrow notation ---------------------------------------------- Ross Paterson's ICFP'01 paper described syntax to support John Hughes's "arrows", rather as do-notation supports monads. Except that do-notation is relatively modest -- you can write monads by hand without much trouble -- whereas arrow-notation is more-or-less essential for writing arrow programs. It desugars to a massive pile of tuple construction and selection! For some time, Ross has had a pre-processor for arrow notation, but the resulting type error messages (reported in terms of the desugared code) are impenetrable. This commit integrates the syntax into GHC. The type error messages almost certainly still require tuning, but they should be better than with the pre-processor. Main syntactic changes (enabled with -farrows) exp ::= ... | proc pat -> cmd cmd ::= exp1 -< exp2 | exp1 >- exp2 | exp1 -<< exp2 | exp1 >>- exp2 | \ pat1 .. patn -> cmd | let decls in cmd | if exp then cmd1 else cmd2 | do { cstmt1 .. cstmtn ; cmd } | (| exp |) cmd1 .. cmdn | cmd1 qop cmd2 | case exp of { calts } cstmt :: = let decls | pat <- cmd | rec { cstmt1 .. cstmtn } | cmd New keywords and symbols: proc rec -< >- -<< >>- (| |) The do-notation in cmds was not described in Ross's ICFP'01 paper; instead it's in his chapter in The Fun of Programming (Plagrave 2003). The four arrow-tail forms (-<) etc cover (a) which order the pices come in (-< vs >-), and (b) whether the locally bound variables can be used in the arrow part (-< vs -<<) . In previous presentations, the higher-order-ness (b) was inferred, but it makes a big difference to the typing required so it seems more consistent to be explicit. The 'rec' form is also available in do-notation: * you can use 'rec' in an ordinary do, with the obvious meaning * using 'mdo' just says "infer the minimal recs" Still to do ~~~~~~~~~~~ Top priority is the user manual. The implementation still lacks an implementation of the case form of cmd. Implementation notes ~~~~~~~~~~~~~~~~~~~~ Cmds are parsed, and indeed renamed, as expressions. The type checker distinguishes the two.

1 0

RE: @-bindings broken in 6.0?
by Simon Peyton-Jones 24 Jun '03

24 Jun '03

Yes, I'm afraid so. With -fglasgow-exts Template Haskell captures [t| ... |] and [p| ... |] and similarly [d| and [e| for quotations. I don't think I'd fully realised that this conflicts with list comprehensions [t|t<-ts] (I remember reading a book when I was 10 featuring kids trying to decode a message that was in two parts "mac" .. and "hine". Took me ages to spot "machine".) But maybe this isn't what you found? Better syntax here would be welcome if anyone can think of some. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of John Meacham | Sent: 18 June 2003 03:24 | To: glasgow-haskell-users(a)haskell.org | Subject: @-bindings broken in 6.0? | | change in list comprehension parsing? | after I upgraded to ghc 6.0 there were some odd syntax errors on list | comprehensions which i did not get before, making sure i put spaces | between all symbols seems to fix them.. was something changed about how | they are parsed which breaks code that used to work? just curious. | John | -- | ------------------------------------------------------------------------ --- | John Meacham - California Institute of Technology, Alum. - john(a)foo.net | ------------------------------------------------------------------------ --- | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

7 6

GHC 6.0 Sparc/Solaris dist
by Simon Marlow 24 Jun '03

24 Jun '03

I've updated the Sparc/Solaris binary distribution of 6.0: this version should (hopefully) install without difficulty. Let me know if there are any problems. http://www.haskell.org/ghc/dist/6.0/ghc-6.0-sparc-sun-solaris2.tar.bz2 Cheers, Simon

1 0

RE: ghc-split accepts building 6.0 on Windows
by Simon Peyton-Jones 24 Jun '03

24 Jun '03

Sigbjorn has now fixed this in a better way: GHC now canonicalises the TMPDIR stuff internally. So it should just work in future. Thanks to Sigbjorn; and thaks to Dominic for pointing this one out. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Dominic Cooney | Sent: 30 May 2003 11:46 | To: glasgow-haskell-users(a)haskell.org | Subject: ghc-split accepts building 6.0 on Windows | | My environment's TEMP and TMP are C:\temp, but for some reason, my recent | Cygwin install makes 'TEMP' and 'TMP' /cygdrive/c/temp/4; this duly gets | passed to ghc-inplace as C:\temp\4. | | Then, in libraries\base, ghc-split complains that \4 mentions a non-existent | group in a regexp: | | ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude | -#include HsBase.h -Icbits/regex -funbox-strict-fields -package-name base -O | -Rghc-timing -split-objs -c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi | Reference to nonexistent group in regex; marked by <-- HERE in m/"c:\temp\4 | <--HERE \ghc936.split\.c"/ at | d:\\users\\cooney\\ghc\\ghc-6.0\ghc\driver\split\ghc-split line 51, <TMPI> | line 23. | make[2]: *** [GHC/Base.o] Error 255 | | All I needed to do was editing ghc\driver\split\ghc-split so | | $Tmp_prefix = $ARGV[1] | | was instead | | ($Tmp_prefix = $ARGV[1]) =~ s/\\/\\\\/g; | | I don't know whether this habit of appending \4 is a delightful quirk of my | Cygwin install, but FWIW for other Windows Server 2k3/Cygwin users out | there... | | Dominic Cooney | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: [Gtk2hs-users] ghci-5.04.3 and ghc-6.0
by Simon Marlow 23 Jun '03

23 Jun '03

> Would it be possible to use the full hierarchical module name? > There's a much better chance of them being unique. > ie use > > __stginit_Control_Arrow > > rather than > > __stginit_Arrow > > I *assume* that information is avaliable at compile/build time. Yes, we already do this. However, in your case you had a module called "Arrow" in gtk2hs, and a module called "Arrow" in the lang package, in addition to the module "Control.Arrow" in the base package. Cheers, Simon

1 0

RE: signal handling and optimisation
by Simon Marlow 23 Jun '03

23 Jun '03

> I'm trying to write some code that catches unix signals and turns them > into GHC exceptions, GHC version 6.0, debian linux > > Heres my code: > > ------ > module Main where > > import Control.Concurrent > import Control.Exception > import System.Posix > import IO > > catchCtrlC :: IO Handler > catchCtrlC > = do main_thread <- myThreadId > installHandler sigINT (Catch (handler main_thread)) Nothing > where > handler :: ThreadId -> IO () > handler main_thread = throwTo main_thread > (ErrorCall "Kaboom") > > main :: IO () > main = do catchCtrlC > print (f 1) > > f :: Int -> Int > f x = f (x + 1) > ------ > > The function "f" is intentionally bogus, I want it to loop so > I have enough time to hit cntrl-C. You've hit a known bug with concurrency, described in the Control.Concurrent documentation. The problem is that context switches only happen when some allocation is going on: in your f function above, the optimiser turns it into a loop that does no allocation, so no context switches can happen and the exception is never delivered. You probably won't run into this bug in a real program ;-) Cheers, Simon

1 0

HEADS UP: GCC 3.x and Sparc
by Simon Marlow 23 Jun '03

23 Jun '03

I've been tracking down some issues with GCC 3.2/3.3 on Sparc, and it turns out that there's a known bug in these compilers which affects us. See my bug report here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11252 which is a duplicate of the original bug, here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7871 The upshot appears to be that global register variables are broken on GCC 3.2+. So far this hasn't affected us on x86 (fingers crossed), but it certainly shows up on Sparc. If you're on a Sparc box, stick to GCC 2.95 for now. I'll try to get an idea from the gcc folks of when this might be fixed. Cheers, Simon

1 0

RE: Changes in the Core language file syntax since GHC5.02?
by Simon Peyton-Jones 23 Jun '03

23 Jun '03

Don pointed to the source code, but the human-readable document really should be updated too. Would anyone like to volunteer? Preferably someone who's been using Core a bit. (I think the changes are only minor, though.) I'm always interested to know what you are using it for, too! Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Dimitry Golubovsky | Sent: 22 June 2003 19:15 | To: glasgow-haskell-users(a)haskell.org | Subject: Changes in the Core language file syntax since GHC5.02? | | Hi, | | I asked this in the fa.haskell newsgroup, but since this is more | GHC-specific, maybe this list is a better place to ask. | | I am trying to learn the syntax of Core language files using the paper | by Andrew Tolmach named "An External Representation for the GHC Core | Language". This was a draft for the version 5.02. Have there been any | improvements to the Core language definitions since that version and | during the v6.0 implementation? Are they summarized in a document? Or | maybe a fresher version of the paper is available? | | Thanks, | | -- | Dmitry M. Golubovsky | South Lyon, MI | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0