- Glasgow-haskell-users

Re: [Haskell] Haskell 6.4 perfomance
by Keean Schupke 25 Mar '05

25 Mar '05

Think this should really go to glasgow-haskell-users... If this is true - how do I get ghc to use C--, and is it really faster than using gcc as a backend with all the bells & whistles turned on (for a pentium-III) something like "-O3 -mcpu=pentium3 -march=pentium3 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -fno-crossjumping -mfpmath=sse,387 -ffast-math -fsched-spec-load -fprefetch-loop-arrays -maccumulate-outgoing-args -fmove-all-movables -freduce-all-givs" Keean. Alexandre wrote: > As I heard, 6.4 version of the Haskell using C-- backend and make lots > of the resulting code perfomance (programs executed faster). > If so, does any test/comparison with other languages available? > > Thank you in advance, > Regards, > /Alexandre. >

2 1

RE: comments on the GHC API
by Simon Marlow 23 Mar '05

23 Mar '05

On 22 March 2005 17:49, Matthias Neubauer wrote: > ... we also need the state after renaming, but we then have to stop, I > suppose! Yes, the HaRE folks also want the renamed abstract syntax too. We haven't quite figured out how best to make it available: renaming is intertwined with typechecking a bit. > Because we want to do do our own typechecking, stopping after ghc's > typechecking would be to late: in case of a type error, ghc falls back > into the wrong context (at least that's what's happening right now > when doing a :load inside ghci ...). > >>> We, for our part, would need parts of the intermediate result >>> (that is, the type environment and class declarations) existing >>> either before parsing A, after parsing A, or, even better, after >>> renaming A. Other users may be interested in other intermediate >>> results. > > Is there a way to get access to all the identifiers that are > *imported* into the current module? Having that piece of information > at hand, we could then use *lookupThing* to cumulate the initial type > environment and the initial class environment for our analysis. > > Or do you see another/better way of doing that? The ModIface contains the usages, which includes everything that is *used* by the current module (not quite the same as everything that is imported, because this is a list of original names, not imported names). There is also the mi_globals list (in ModIface), which contains everything in scope at the top level of the module. From that I guess you could find everything that is imported by subtracting things that are defined in the local module. Cheers, Simon

1 0

RE: porting ghc-6.4 to x86_64
by Simon Marlow 23 Mar '05

23 Mar '05

On 23 March 2005 09:18, Andrei A. Voropaev wrote: > Sorry. Forgot to ask the next question on this process. Now that I > have unregistered compiler, how do I build the registered one? > > I've tried to start with new tree and then run > > ./configure --with-ghc=T/ghc/compiler/ghc-inplace > make Yes, that should do it. Except that x86_64 doesn't have support for object splitting yet, so you need to add a file mk/build.mk with the line: SplitObjs=NO to turn off splitting. For some reason that I don't quite understand, it seems from the error message that you posted the compiler is attempting to generate code for -split-objs, which is causing the assembler to fall over. Turning off splitting should fix that anyway. Cheers, Simon

2 1

RE: porting ghc-6.4 to x86_64
by Simon Marlow 23 Mar '05

23 Mar '05

On 22 March 2005 10:10, Andrei A. Voropaev wrote: > Well, looking at the makefile it becomes clear, that it must do so. > ------------------------------------- > # Make DerivedConstants.h for the compiler > > all :: DerivedConstants.h > > mkDerivedConstants.c : $(H_CONFIG) > > mkDerivedConstantsHdr : mkDerivedConstants.o > $(CC) -o $@ $(CC_OPTS) $(LD_OPTS) mkDerivedConstants.o > > DerivedConstants.h : mkDerivedConstantsHdr > ./mkDerivedConstantsHdr >$@ > > CLEAN_FILES += mkDerivedConstantsHdr$(exeext) DerivedConstants.h > ------------------------------------ > > Since ghcautoconf.h is new this triggers update for > mkDerivedConstants.c which in turn updates mkDerivedConstantsHdr > which in turn updates DerivedConstants.h. I guess I should also touch > the mkDerivedConstants.c to avoid the updates. Am I correct? Duh, sorry about that. The full list of things you need to touch are: $ touch ghcautoconf.h DerivedConstants.h GHCConstants.h mkDerivedConstants.c mkDerivedConstantsHdr mkDerivedConstants.o mkGHCConstants mkGHCConstants.o I must have avoided making in ghc/includes when I did the bootstrap myself. Thanks for highlighting the problem. Cheers, Simon

