- Glasgow-haskell-users

Is there a way to optimize out some foreign calls?
by Brian Hulley 04 Apr '06

04 Apr '06

H - I'm wondering if there is any way to specify that certain sequences of foreign calls can be merged into a single foreign call. For example, in a common situation where a state of a foreign API is pushed and popped so that the previous state is restored, I'd like successive pops to avoid wasting time restoring intermediate states as in: -- push a state onto the API's state stack (without changing the state) foreign import ccall api_push :: State -> IO () -- discards the state at the top of the stack foreign import ccall api_pop :: IO () -- synchronises the API's state with the state at the top of the stack foreign import ccall api_sync :: IO () use :: State -> IO () -> IO () use s action = do api_push s api_sync action api_pop api_sync -- put the API back into the previous state main = do use State1 $ do actionIn1a use State2 $ do actionIn2 use State3 $ do actionIn3 actionIn1b If 'use' is inlined, the compiler would (presumably) produce code like: main = do api_push State1 api_sync actionIn1a api_push State2 api_sync actionIn2 api_push State3 api_sync actionIn3 api_pop api_sync -- This is a waste of time api_pop api_sync actionIn1b api_pop api_sync I'm wondering if there is any way to cause the compiler to avoid the wasteful call to api_sync above. I'm thinking in terms of some way of marking foreign functions to specify how they can be optimized out or specifying rewrite sequences eg x >> api_sync >> api_pop >> api_sync >> y = x >> api_pop >> api_sync >> y I've read the manual (7.10) on rewrite rules, but I'm having difficulty understanding how to express the lhs of the above equation as a rewrite rule so that it matches a sequence anywhere in a do block (to deal with nested parentheses and the use of >>= instead of >>) Any ideas? Thanks, Brian.

1 0

readChan and unGetChan?
by Li, Peng 04 Apr '06

04 Apr '06

Suppose the following happens: (1) Thread A calls readChan on an empty channel and waits (2) Thread B puts something to the read-end of the channel using unGetChan When a GHC program does this, both threads are blocked! Is it the behaviour we really want for unGetChan, or should we fix the implementation for Control.Concurrent.Chan? Thanks, Peng

2 1

Dumb guy needs help
by Davey_dude 03 Apr '06

03 Apr '06

Im new to Haskell, hugs in particular, and was hoping you could help me solve a problem. It should be pretty easy. I have to use hugs to create an expression "data Exp = Plus Exp Exp| Sub Exp Exp| Mult Exp Exp| Power Exp Exp | Number [Int]" to define a constant "ex1 :: Exp" that represents the function ((3*4) + (2*(12^2))) - 2. Exp is an expression where numbers are represented by a list of digits (540 is [5,4,0]). Got any ideas. Any help is greatly needed! -- View this message in context: http://www.nabble.com/Dumb-guy-needs-help-t1386770.html#a3724993 Sent from the Haskell - Glasgow-haskell-users forum at Nabble.com.

2 1

Still problems building ghc 6.5 with ghc 6.4
by Michael Marte 01 Apr '06

01 Apr '06

Hello *, when building ghc 6.5 with ghc 6.4 and alex 2.0.1, the build fails as follows: make -C ghc/compiler stage=2 make[2]: Entering directory `/home/marte/fptools/ghc/compiler' ../../ghc/compiler/ghc-inplace -H16m -O -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -threaded -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -ignore-package ghc -fgenerics -funbox-strict-fields -c parser/Lexer.hs -o stage2/parser/Lexer.o -ohi stage2/parser/Lexer.hi parser/Lexer.x:578:10: lexical error in string/character literal at character '\955' <<ghc: 51822676 bytes, 5 GCs, 98216/98216 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.62 MUT (0.84 elapsed), 0.11 GC (0.13 elapsed) :ghc>> make[2]: *** [stage2/parser/Lexer.o] Error 1 make[2]: Leaving directory `/home/marte/fptools/ghc/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/home/marte/fptools' make: *** [bootstrap2] Error 2 Is this problem caused by alex? Michael

2 10

Message "GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#'" building GHC with additional primitive operation
by Thorkil Naur 31 Mar '06

31 Mar '06

