- Glasgow-haskell-users

RE: jhc vs ghc and the surprising result involving ghcgeneratedassembly.
by Simon Marlow 02 Nov '05

02 Nov '05

On 02 November 2005 13:59, Florian Weimer wrote: > However, beginning with GCC 3.4, you can use: > > extern void bar(); > > void foo() > { > void (*p)(void) = bar; > p(); > } Interesting.. though I'm not sure I'm comfortable with relying on gcc's tail call optimisation to do the right thing. Aren't there side conditions that might prevent it from kicking in? > And the indirect call is turned into a direct jump. Tail recursive > calls and really indirect tail calls are also optimzed. Together with > -fomit-frame-pointer, this could give you what you need, without > post-processing the generated assembler code (which is desirable > because the asm volatile statements inhibit further optimization). > > Is it correct that you use indirect gotos across functions? Such > gotos aren't supported by GCC and work only by accident. Yes, but cross-function gotos are always to the beginning of a function. Also, our post-processor removes the function prologue from the asm. GHC via C has always worked "by accident" :-) But it has worked for a long time with careful tweaking of the post-processor (known as the mangler) for each new version of gcc. Yes, we're living dangerously, and it's getting harder, but we're still alive (just). Cheers, Simon

3 3

Array operations and pinning
by Rene de Visser 02 Nov '05

02 Nov '05

Hello, Where is the documentation on how pinning works in the GHC garbage collector (from a GHC users point of view). I have copied the following code from array/IO.hs and am thinking that it is assuming that the array is pinned? What triggers the pinning? On a second note. Why is the type signiture so constricted. The code below works on any IOUArray (which is very usefull, not just on Int Word8). Naturally this assumes the particular in memory array layout that GHC uses on a particular platform, so would not be compatible (probably) with other Haskell compilers. Rene. hPutArray :: Handle -- ^ Handle to write to -> IOUArray Int Word8 -- ^ Array to write from -> Int -- ^ Number of 'Word8's to write -> IO () hPutArray handle (IOUArray (STUArray l u raw)) count | count == 0 = return () | count < 0 || count > rangeSize (l,u) = illegalBufferSize handle "hPutArray" count | otherwise = do wantWritableHandle "hPutArray" handle $ \ handle_@Handle__{ haFD=fd, haBuffer=ref, haIsStream=stream } -> do old_buf@Buffer{ bufBuf=old_raw, bufRPtr=r, bufWPtr=w, bufSize=size } <- readIORef ref -- enough room in handle buffer? if (size - w > count) -- There's enough room in the buffer: -- just copy the data in and update bufWPtr. then do memcpy_baoff_ba old_raw w raw (fromIntegral count) writeIORef ref old_buf{ bufWPtr = w + count } return () -- else, we have to flush else do flushed_buf <- flushWriteBuffer fd stream old_buf writeIORef ref flushed_buf let this_buf = Buffer{ bufBuf=raw, bufState=WriteBuffer, bufRPtr=0, bufWPtr=count, bufSize=count } flushWriteBuffer fd stream this_buf return ()

1 0

RE: jhc vs ghc and the surprising result involving ghc generatedassembly.
by Simon Marlow 01 Nov '05

01 Nov '05

