- Glasgow-haskell-users

Confused by profiling
by Ian Lynagh 14 Sep '01

14 Sep '01

Hi all I am confused by the GHC profiling output. I have put some abstracts below to illustrate my confusion. I compiled my code with: HFLAGS="-Wall -package lang -prof -auto-all" hmake -ghc main and then ran it with: ./main -t +RTS -p < test5.hs Here is some of main.prof: individual inherited COST CENTRE MODULE entries %time %alloc %time %alloc [...] parse Parser 1 0.0 0.0 81.4 62.3 p_module Parser 0 0.0 0.0 81.4 62.3 <|> PC_base 69517 20.3 5.7 81.4 62.3 [...] p_aexp_list Parser 0 0.0 0.0 0.0 0.3 con2tag_Token# Tokens 880 0.0 0.0 0.0 0.0 pIfThing PC_base 896 0.0 0.0 0.0 0.0 <$ PC 0 0.0 0.0 0.0 0.3 <$> PC 0 0.0 0.0 0.0 0.3 pSucceed PC_base 896 0.0 0.3 0.0 0.3 <*> PC_base 896 0.0 0.0 0.0 0.0 <*> PC_base 896 0.0 0.0 0.0 0.0 p_aexp_tuple Parser 0 0.0 0.0 0.0 0.3 [...] and here is the code for p_aexp_list: p_aexp_list :: Parser Token Aexp p_aexp_list = (Aexp_list . get_rights) <$ pIfThing ((==) (Special '[')) <*> pSList False p_comma p_exp <* pIfThing ((==) (Special ']')) Now basically my problem is how things under p_aexp_list can be entered 896 times if p_aexp_list is entered 0 times - am I reading it wrong? And the only place p_aexp_list is called from is p_aexp_init = p_aexp_qvar <|> p_aexp_gcon <|> p_aexp_literal <|> p_aexp_paren <|> p_aexp_tuple <|> p_aexp_list <|> p_aexp_arith <|> p_aexp_listcomp <|> p_aexp_left <|> p_aexp_right but my reading of the profile output shows it as being called from <|> which is in turn called from p_module (all lines in the second [...] are indented with at least " "). Am I missing something obvious? Thanks Ian

1 1

RE: ghc/HopenGL/cygwin/W2K
by Simon Peyton-Jones 14 Sep '01

14 Sep '01