Hello, Using the marvelous Haskell language and the equally marvelous GHC implementation, I have over the past couple of years revived my old interest in integer factorization. The built-in support for multi-precision integer arithmetic makes Haskell a fine choice for this kind of computation. And working with numbers with several hundreds of decimal digits, I at least hope that the (undoubted) overhead of GHC Haskell when compared to, say, direct use of C is easily drowned by the time taken by the individual arithmetic operations. And Haskell is so much easier to use than C. (In addition to GHC, I use Hugs.) I have come to a point, however, where I wish to squeeze some additional drops of performance out of my programs. For that, I would like direct access to some selection of gmp functions, in addition to those that are available through the use of Integer operators. For example, to experiment with the use of Montgomery modular multiplication (Mathematics of Computation, volume 44, number 170, April 1985, pages 519-521), I would like access to the mpz_tdiv_q_2exp function that divides an integer by a power of 2 by efficient shift operations. I have considered using FFI, but although I have not given up this idea, it seems hard to do in a manner that avoids some potentially significant additional overhead. So, the idea that I am currently exploring is to add some new primitive operations to Haskell as supported by GHC. Offhand, I would not have considered it likely that going in this direction would be particularly easy. So I was happy to discover that GHC already supports certain additional direct gmp calls. For example, the GHC.Num module includes the gcdInteger function that more or less directly calls mpz_gcd, everything in a seemingly straightforward manner. Unfortunately, my attempt to mimic this has failed. In detail, this is what I have done: 1. I have expanded ghc-6.4.1-src.tar.bz2 and tried to build it (./configure + make). No errors detected and seemingly, this produced a working GHC compiler. 2. Then I changed the source as indicated in the following that compares the original with my changed version: tn@linux:~/tn/Haskell/ghc/unpack> diff -r original/ . | grep -v '^Only in \./ghc' diff -r original/ghc-6.4.1/ghc/compiler/prelude/primops.txt.pp ./ghc-6.4.1/ghc/compiler/prelude/primops.txt.pp 6a7 > -- 2006-Mar-20 20.29 / TN: Experiment with additional primitive operations 429a431,435 > primop IntegerQuot2ExpOp "quotInteger2Exp#" GenPrimOp > Int# -> ByteArr# -> Int# -> (# Int#, ByteArr# #) > {Rounds towards zero.} > with out_of_line = True > diff -r original/ghc-6.4.1/ghc/includes/StgMiscClosures.h ./ghc-6.4.1/ghc/includes/StgMiscClosures.h 10a11,12 > * 2006-Mar-21 17.05 / TN: Experiment with additional primitive operations > * 491a494 > RTS_FUN(quotInteger2Expzh_fast); diff -r original/ghc-6.4.1/ghc/rts/Linker.c ./ghc-6.4.1/ghc/rts/Linker.c 6a7,8 > * 2006-Mar-21 17.06 / TN: Experiment with additional primitive operations > * 535a538 > SymX(quotInteger2Expzh_fast) \ diff -r original/ghc-6.4.1/ghc/rts/PrimOps.cmm ./ghc-6.4.1/ghc/rts/PrimOps.cmm 6a7,8 > * 2006-03-20 23.50 / TN: Experiment with additional primitive operations > * 29a32,36 > quotInteger2Expzh_fast > { > // At this point, the call of mpz_tdiv_q_2exp will eventually be inserted > } > Only in .: original Only in .: save tn@linux:~/tn/Haskell/ghc/unpack> With these changes, make fails with the error messages rm -f GHC/PrimopWrappers.o; if [ ! -d GHC/PrimopWrappers_split ]; then mkdir GHC/PrimopWrappers_split; else /usr/bin/find GHC/PrimopWrappers_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/PrimopWrappers.hs -o GHC/PrimopWrappers.o -ohi GHC/PrimopWrappers.hi GHC/PrimopWrappers.hs:133:29: Not in scope: `GHC.Prim.quotInteger2Exp#' <<ghc: 32263284 bytes, 4 GCs, 97412/97412 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.19 elapsed), 0.02 GC (0.04 elapsed) :ghc>> make[2]: *** [GHC/PrimopWrappers.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/tn/tn/Haskell/ghc/unpack/ghc-6.4.1/libraries' make: *** [build] Error 1 So, evidently, it is not as easy to add new primitive operations as I thought. (Or, which is most likely, but embarrasingly, closer to the truth: I am not as clever as I thought I was.) In any case, if someone is able to provide some hint that enables me to proceed in this matter, I would be most grateful. For the record: tn@linux:~/tn/tmp/Haskell/work> gcc -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java,ada --disable-checking --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind --host=i586-suse-linux Thread model: posix gcc version 4.0.2 20050901 (prerelease) (SUSE Linux) tn@linux:~/tn/tmp/Haskell/work> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2 tn@linux:~/tn/tmp/Haskell/work> Best regards Thorkil Naur

