- Glasgow-haskell-users

-odir behaviour change in 6.4.1?
by Andres Loeh 09 Aug '05

09 Aug '05

Is this change in behaviour between ghc-6.4 and ghc-6.4.1 desired: ~/trans $ ls foo foo.c ~/trans $ ghc-6.4 -odir foo -c foo/foo.c ~/trans $ ls foo foo.c foo.o ~/trans $ rm foo/foo.o ~/trans $ ls foo foo.c ~/trans $ ghc-6.4.1.20050804 -odir foo -c foo/foo.c ~/trans $ ls foo foo foo.c ~/trans $ ls foo/foo foo.o It seems to break cabal-1.1.1, in the case that I have something like c-sources: foo/foo.c in my .cabal file ... Cheers, Andres

1 0

RE: Re[4]: C--
by Simon Peyton-Jones 09 Aug '05

09 Aug '05

| so, C-- will never be compiled faster than asm, and, at this moment, | cannot give a better optimization than C? as a result, it's use will have no | meaning until qc-- compiler will advance in it's optimization? For those people interested only in getting their Haskell programs compiled, that's pretty much it. Of course, other people might be interested in C-- itself, but that's a different matter. Simon

1 0

RE: Re[2]: C--
by Simon Peyton-Jones 09 Aug '05

09 Aug '05

| SPJ> Actually using C-- itself as an output medium keeps slipping down the | SPJ> agenda, mainly because no one asks for it! | | because you don't advertise it! :) if you will advertise the | following, preferably with less or more concrete numbers, then we will | know whether we want it or not. just asking "whether you want to have C | or C-- compilation path?" is not enough Fair point. I have not advertised it because it doesn't currently work. I'm not sure what priority to give it. We will use qc--, certainly. It isn't optimised for good code, so we will certainly keep the C and asm routes for the foreseeable future. Simon

2 1

RE: 6.4.1 release candidate testing on OS X
by Simon Marlow 09 Aug '05

09 Aug '05

On 09 August 2005 14:15, Gregory Wright wrote: > ghc-6.4.1.20050806 builds successfully on OS X 10.4.2 using Apple's > gcc-4.0. > > > Bug 1249527 is still fixed, and I was able to build darcs with the > compiler. Nice to hear, thanks Greg! Cheers, Simon

1 0

RE: 6.4.1 release candidate testing on OS X
by Simon Marlow 09 Aug '05

09 Aug '05

On 05 August 2005 23:05, Gregory Wright wrote: > ghc-6.4.1.20050804 builds successfully on Mac OS X 10.4.2 using gcc > 3.3. > > This snapshot also appears to fix bug 1249527, "runhaskell causes GHC > to segfault on OS X". > > The new compiler was also tested by building darcs-1.0.3. > > The build was done under the darwinports infrastructure using ghc-6.4 > as the bootstrap > compiler. > > I haven't yet tried to build using gcc 4.0; should I expect that to > work yet? It might - we've been testing with gcc 4.0, but I believe the MacOS X version has some differences. Cheers, Simon

2 1

RE: Question about ghc case analysis
by Simon Marlow 09 Aug '05

09 Aug '05

On 09 August 2005 12:25, Adrian Hey wrote: > Well this is actually a couple of questions.. > > First question is how does ghc do case analysis on algebraic > data type constructors. I always assumed it was by using some > kind of jump table on a tag field, but I don't know really (I'm > not even sure ghc makes use of tag fields as such). If the number of constructors is less than or equal to 8 (currently), GHC uses vectored returns. The case exrpession pushes a return address on the stack that is a pointer to a vector, and the code for the constructor jumps to the appropriate entry. For >8 constructors, GHC uses a direct return address and then a comparison on the tag value extracted from the constructor's info table. > Second question is really the same question but for literals. > What search algorithm is employed and is it likely to be > worth hand coding something else? (a binary search maybe). > > I'm thinking of code like this.. > case n of > 0 -> > 7 -> > 34622 -> > .. lots more > _ -> GHC's code generator turns these into binary trees or table jumps, or a combination of the two, depending on the population. But if you're compiling via C, then we just generate a switch and leave it up to the C compiler to choose. Cheers, Simon

1 0

Question about ghc case analysis
by Adrian Hey 09 Aug '05