2 2

RE: comments on the GHC API
by Simon Marlow 22 Mar '05

22 Mar '05

Hi Matthias, I think most of what you're asking for is planned... On 17 March 2005 16:59, Matthias Neubauer wrote: > I just had a first look at the sketch for the planned GHC API > (ghc/compiler/main/GHC.hs), since we are very keen on using it ... > > Our group would mostly like to make use of a compilation > manager/module system implementation for Haskell---so these are the > parts I concentrated on for now. More specifically, the scenario how > we would like to use a GHC library is the following: > > So far, we've implemented a static analysis for (single) Haskell > modules. To make our tool ready for a wider use, we would like extend > it to full Haskell 98 (plus extensions). What we therefore would like > to ask a GHC library is, given a specific module A, to compile all the > other modules that A is dependent on, load them into a context for A, > and start processing A up to the point where the actual type-checking > of A would commence. After that, we would like to query the library > about the initial (type) environment of A (that is, get out a complete > summary of all the imported bindings, classes, methods, etc) to then > proceed with our own analysis instead of using GHC's type inferencer. > > I see two basic ways how a GHC library could help us to achieve this: > > - The library both offers a separate module dependency analysis and > also lets us use the compiler in one-shot mode. We then could first > calculate the dependencies of A, compile them separately, and > calculate the initial environment of A manually by combining the > interfaces of the imported modules. Of course, we would also need > the possibility to access the imports of A (including renamings and > such) without the need to compile A as a whole. > > - Loading a set of targets (using *load*) can be controlled in a more > fine-grained way. Instead of just offering the possibility to > compile a set of targets either completely or not at all, there is > an option to compile targets only up to a certain compilation phase > (or alternatively, to optionally keep intermediate results occurring > between the phases to be able to retrieve them afterwards.) The 'load' function lets you load only up to a certain module, and the JustTypecheck mode stops before code generation and lets you inspect the typechecked code. Using this, you can compile one module at a time and get the typechecked code out - does that sound ok? There are some areas to do with getting access to the typechecked class declarations and some other parts of the module that we have still to sort out. The refactoring folks also want access to the renamed code (before typechecking), which includes more of the original declarations. > We, for our part, would need parts of the intermediate result (that > is, the type environment and class declarations) existing either > before parsing A, after parsing A, or, even better, after renaming > A. Other users may be interested in other intermediate results. > > What do others think? > > Some more, rather random, remarks: > > - I guess v_CmdLineMode and friends are iorefs that are supposed to > live globally in GHC.hs. Couldn't you also pack them into a separate > data type created by *init* and later share them between several > sessions. The CmdLineMode will be private to the front end only, but there's a related GhcMode that now lives in the DynFlags. Take a look at the HEAD as it is now (I just commmitted some big changes in this area in preparation for the GHC API). > Maybe we could even introduce a Session monad? Looking at all the > functions again, they all seem to have Session arguments ... > > - I guess the exported name *GhcSession* should read *Session* (or > better the other way around) > > - Same for *GhcMode* vs. *GhciMode* > > - What's the purpose of having a mode argument for "newSession"? As I > read the rest of the API, *load* is the only way to trigger the > compilation of targets. And *load* seems to be intended to work > similar to the interactive mode only. load might compile and link object code in --make mode, or compile and dynamically-link bytecode in --interactive mode. > - What are Module, ModSummary, ModIface, HsTypecheckedGroup, HsGroup, > TyThing, and Type standing for (I know of course ...)? How > complicated would it be to return already existing (TH) data types > instead of exposing/specifying more of GHC's internals? The TH types aren't really rich enough for all the purposes we expect this interface to be used for. In particular, the data type needs to include the full GHC language, it needs to include full source location information (the refactoring folks need this, and so does Visual Studio), and it needs to include type information for identifiers. Only HsSyn includes all this. Cheers, Simon

2 1

RE: porting ghc-6.4 to x86_64
by Simon Marlow 22 Mar '05