3 9

Re: GHC 6.4.2 release candidates
by Simon Marlow 30 Mar '06

30 Mar '06

Duncan Coutts wrote: > On Tue, 2006-03-28 at 12:34 +0100, Simon Marlow wrote: > >>Hi Folks, >> >>We're finally in release-candidate mode for 6.4.2. Please grab a >>snapshot and try it out: >> >>http://www.haskell.org/ghc/dist/stable/dist/ >> >>(scroll to the bottom for the latest). The available builds are: >>x86_64-unknown-linux (Fedora Core 5), i386-unknown-linux (glibc 2.3 >>era), and Windows (i386-unknown-mingw32). >> >>There's a source snapshot if you want to build yourself - please try >>this if you can, we need to make sure the source bundle builds cleanly. > > > One thing that Don, Ian and I were discussing was having a tarball of > the testsuite and nofib performance suite to go along with the official > 6.4.2 release. This would make it easier for us to be consistent. Having > the testsuite go with the ghc release will mean we can be sure about > which tests we expect to fail on x86/amd64 and we can use that as a > comparison for the other arch ports. > > If we could get a tarball of the testsuite out before the release then > we can send in our results for various arches and that could be included > into the know failures files for the testsuite that goes official > release. It'd give us a better sense of the state of things on each > arch. Perhaps we could record testsuite results for different arches on > the ghc wiki somewhere. This is a good idea. I'm just clearling up the last of the current failures, and I'll make the tarball. Cheers, Simon

1 0

RE: Possible runtime overhead of wrapping the IO monad?
by Simon Peyton-Jones 30 Mar '06

30 Mar '06

| -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Brian Hulley | Sent: 30 March 2006 13:14 | To: John Meacham; glasgow-haskell-users(a)haskell.org | Subject: Re: Possible runtime overhead of wrapping the IO monad? | | John Meacham wrote: | > On Thu, Mar 30, 2006 at 03:50:06AM +0100, Brian Hulley wrote: | >> where the intention is that the callback will take the width and | >> height of the window and return a RenderM action, the problem is | >> that because the FFI does not allow RenderM to appear in a foreign | >> type. | > | > it should, the types in foreign declarations should "see through" | > newtypes. | | Unfortunately GHC does not seem to support this: | | foreign import ccall duma_clear :: Word.Word32 -> RenderM () | | Unacceptable result type in foreign declaration: RenderM () | When checking declaration: | foreign import ccall safe "static &duma_clear" | duma_clear :: GHC.Word.Word32 -> RenderM () | | even though the FFI spec agrees with you (Section 3.2): | | The argument types ati produced by fatype must be | marshallable foreign types; that is, each ati is either (1) | a basic foreign type or (2) a type synonym or renamed | datatype of a marshallable foreign type. Moreover, the | result type rt produced by frtype must be a | marshallable foreign result type; that is, | it is either a marshallable foreign type, ... GHC does unwrap newtype result types, as in foreign import foo :: Int -> IO Boogle newtype Boogle = B Int which is what the manual meant. I'd never thought of newtyping the IO monad itself. Why are you doing that, incidentally? I guess it wouldn't be too hard to unwrap the monad type too. If it's important to you, please submit a feature request. Thanks Simon

2 2

GHC 6.5 on Mac Os X
by Christopher Brown 30 Mar '06

30 Mar '06