09 Aug '05

Hello, Well this is actually a couple of questions.. First question is how does ghc do case analysis on algebraic data type constructors. I always assumed it was by using some kind of jump table on a tag field, but I don't know really (I'm not even sure ghc makes use of tag fields as such). Second question is really the same question but for literals. What search algorithm is employed and is it likely to be worth hand coding something else? (a binary search maybe). I'm thinking of code like this.. case n of 0 -> 7 -> 34622 -> .. lots more _ -> Thanks -- Adrian Hey

1 0

RE: Inferred type is less polymorphic than expected?
by Simon Peyton-Jones 09 Aug '05

09 Aug '05

| > Are you saying, that the second error causes the first one? Thus, | > everything is caused by 'printer' being recursively defined? | Yes, that's what I believe. I'm not sure why it shows the first error | message at all; in my experience, strange things happen when ghc | continues after an error message that you shouldn't pay too much | attention to. Perhaps ghc-6.4 just assumes identical contexts in | recursive groups without checking the type signatures. After an error in a function definition for f, GHC carries on assuming the function has type f :: forall a. a That very seldom leads to subsequent errors, but maybe it did this time. The way to find out is to show the program that elicits this message but not the other. Simon

2 1

RE: C--
by Simon Peyton-Jones 09 Aug '05

09 Aug '05

We're already compiling via an intermediate data type that is closely based on C--. That internal data type is used regardless of whether you emit C, asm, or C--. Actually using C-- itself as an output medium keeps slipping down the agenda, mainly because no one asks for it! But I still fully intend to do it. 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: 01 August 2005 13:13 | To: Bulat Ziganshin; glasgow-haskell-users(a)haskell.org | Subject: RE: C-- | | On 31 July 2005 08:10, Bulat Ziganshin wrote: | | > can you please say about value of using C-- in GHC? will this | > reduce compile time, increase speed of compiled programs, improve | > portability or make some other effect? would the C-- compile path | > replace asm or C path? | | It should reduce compile time compared to compiling via C, though I | suspect it will still be slower than using GHC's built-in native code | generator. | | It should improve the speed of compiled programs, because C-- will be | using its own, efficient, calling convention. For example, this will | mean that some arguments can be passed in registers on x86, which we | can't do currently because of a combination of the lack of registers and | limitations in what we can convince gcc to do. | | It should improve portability, because there is less work in GHC | required to compile via C-- on a new platform: no mangler to modify, for | example. | | Eventually, we hope the registerised via-C path would become redundant. | The unregisterised path is still useful for bootstrapping, given that | more platforms have a C compiler than a C-- compiler (if C-- were to | become ubiquitous, the unregisterised path would become irrelevant too). | | Cheers, | Simon | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: how to return ghc to Cabal-1.0
by Simon Marlow 09 Aug '05

09 Aug '05

On 08 August 2005 13:42, Serge D. Mechveliani wrote: > Please, how to return GHC to Cabal-1.0 ? > > I have installed ghc-6.4.1.20050806-i386-unknown-linux > in my home. > Then I tried to upgrade Cabal in GHC to 1.1.1. > For this, I istalled Cabal-1.1.1 to my home. > > Then, there appeared a certain difficulty in building application. > > But now I decide to stop these experiments > (have not time now to struggle with complications) and to return to > regular > ghc-6.4.1 (with Cabal-1.0). > > And cannot! > > Then, I remove the installation directory and install > ghc-6.4.1-pre binary by new, starting from `configure'. > > Then ghci -package Cabal > > crashes, reporting something of Cabal-1.1.1. You should really cut and paste the *exact* command and error message, we can't tell much from this. Don't worry about spamming us with too much detail. To return to Cabal-1.0, you should simply unregister Cabal-1.1.1, assuming you haven't also unregistered Cabal-1.0. 'ghc-pkg list' will tell you which packages are registered, and whether they are registered globally or locally to you. 'ghc-pkg unregister Cabal-1.1.1' will unregister Cabal-1.1.1, for example. If it is registered for you only, then you will need to add the --user flag. Additionally, you probably want to delete the files that belong to Cabal-1.1.1. 'ghc-pkg describe Cabal-1.1.1' will tell you where the files live (before you unregister it, of course). Cheers, Simon

2 1