Clifford In the next few days we'll release GHC 5.02. The Windows version of that will not require any version of cygwin; it comes complete, and you don't need to install anything else to make it work. (Nor does it mind if you have some version of cygwin installed, a surprisingly difficult criterion to satisfy, given Window's DLL story.) So I suggest you wait a few days. I do mean days and not weeks! (There is a slightly experimental Windows binary download you can try meanwhile; I enclose the message announcing it.) I'm not certain whether HOpen/GL has 'caught up' to GHC 5.02, but I'm sure it will shortly, and any differences will be of the trivial kind. Simon | -----Original Message----- | From: Clifford Beshers [mailto:beshers@cs.columbia.edu] | Sent: 14 September 2001 04:14 | To: glasgow-haskell-users(a)haskell.org | Subject: ghc/HopenGL/cygwin/W2K | | | | | I'm trying to get to the point where I can use ghc and OpenGL | under Windows 2000. Unfortunately, I'm lost in a maze of | version numbers. | | I had cygwin-1.3.2 installed, I think, which did not match | the 1.3.1 used in the ghc-4.08 package. I tried to install | cygwin 1.3.1, but got 1.3.3 instead. Nowhere can I find a | course for 1.3.1. Nor can I find 5.00.2 compiled for | Windows, though there is some mention of W2K support in the | documentation. | | Can anyone provide me with a recent road map? I don't mind | compiling everything, if that's what it takes, I just feel | I'm wandering in the wilderness. | | Thanks, | | Clifford Beshers | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

ghc/HopenGL/cygwin/W2K
by Clifford Beshers 14 Sep '01

14 Sep '01

I'm trying to get to the point where I can use ghc and OpenGL under Windows 2000. Unfortunately, I'm lost in a maze of version numbers. I had cygwin-1.3.2 installed, I think, which did not match the 1.3.1 used in the ghc-4.08 package. I tried to install cygwin 1.3.1, but got 1.3.3 instead. Nowhere can I find a course for 1.3.1. Nor can I find 5.00.2 compiled for Windows, though there is some mention of W2K support in the documentation. Can anyone provide me with a recent road map? I don't mind compiling everything, if that's what it takes, I just feel I'm wandering in the wilderness. Thanks, Clifford Beshers

1 0

shell to run functions
by Johansson Mikael 12 Sep '01

12 Sep '01

Hello! I have problems running functions in a haskell program being able to give input and get output via the keyboard. I have a glasgow compiler and have successfully made a compiled and runned a program wich read a char and writes it back to screen. main :: IO () main = do c <- getChar putChar c But when I try to write a program with this function: f x = x mod 7 == 0 || x mod 10 == 7 || x div 10 mod 10 == 7 The IO doesn't seem to work How do I put programs like this in a IO shell. Thanks in advance. Mikael Johansson Volvo Aero Corporation Military Engines Trollhättan Dept. 7164MJ SE-461 81 Trollhättan, Sweden phone +46 520 940 61 e-mail: mikael.mj.johansson(a)volvo.com

2 1

Re: A question about Unicode support
by Marcin 'Qrczak' Kowalczyk 11 Sep '01

11 Sep '01

Tue, 11 Sep 2001 13:19:54 -0300 (GMT), Pablo Pedemonte <ppedemon(a)sol.info.unlp.edu.ar> pisze: > Ghc 5.00.2 provides (initial) Unicode support, so I thought the > chr function would do. But it seems it still rejects Int values > greater than 0xFF. It doesn't. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

A question about Unicode support
by Pablo Pedemonte 11 Sep '01

11 Sep '01

Hi all! The question is really simple: how can I convert an Int into a Char? Ghc 5.00.2 provides (initial) Unicode support, so I thought the chr function would do. But it seems it still rejects Int values greater than 0xFF. So, what function shoud I use? Thanks in advance. Regards, Pablo

1 0

Re: GHC FFI Return Type Bug
by Marcin 'Qrczak' Kowalczyk 10 Sep '01

10 Sep '01

10 Sep 2001 13:20:33 -0600, Alastair David Reid <reid(a)cs.utah.edu> pisze: > So GHC's Int/Word implementation is different from Hugs'? Hugs > represents Word8 (say) by a 32 bit int but doesn't guarantee that the > top 24 bits are all zero. GHC does similarly, except that it does guarantee that unused bits are zero. Or one - in negative numbers. In other words it represents value x of type Int8 as if converted to Int. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: GHC FFI Return Type Bug
by Julian Seward (Intl Vendor) 10 Sep '01

10 Sep '01

Thanks. I think the decision here is to do the safe thing and mask the return results ourselves, since it's only one extra insn. This won't make it into 5.02, tho. J | -----Original Message----- | From: Sigbjorn Finne [mailto:sof@galconn.com] | Sent: Saturday, September 08, 2001 4:27 PM | To: Julian Seward (Intl Vendor) | Cc: partain(a)dcs.gla.ac.uk; Ashley Yakeley; GHC List | Subject: Re: GHC FFI Return Type Bug | | | Here's another data point on this topic - I asked around | inside of MS, and the consensus is that the contents of the | unused portions of EAX is undefined upon return (upper 3 | bytes for byte-sized return values, upper 2 for 16-bit | values). This is invariant of x86 calling convention on Win32 | (cdecl,stdcall,fastcall). Still no known doc/spec which | spells this out. | | ==> GHC's NCG and C backends need to know the sizes of the | unboxed Ints and Words involved in CCalls to generate correct code. | | --sigbjorn | | ----- Original Message ----- | From: "Sigbjorn Finne" <sof(a)galconn.com> | To: "Julian Seward (Intl Vendor)" <v-julsew(a)microsoft.com> | Cc: <partain(a)dcs.gla.ac.uk>; "Ashley Yakeley" | <ashley(a)semantic.org>; "GHC List" <glasgow-haskell-users(a)haskell.org> | Sent: Tuesday, August 07, 2001 16:00 | Subject: Re: GHC FFI Return Type Bug | | | > | > "Julian Seward (Intl Vendor)" <v-julsew(a)microsoft.com> writes: | > > | > > | > char fooble ( ... ) | > > | > { | > > | > return 'z'; | > > | > } | > > | > | > > | > on an x86, 'z' will be returned at the lowest 8 bits in %eax. | > > | > What I | > > | > > | > don't know is, is the C compiler obliged to clear the | upper 24 | > > | > bits | > > of | > > | > %eax, or does that onus fall on the callee? | > > | | > > | Yes, the callee is required to narrow <expr> in 'return | <expr>;' | > > | to fit that of the specified return type -- see 9.8 of Harbison | > > | and Steele. | > > | | > ... | > > So we don't need to worry about doing the masking on the Haskell | > > side, right? | > > | > | > Yes, that's been my understanding. But, as Carl Witty | rightly points | > out, a distinction can be made between narrowing down the | result value | > and the transmission of the narrowed result back to the caller. | > | > Carl's example doesn't fully convince me though, since the masking | > done in the code for "g" is patently redundant ("f" does | mask out the | > upper 3 bytes of %eax upon return). However, the example | given in the | > original bug report can be made to emit code that doesn't | mask %eax | > (via "gcc-2.96 -O" on an i686-pc-linux). Another data point is that | > MSVC also emits code that masks. | > | > So, indications are that you actually do need to mask on an | x86, but | > I've got no supporting documentation. If anyone is able to | dig up more | > info and/or know someone that could answer this one decisively, I'd | > interested to hear of their findings. | > | > --sigbjorn | > | > btw, the document specifying the x86 ABI, located via | > | > http://uwsg.iu.edu/hypermail/linux/kernel/0011.1/0596.html | > | > , doesn't cover this as far as I've been able to tell. | > | > | > | > _______________________________________________ | > Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | |

3 2

RE: GHC FFI Return Type Bug
by Julian Seward (Intl Vendor) 10 Sep '01

10 Sep '01

| Speaking of 5.02 . Could someone enlighten us that are not on | the CVS mailing list about the state of things? When can we | expect the release? If I'm feeling optimistic, late this week; otherwise, sometime next week. We've had some stability problems, but I hope these are now solved. Another part of the delay stems from the fact that we're trying to get our new glorious automated test system to run with zero failures on all supported platforms. The upside of all this is that 5.02, when it eventually appears, should be pretty darn stable. (Famous last words ...) J

1 0

RE: GHC FFI Return Type Bug
by Julian Seward (Intl Vendor) 08 Sep '01

08 Sep '01

Sigbjorn Am confused by your answer. | > char fooble ( ... ) | > { | > return 'z'; | > } | > | > on an x86, 'z' will be returned at the lowest 8 bits in %eax. What I | > don't know is, is the C compiler obliged to clear the upper 24 bits of | > %eax, or does that onus fall on the callee? | | Yes, the callee is required to narrow <expr> in 'return | <expr>;' to fit that of the specified return type -- see 9.8 | of Harbison and Steele. So, a C compiler that cause f() to | return 0x7fffffff for the following, | | unsigned char g() | { | return 0x7fffffff; | } | | unsigned int f() | { | return g(); | } | | is in the wrong. [Notice that narrowing for signed integral | types is undefined in ISO C, but most current-day compilers | implement such narrowing ops the same way, i.e., by masking | off excess bits.] So we don't need to worry about doing the masking on the Haskell side, right? | > Also, I don't even know where to look for the specification | of details | > of the C calling conventions. Anyone got a clue? | > | | Harbison & Steele Chapters 6 and 9 cover the conversion rules | that apply to functions (and other expressions). As you no | doubt already know, lower-level details are the domain of a | platform's ABI. | | Sounds to me like unboxed sized Words and Ints is the | (unavoidable) way to go. Why would we need these unless we *did* need to worry about masking on the Haskell side? Pls clarify. J

2 2