March 2006 - Glasgow-haskell-users

factorial: let's get ahead of jhc! :)
by Bulat Ziganshin 02 Mar '06

02 Mar '06

Hello glasgow-haskell-users, i propose to do for start rather small change that will allow to make things go several times faster and in particular outperform jhc for the small "leaf" loops (i.e. loops that use only GHC primitives and don't call other functions). that include factorial, "a[]+=b[i]" loop that was discussed here several weeks ago, some shootout examples, my own arrays serialization code and so on, so on the idea is that the following STG code f :: Int# -> Double# -> ... -> Int# (i.e. function use only unboxed values/results) f x y z = code1 in case expr1 of A -> codeA B -> codeB C -> codeC in f x_c y_c z_c D -> codeD in f x_d y_d z_d _ -> code0 in f x0 y0 z0 can be compiled to the following C/C-- code: f() { x = sp[0]; y = sp[4]; z = sp[8]; sp+=12; code1; while (expr1!=A) { if (expr1==B) then return codeB; else if (expr1==C) then {x=x_c; y=y_c; z=z_c;} else if (expr1==D) then {x=x_d; y=y_d; z=z_d;} else {x=x0; y=y0; z=z0;} code1; } return codeA; } this compilation don't require any changes in GHC memory model. all we need: 1) add for/if/while to the C-- statement types list (data CmmStmt) 2) implement recognizer for such simple STG functions (leaf unboxed procedures recognizer) 3) implement the translation itself as i said, it's should be no more than one day of work. i even think that it's one day for me and one hour for Simon Marlow :) Simon, how about this? i can even make the patches over current 6.6 sources and you will apply them at morning and we will see whether it work :) i yet never tried to rebuild the whole ghc :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

RE: GHC 6.4.1 crash on Windows XP
by Cyril Schmidt 01 Mar '06

01 Mar '06