John, this is great stuff. There's clearly a lot we can do to improve GHC's code, at least for fac :-) (I'd be really interested in any numbers you have for larger programs too, eg. the nofib suite). > and now the generated assembly. > > Main_zdwfac_info: > .text > .align 8 > .text > movq (%rbp), %rdx > cmpq $1, %rdx > jne .L2 > movq 8(%rbp), %r13 > leaq 16(%rbp), %rbp > movq (%rbp), %rax > .L4: > jmp *%rax gcc started generating this rubbish around version 3.4, if I recall correctly. I've tried disabling various optimisations, but can't seem to convince gcc not to generate the extra jump. You don't get this from the native code generator, BTW. Actually, our NCG beats gcc in most cases on x86_64, I believe. > .L2: > movq %rdx, %rax > imulq 8(%rbp), %rax > movq %rax, 8(%rbp) > leaq -1(%rdx), %rax > movq %rax, (%rbp) > movl $Main_zdwfac_info, %eax > jmp .L4 [snip] > A couple simple rules seem to help greatly. > > * turn anything of the form JMP_((W_)&self) where self is oneself into a goto > that gotos a label at the beginning of the function. Sounds like a good idea. In fact, we should do all this as a C-- -> C-- optimisation, as Simon PJ pointed out (and I mentioned on IRC yesterday). one small caveat: our register allocator can't handle loops at the moment, so any optimisations that generated actual loops would have to be disabled for the NCG for now. > * do simple pattern matthing on the basic blocks to recognize where C control > constructs can be placed. > > for instance turn > > if (x) { goto y; } > blah.. > baz.. > JMP_(foo) > > into > > if (x) { goto y; } else { > blah.. > baz.. > JMP_(foo) > } I don't actually understand why this helps, but it's easy enough to do. > * getting stack dereferences out of your loops. A bit more tricky, but could still be done as C-- to C--. Note that GHC's back end is really aimed at producing good code when there are registers available for passing arguments - this isn't true on x86 or x86_64 at the moment, though. > 1. fully convert it to use C control constructs, so gcc will do it for us. > (code motion and loop invarient being inhibited again by gotos) Ok. Jan's do-while idea seems like a cheap way to achieve this. > These should be straightforward to implement in the C code generator. it also > suggests we might want to try to use the native C calling convention on leaf > nodes that deal with unboxed values (so we get register passing and return > values for free) or taking groups of mutually recursive functions and turning > them all into one function with explicit jumps between them. Using the real C calling convention brings some problems - we'd have to use setjmp/longjmp to pass control back to the scheduler or garbage collector. Cheers, Simon

4 4

ghc-6.4.1: panic - Prelude.last: empty list
by Einar Karttunen 30 Oct '05

30 Oct '05

Hello I am having problems with GHC 6.4.1 dying with the message: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): Prelude.last: empty list The source is nontrivial and contains template haskell. The error seems to appear after byte code generation. The log of the compile with -v9 is at the address below: http://cs.helsinki.fi/u/ekarttun/haskell/log.txt Is there anything else I should do to isolate the error better? - Einar Karttunen

2 1

Error compiling using Network module
by Jorge Guerra 28 Oct '05

28 Oct '05

Hello to all, I have recently began using ghc, in particular the network module and I'm having problems with it. The following code ilustrates my problem, is very simple all I try to do is connect to a socket in my local machine send a request and print the response. -- BEGIN CODE import IO import Network host = "127.0.0.1" port = PortNumber 631 request = "GET / HTTP/1.1\nHost: 127.0.0.1:631\n\n" main = withSocketsDo $ do h <- connectTo host port hSetBuffering h LineBuffering hPutStr h request getResponse h hClose h getResponse h = do b <- hIsEOF h if b == False then do line <- hGetChar h hFlush h putChar line getResponse h else putStrLn "End of Input" -- END CODE When I try to compile it using the command: ghc -o socketTest socketTest.hs The following error appears: socketTest.o(.text+0xe2): In function `r2dL_info': : undefined reference to `NetworkziSocket_zdfNumPortNumber_closure' socketTest.o(.text+0x7c1): In function `s2f8_info': : undefined reference to `Network_connectTo_closure' socketTest.o(.text+0x8c3): In function `Main_main_info': : undefined reference to `NetworkziSocket_withSocketsDo_closure' socketTest.o(.text+0x971): In function `__stginit_Main_': : undefined reference to `__stginit_Network_' socketTest.o(.data+0x20): In function `r2dN_closure': : undefined reference to `Network_PortNumber_static_info' socketTest.o(.rodata+0x10): In function `r2dL_srt': : undefined reference to `NetworkziSocket_zdfNumPortNumber_closure' socketTest.o(.rodata+0x74): In function `s2fJ_srt': : undefined reference to `Network_connectTo_closure' socketTest.o(.rodata+0x9c): In function `Main_main_srt': : undefined reference to `NetworkziSocket_withSocketsDo_closure' collect2: ld returned 1 exit status I'm using ghc-6.4.1 in Gentoo Linux 2005.0 running kernel 2.6.13 and gcc-3.3.6 I don't know if is an error in my code or in ghc. Any sugestions? Thanks for your help -- Jorge E. Guerra D. Departamento de Computación y Tecnología de la Información Universidad Simón Bolívar