22 Mar '05

On 22 March 2005 09:24, Andrei A. Voropaev wrote: > On Tue, Mar 22, 2005 at 10:06:13AM +0100, Andrei A. Voropaev wrote: >> On Mon, Mar 21, 2005 at 02:20:25PM -0000, Simon Marlow wrote: >> [...] >>>>> Did you copy across ghc/includes/DerivedConstants.h and >>>>> ghc/includes/GHCConstants.h from the target to the host? I think >>>>> that should fix the above error (the docs do say you have to do >>>>> this, so perhaps it's something else). >>>> >>>> Sure enough I did. As I said, I carefully followed the >>>> instructions. I repeated the whole process 3 times to make sure I >>>> didn't forget something :) >>> >>> So could you check the values of SIZEOF_VOID_P (in ghcautoconf.h) >>> and SIZEOF_mp_limb_t (in DerivedConstants.h)? They should both be >>> 8 in the versions of these files copied from the target. >> >> Aha. The values are different. Carefull watching of the >> DerivedConstants.h showed that it was overwritten when I did 'cd >> H/ghc && make boot'. And yes, I did touch of all the copied files. > > Even worse. This file gets overwritten on subsequent steps as well. > So, my attempts to copy the correct one from the T machine again and > again fail. Ok, looks like I need to update the instructions. Does this sequence work: - cd H/ghc/includes && make boot - copy files from T/ghc/includes to H/ghc/includes - touch the files - cd H/ghc/includes && make <<-- should do nothing now Cheers, Simon

2 2

RE: porting ghc-6.4 to x86_64
by Simon Marlow 22 Mar '05

22 Mar '05

On 21 March 2005 14:12, Andrei A. Voropaev wrote: > On Mon, Mar 21, 2005 at 02:09:03PM -0000, Simon Marlow wrote: >> On 21 March 2005 09:52, Andrei A. Voropaev wrote: >> >>> I know that this has been done already (at least by RedHat), but >>> since I don't use RedHat (or any other distro of linux) and instead >>> compiled everything myself, I have to bootstrap ghc as well. So I'm >>> carefully following the instruction. On my host (i386) I have >>> ghc-6.2.2 (and ghc-6.4). Looks like I have some problem. >>> >>> As far as I understand this should fail. >>> >>> $ cd H/ghc && make boot && make >>> ..... >>> ==fptools== make all -r; >>> in /usr/local/src/ghc-6.4/ghc/rts >>> >> ------------------------------------------------------------------------ >>> ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static >>> -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h >>> -#include RtsUtils.h -#include StgRun.h -#include Schedule.h >>> -#include Printer.h -#include Sanity.h -#include STM.h -#include >>> Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h >>> -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h >>> -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o >>> In file included from Apply.cmm:13: >>> /usr/local/src/ghc-6.4/ghc/includes/Cmm.h:288: #error mp_limb_t != >>> StgWord: assumptions in PrimOps.cmm are now false >>> make[1]: *** [Apply.o] Error 1 >>> make: *** [all] Error 1 >> >> Yes, I hit exactly this problem when I recently bootstrapped on >> x86_64. IIRC, the solution was to make the RTS compile. >> >> Did you copy across ghc/includes/DerivedConstants.h and >> ghc/includes/GHCConstants.h from the target to the host? I think >> that should fix the above error (the docs do say you have to do >> this, so perhaps it's something else). > > Sure enough I did. As I said, I carefully followed the instructions. I > repeated the whole process 3 times to make sure I didn't forget > something :) So could you check the values of SIZEOF_VOID_P (in ghcautoconf.h) and SIZEOF_mp_limb_t (in DerivedConstants.h)? They should both be 8 in the versions of these files copied from the target. Cheers, Simon

2 2

Updated 6.4 Windows installer RC
by Sigbjorn Finne 21 Mar '05

21 Mar '05