> Can you tell which process is crashing? Is it the GHC process that is > interpreting Setup.hs, or the process invoked by Setup.hs to build the > package? I suspect it is the GHC process that is invoked by Setup.hs, but I do not have any hard evidence to support this. > One thing you could try is compiling Setup.hs to a binary, and running > that instead. That worked! I think this counts as evidence for the above. > > Also, if you could run Setup like this and send us the output: > > $ ./setup build -v > > (or the runhaskell version, if that's the only one that crashes) I did it via runhaskell: runhaskell Setup.hs build -v Preprocessing library Vasicek-0.3... Building Vasicek-0.3... This is all what it said before the crash... Just about 15 minutes ago I fixed the problem (at least I hope I did) by installing the snapshot of GHC 6.4.2 of February 27 (BTW, the cc1.exe is missing from the tar file). I also found at least one difference between the PC where the problem showed up and the one where it did not. Both PCs had Cygwin installed. On the PC where the problem did not show up, the Cygwin executables shadowed the Windows programs with the same name: e.g. if I type 'find' in Windows command prompt, I get the UNIX find. On the PC where the problem did show up, it was the other way: I get the Windows find (of course, from the bash shell I always get the UNIX find). I do not know, though, if this is linked in any way to the GHC problem. I spent some time playing with PATH to try to make the two PCs behave the same, but I could not (I do not have Admin priviledges). The GHC was always started from the Windows prompt, never from bash. Anyway, as the problem is solved by moving from 6.4.1 to 6.4.2, we can conclude that it was caused by one of the bugs fixed after 6.4.1, and close the issue for now. If you, however, would like to continue investigation, please let me know -- I can easily reproduce the problem, and I'll be happy to get any extra information for you (once I know how to get it). I will keep version 6.4.1 for the time being. Thank you very much for the help. Cheers, Cyril

1 0

Problem building on sparc/Linux
by Ian Lynagh 01 Mar '06

01 Mar '06

Hi all, I'm having problems building ghc 6.4.1 with ghc 6.4.1 (should be unregisterised in both cases) on Sparc/Linux: mkdir stage1/cprAnalysis mkdir stage1/compMan mkdir stage1/ndpFlatten mkdir stage1/iface mkdir stage1/cmm mkdir stage1/ghci Creating main/Config.hs ... done. Creating stage1/ghc_boot_platform.h... Done. gcc -E -undef -traditional -P -I../includes -x c prelude/primops.txt.pp | \ grep -v '^#pragma GCC' > prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl < prelude/primops.txt > primop-data-decl.hs-incl genprimopcode: parse error at (line 579, column 1): unexpected "\t" expecting "primop", "section" or "thats_all_folks" make[3]: *** [primop-data-decl.hs-incl] Error 1 make[3]: *** Deleting file `primop-data-decl.hs-incl' make[2]: *** [boot] Error 1 make[2]: Leaving directory `/scratch/igloo/test_rebuild/ghc6-6.4.1/ghc' make[1]: *** [build] Error 1 make[1]: Leaving directory `/scratch/igloo/test_rebuild/ghc6-6.4.1' make: *** [build-stamp] Error 2 igloo@vore:/scratch/igloo/test_rebuild/ghc6-6.4.1$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 igloo@vore:/scratch/igloo/test_rebuild/ghc6-6.4.1$ gcc --version gcc (GCC) 3.3.6 (Debian 1:3.3.6-12) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I have attached vore:/scratch/igloo/test_rebuild/ghc6-6.4.1/ghc/compiler/prelude/primops.txt Anyone got any idea what's going on? Thanks Ian

4 5

Building Win32 DLLs: Manual is not up-to-date
by Michael Marte 01 Mar '06

01 Mar '06

Hello *, I am trying to turn a prototype written in Haskell into something I can call from a Visual Studio C++ 6.0 program. (The prototype is so clean and fast that there is no point in recoding everything.) So I followed the instructions in section 11.5 of the ghc manual ("Building and using Win32 DLLs") and ended up as follows: $ ghc -c dllMain.c dllMain.c:4: warning: type defaults to `int' in declaration of `EXTFUN' dllMain.c:4: warning: parameter names (without types) in function declaration dllMain.c:4: warning: data definition has no type or storage class dllMain.c: In function `DllMain': dllMain.c:18: error: `__stginit_Adder' undeclared (first use in this function) dllMain.c:18: error: (Each undeclared identifier is reported only once dllMain.c:18: error: for each function it appears in.) Section 8.2 proposes to add extern void __stginit_Adder(void) which actually works. So it seems that section 11.2 is not up-to-date!

2 1

Re[3]: factorial: let's get ahead of jhc! :)
by Bulat Ziganshin 01 Mar '06

01 Mar '06

Hello Bulat, Friday, February 24, 2006, 6:37:42 PM, you wrote: SPJ>> Perhaps you may consider doing this transformation on the C-- data type SPJ>> only, without involving the (already very complicated) STG -> C-- code SPJ>> generator? i have found my investiations in this area. that is the C-- code generated for fac worker: Fac_zdwfac_entry() { c1C0: _s1BD = I32[Sp + 0]; if (_s1BD != 1) goto c1C4; R1 = I32[Sp + 4]; Sp = Sp + 8; jump (I32[Sp + 0]); c1C4: _s1BI = _s1BD * I32[Sp + 4]; _s1BF = _s1BD - 1; I32[Sp + 4] = _s1BI; I32[Sp + 0] = _s1BF; jump c1C0; } first, we convert jump to the explicit loop: _s1BD = I32[Sp + 0]; while (_s1BD != 1) { _s1BI = _s1BD * I32[Sp + 4]; _s1BF = _s1BD - 1; I32[Sp + 4] = _s1BI; I32[Sp + 0] = _s1BF; _s1BD = I32[Sp + 0]; } R1 = I32[Sp + 4]; Sp = Sp + 8; jump (I32[Sp + 0]); then, we cache contents of sp[*] variables in the local ones: sp4 = I32[Sp + 4]; sp0 = I32[Sp + 0]; _s1BD = sp0; while (_s1BD != 1) { _s1BI = _s1BD * sp4; _s1BF = _s1BD - 1; sp4 = _s1BI; sp0 = _s1BF; _s1BD = sp0; } I32[Sp + 4] = sp4; I32[Sp + 0] = sp0; R1 = I32[Sp + 4]; Sp = Sp + 8; jump (I32[Sp + 0]); and then we wipe out all the superfluous variables: sp4 = I32[Sp + 4]; sp0 = I32[Sp + 0]; while (sp0 != 1) { sp4 = sp0 * sp4; sp0 = sp0 - 1; } R1 = sp4; Sp = Sp + 8; jump (I32[Sp + 0]); and it is even for simple fac() function!!! instead of straightforward generation of code that we need we should make all these nontrivial studying and hard transformations on already generated code. on the other side, we can just generate the following code right from the STG: int fac () { sp4 = I32[Sp + 4]; sp0 = I32[Sp + 0]; while (sp0 != 1) { sp4 = sp0 * sp4; sp0 = sp0 - 1; } R1 = sp4; Sp = Sp + 8; jump (I32[Sp + 0]); } i think that my way is 100x simpler -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

RE: GHC 6.4.1 crash on Windows XP
by Simon Marlow 01 Mar '06

01 Mar '06

Can you tell which process is crashing? Is it the GHC process that is interpreting Setup.hs, or the process invoked by Setup.hs to build the package? One thing you could try is compiling Setup.hs to a binary, and running that instead. Also, if you could run Setup like this and send us the output: $ ./setup build -v (or the runhaskell version, if that's the only one that crashes) Cheers, Simon On 28 February 2006 10:57, Cyril Schmidt wrote: > Simon Marlow wrote: > >> Does it always crash in the same way? > > Yes, as far as I can see. Unfortunately, most of the context is > already lost when the error message pops up. The error code is > always the same. > >> Can you fire up GHCi and perform a small evaluation or two? > > Yes, this works just fine. > >> Can you compile small programs, do they run? > > Also works fine. > >> >> Please send us the complete output from commands that crash: eg. add >> -v to the build command above. >> > > I attach the stderr and stdout from > runhaskell -v5 Setup.hs build > > I could also send the sources of the package being compiled, but I do > not think they are relevant here: it crashes on *any* package. > > BTW, I had installed Cabal-1-1.3, but it did not help, so I reverted > to the version of Cabal that came with the compiler. > > It is strange that the same version of GHC works fine on my PC and > breaks on that of my colleague. To the best of my knowledge, these > two PCs are not different from each other in any special way. I did > have some strange crashes on my PC as well, but these were cured by > upgrading from 6.4 to > 6.4.1. > > Cheers, > > Cyril > > >> Cyril Schmidt wrote: >>> A freshly installed GHC 6.4.1 on my colleague's PC crashes when I >>> try to build a package: >>> >>> runhaskell Setup.hs build >>> >>> The effect is easily reproduceable (it shows up on *any* package >>> that I try to build). >>> >>> Does anyone have any idea of what might be wrong here?

1 0