Hi, I am trying to get GHC 6.5 to compile on Mac OS X and I am not having much success. I managed to get the CVS version to build without any problems on my linux machine, and when I followed the same steps to complie on my mac I get errors. Here are the steps I followed on my mac autoreconf ./configure make I am using Happy version 1.14 alex version 2.0.1 I also tried 2 different builds, one using gcc 3.3 and the other using gcc 4.0 With gcc 4.0 I get the following error: ------------------------------------------------------------------------ ==fptools== make all - --no-print-directory -r; in /Users/chrisbrown/fptools/ghc/utils/hsc2hs ------------------------------------------------------------------------ /usr/local/bin//ghc -H16m -O -i../../lib/compat -ignore-package Cabal -Rghc-timing -Wall -c Main.hs -o Main.o -ohi Main.hi /tmp/ghc7100.s:unknown:Undefined local symbol L___DISCARD__$stuc <<ghc: 795261768 bytes, 1901 GCs, 10806254/16691432 avg/max bytes residency (10 samples), 46M in use, 0.10 INIT (0.00 elapsed), 9.72 MUT (42.51 elapsed), 7.31 GC (9.09 elapsed) :ghc>> make[3]: *** [Main.o] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 dhcp293e:~/fptools chrisbrown$ And with gcc 3.3 I get: /usr/local/bin//ghc -H16m -O -istage1/utils -istage1/basicTypes - istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename - istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/ specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn - istage1/simplStg -istage1/codeGen -istage1/main -istage1/ profiling -istage1/parser -istage1/cprAnalysis -istage1/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen - InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc- timing -H16M '-#include "hschooks.h"' -i../lib/compat -ignore- package Cabal -c deSugar/Desugar.lhs -o stage1/deSugar/Desugar.o - ohi stage1/deSugar/Desugar.hi /tmp/ghc7343.s:unknown:Undefined local symbol L___DISCASD__$stub <<ghc: 137823188 bytes, 39 GCs, 5163380/11942184 avg/max bytes residency (4 samples), 23M in use, 0.10 INIT (0.00 elapsed), 1.56 MUT (4.83 elapsed), 1.01 GC (1.29 elapsed) :ghc>> make[2]: *** [stage1/deSugar/Desugar.o] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 dhcp293e:~/fptools chrisbrown$ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1809) dhcp293e:~/fptools chrisbrown$ These error messages seem to be non-deterministic. I am running Mac OS X 10.4.1 with 1 gig RAM. Cheers, Chris. Christopher Brown Ph.D. Student University of Kent. UK. http://www.cs.kent.ac.uk/people/rpg/cmb21/index.html

5 4

How to access hs_free_fun_ptr from a Visual Studio DLL
by Brian Hulley 28 Mar '06

28 Mar '06

Hi - I have the following declaration and code in part of a DLL I'm writing: extern "C" { typedef void (*HsFunPtr)(); extern __declspec(dllimport) void hs_free_fun_ptr(HsFunPtr fp); } enum ECallback { ECallback_Render, ECallback_COUNT}; HsFunPtr callback[ECallback_COUNT]; void SetCallback(ECallback c, HsFunPtr fp){ if (callback[c]){ hs_free_fun_ptr(callback[c]); } callback[c] = fp; } However when I try to build the DLL, I get the following error from Visual Studio: Duma.obj : error LNK2019: unresolved external symbol __imp__hs_free_fun_ptr So the problem is that the VS is adding __imp__ onto the function name even though I've specified it as extern "C" and is moreover just ignoring the dllimport directive and complaining that it can't find the function. I've also tried deleting the "extern" before the "__declspec" but this doesn't make any difference. Also, I've tried putting hs_free_fun_ptr into the IMPORTS section of the def file but this doesn't make any difference either (I don't even think def files have an IMPORTS section so it's probably just being ignored). I've got a horrible feeling that VS will need a .lib file for ghc to allow it to link against hs_free_fun_ptr but I don't have a clue how to generate one... Does anyone know how I can get everything to link? Thanks, Brian.

5 12

RE: GHC 6.4.2 release candidates
by Simon Marlow 28 Mar '06

28 Mar '06

On 28 March 2006 13:41, Bulat Ziganshin wrote: > Tuesday, March 28, 2006, 3:34:59 PM, you wrote: > >> We're finally in release-candidate mode for 6.4.2. Please grab a > > i've written your email about ghc documentation that lists obsolete > "-ddump" options and don't mention new ones such as "-ddump-cmm". are > you got it? > > i can even scan the ghc 6.4.1 docs and write you about all oddities i > can see. just that i can recall now - "-fgenerics" section says > something about ghc 5.02, "-fparr" is still undocumented, TH section > should contain reference to wiki page and so on Thanks Bulat, I got your earlier message, sorry for not replying. It would be great if you could list these things - please open a ticket on the bug tracker. Cheers, Simon

1 0