An updated version of the Windows installer for ghc-6.4 is now available for testing, http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-bld1.msi md5 checksum: 4a55a5614587cef07a19d7f7728f3a83 It hopefully sorts out the showstopping profiling problems that people have reported; let me know if it doesn't and/or there are other packaging snafus. If nothing major pops up, I'll consider the bits blessed and hook the installer up to the GHC downloads page. Note: - the installer re-uses the product GUIDs of the original 6.4 installer, so if you've already got it installed, it'll remove that install the first time you run it. - the HGL and Win32 packages have been removed from the installer at the suggestion of the package author(s); deemed not quite yet ready for primetime, I believe. --sigbjorn

2 2

RE: porting ghc-6.4 to x86_64
by Simon Marlow 21 Mar '05

21 Mar '05

On 21 March 2005 09:52, Andrei A. Voropaev wrote: > I know that this has been done already (at least by RedHat), but > since I > don't use RedHat (or any other distro of linux) and instead compiled > everything myself, I have to bootstrap ghc as well. So I'm carefully > following the instruction. On my host (i386) I have ghc-6.2.2 (and > ghc-6.4). Looks like I have some problem. > > As far as I understand this should fail. > > $ cd H/ghc && make boot && make > ..... > ==fptools== make all -r; > in /usr/local/src/ghc-6.4/ghc/rts > ------------------------------------------------------------------------ > ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static > -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h > -#include RtsUtils.h -#include StgRun.h -#include Schedule.h > -#include Printer.h -#include Sanity.h -#include STM.h -#include > Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h > -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h > -#include Apply.h -fvia-C -dcmm-lint -c Apply.cmm -o Apply.o > In file included from Apply.cmm:13: > /usr/local/src/ghc-6.4/ghc/includes/Cmm.h:288: #error mp_limb_t != > StgWord: assumptions in PrimOps.cmm are now false > make[1]: *** [Apply.o] Error 1 > make: *** [all] Error 1 Yes, I hit exactly this problem when I recently bootstrapped on x86_64. IIRC, the solution was to make the RTS compile. Did you copy across ghc/includes/DerivedConstants.h and ghc/includes/GHCConstants.h from the target to the host? I think that should fix the above error (the docs do say you have to do this, so perhaps it's something else). Cheers, Simon

2 1

Unicode Source / Keyboard Layout
by Sven Moritz Hallberg 21 Mar '05

21 Mar '05

Greetings GHC and Haskell folk, please excuse the cross-post. This is a coordinational message. :) I've been longing for Unicode (UTF-8) input support in GHC for a long time. I am currently customizing a keyboard layout to include many mathematical operators and special characters which would be very useful in writing even prettier (!) Haskell code. I'd be interested to complete the keyboard layout and make it public, to raise the value of Unicode input support. When will it happen? To make the fun complete, I think a few adjustments to the Haskell grammar would be in order, so, guessing the relevant people read these lists, may I suggest the following? 1. In addition to the backslash, accept "mathematical * small lamda" (U+1D6CC, U+1D706, U+1D740, U+1D77A, and U+1D7B4) for lambda abstractions. Leave "greek small letter lamda" as a regular letter, so the Greeks can write their native language. 2. In addition to "->", accept "rightwards arrow" U+2192 as the function arrow. 3. Accept "leftwards arrow" U+2190 in do and notation. 4. Accept "leftwards arrow-tail" U+2919 in arrow notation. 5. Accept "rightwards double arrow" U+21D2 in addition to "=>" for type contexts. 6. Accept "for all" U+2200 in addition to the forall keyword. 7. Remove the symbols for clearly prefix operators (n-ary summation and product, logical not, etc.) from the set of characters used to build binary operators. Leave them as identifier letters, so they can be bound to regular functions. Did I forget anything? Being a Macintosh user, I've assembled a Mac OS keylayout file. For anyone interested, the current version can be downloaded: http://www.scannedinavian.org/~pesco/distfiles/hallberg-dvorak.zip The base layout is Dvorak. Caps Lock switches to Greek mode, where 'a' changes to alpha, 'b' to beta, etc. Alt (Option) accesses the symbol map. Shift-Alt gives a second level of symbols. Currently, the symbol map contains german Umlaute for me. I'll most probably move them behind dead-keys soon, though. (A-e giving Ä etc.) I can produce an XKB map for X11 once I'm happy with the layout. It would be cool if someone could also port the thing to Windows around that time. Please get in touch if you're interested. Let me know what you think, Sven Moritz Hallberg

1 0