2 1

RE: Segfaulting programs with GHC 6.4.1
by Simon Marlow 28 Oct '05

28 Oct '05

On 24 October 2005 17:23, John Goerzen wrote: > 9. Now run dist/build/gopherbot. > > You should see it start to download documents, and crash after a > few minutes. I have it running on my laptop, but I'm behind a firewall right now and I guess it doesn't understand the http_proxy environment variable (is there a way to tell it to use a proxy?). At least, it seems to be complaining about timeouts on its connections. I'll try later outside the firewall. Cheers, Simon

2 1

RE: Default name of target executable
by Simon Marlow 28 Oct '05

28 Oct '05

On 24 October 2005 21:45, Tomasz Zielonka wrote: > On 10/24/05, Tomasz Zielonka <tomasz.zielonka(a)gmail.com> wrote: >> Here is the patch. > > Again, with a small bugfix in docs. Thanks; now committed. Cheers, Simon

1 0

[ ghc-Feature Requests-1340203 ] Debug.Trace.trace should work on Show
by SourceForge.net 27 Oct '05

27 Oct '05

Feature Requests item #1340203, was opened at 2005-10-28 04:38 Message generated for change (Settings changed) made by jch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Priority: 2 Submitted By: Juliusz Chroboczek (jch) Assigned to: Nobody/Anonymous (nobody) Summary: Debug.Trace.trace should work on Show Initial Comment: Debug.Trace.trace has type trace :: String -> a -> a which forces me to insert calls to show. Could it be generalised to trace :: Show a => a -> b -> b Thanks, Juliusz Chroboczek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_…

1 0

[ ghc-Feature Requests-1340203 ] Debug.Trace.trace should work on Show
by SourceForge.net 27 Oct '05

27 Oct '05

Feature Requests item #1340203, was opened at 2005-10-28 04:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Juliusz Chroboczek (jch) Assigned to: Nobody/Anonymous (nobody) Summary: Debug.Trace.trace should work on Show Initial Comment: Debug.Trace.trace has type trace :: String -> a -> a which forces me to insert calls to show. Could it be generalised to trace :: Show a => a -> b -> b Thanks, Juliusz Chroboczek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1340203&group_…

1 0

GHC-6.4.1 much slower than GHC-6.4
by Mirko Rahn 27 Oct '05

27 Oct '05

Hello, I was surprised about really big differences in running times between 6.4 and 6.4.1, whereby 6.4.1 is *much* slower: *** 6.4: cpu-time interesting (3,3): 00:01:38.08 *** 6.4.1: cpu-time interesting (3,3): 00:05:58.91 Here we have a factor of about 3.6!! Are there others that have noticed such behavior? What could be the reason for that? Sorry, my example is a small monster, but at the moment there is neither time left to search for the reason for this behavior nor to break it down to some smaller pieces of code. I just noticed it... However, you can find the source tree in http://liinwww.ira.uka.de/~rahn/src/ The file http://liinwww.ira.uka.de/~rahn/src/prog.tar.gz contains the tree as well. For the output above: Extract, cd proj/prog and run rahn@i90pc18:~/local/proj/prog$ for version in 6.4 6.4.1; do find . -name '*.hi' | rm -f ; ghc-$version --make -Wall -cpp -D__POS__='__FILE__ ++ "[" ++ show(__LINE__::Int) ++ "]: " ++ ' -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -O Prog/Interesting.hs -o Prog/Interesting.$version.bin 2>/dev/null >/dev/null; echo -n "*** $version: " ; ./Prog/Interesting.$version.bin 2>&1 | grep time ; done Regards, Mirko P.S.: I run a debian-box with i686 GNU/Linux 2.6.11.11 and a dualcore P4 3.2 GHz. -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

2 1