- Glasgow-haskell-users

RE: Dependency Generation
by Simon Marlow 07 Aug '01

07 Aug '01

> I'm getting the following error using the instructions in > 4.9.5.1 Dependency > Generation. > > [dominic@r341-02 webldap]$ make depend > ghc -M -cpp Add.hs EnvPassed.hs ParseError.hs Search.hs > ASNv1.hs Counter.hs GetO > pt.hs ParseExpr.hs StdTokenDef.hs Basev1.hs DecodeAll.hs > Hello.hs ParseLib.hs Ta > gsv1.hs CGI.hs Decode.hs HTML.hs Parser.hs TokenDef.hs > CGISystem.hs Delete.hs HT > MLWizard.hs ParseToken.hs UrlEncoded.hs Classv1.hs DoAdd.hs > ldapHTML.hs Pretty.h > s WebSite.hs CL.hs DoDelete.hs LdapTypesv2.hs QL.hs > X690Utilsv2.hs Client2.hs Do > Modify.hs Mime.hs query.hs client.hs DoSearch.hs Modify.hs > Request.hs Client.hs > Env.hs oldDecodeAll.hs Response.hs > Basev1.hs: can't find one of the following: `Word.hi' > `Word.hs' `Word.lhs' > make: *** [depend] Error 1 > [dominic@r341-02 webldap]$ Just add the same -package options when you use ghc -M as you would when compiling any of the modules. i.e. in this case adding -package lang will help GHC find the Word module (but it won't be included in the dependency output). Cheers, Simon

1 0

Dependency Generation
by Steinitz, Dominic J 07 Aug '01

07 Aug '01

I'm getting the following error using the instructions in 4.9.5.1 Dependency Generation. [dominic@r341-02 webldap]$ make depend ghc -M -cpp Add.hs EnvPassed.hs ParseError.hs Search.hs ASNv1.hs Counter.hs GetO pt.hs ParseExpr.hs StdTokenDef.hs Basev1.hs DecodeAll.hs Hello.hs ParseLib.hs Ta gsv1.hs CGI.hs Decode.hs HTML.hs Parser.hs TokenDef.hs CGISystem.hs Delete.hs HT MLWizard.hs ParseToken.hs UrlEncoded.hs Classv1.hs DoAdd.hs ldapHTML.hs Pretty.h s WebSite.hs CL.hs DoDelete.hs LdapTypesv2.hs QL.hs X690Utilsv2.hs Client2.hs Do Modify.hs Mime.hs query.hs client.hs DoSearch.hs Modify.hs Request.hs Client.hs Env.hs oldDecodeAll.hs Response.hs Basev1.hs: can't find one of the following: `Word.hi' `Word.hs' `Word.lhs' make: *** [depend] Error 1 [dominic@r341-02 webldap]$ Here's the relevant bit of the makefile. depend: ghc -M $(HC_OPTS) $(SRCS) SRCS = Add.hs EnvPassed.hs ParseError.hs Search.hs\ ASNv1.hs Counter.hs GetOpt.hs ParseExpr.hs StdTokenDef.hs\ Basev1.hs DecodeAll.hs Hello.hs ParseLib.hs Tagsv1.hs\ CGI.hs Decode.hs HTML.hs Parser.hs TokenDef.hs\ CGISystem.hs Delete.hs HTMLWizard.hs ParseToken.hs UrlEncoded.hs\ Classv1.hs DoAdd.hs ldapHTML.hs Pretty.hs WebSite.hs\ CL.hs DoDelete.hs LdapTypesv2.hs QL.hs X690Utilsv2.hs\ Client2.hs DoModify.hs Mime.hs query.hs\ client.hs DoSearch.hs Modify.hs Request.hs\ Client.hs Env.hs oldDecodeAll.hs Response.hs HC_OPTS= -cpp and here are the imports in Basev1.hs import Int import Char import Bits import Word import Tagsv1 It's not clear from the documentation what I should add to stop ghc -M trying to find Word. I tried -exclude-module=Word.hs but got the following [dominic@r341-02 webldap]$ make depend ghc -M -cpp -exclude-module=Word.hs Add.hs EnvPassed.hs ParseError.hs Search.hs ASNv1.hs Counter.hs GetOpt.hs ParseExpr.hs StdTokenDef.hs Basev1.hs DecodeAll.hs Hello.hs ParseLib.hs Tagsv1.hs CGI.hs Decode.hs HTML.hs Parser.hs TokenDef.hs C GISystem.hs Delete.hs HTMLWizard.hs ParseToken.hs UrlEncoded.hs Classv1.hs DoAdd .hs ldapHTML.hs Pretty.hs WebSite.hs CL.hs DoDelete.hs LdapTypesv2.hs QL.hs X690 Utilsv2.hs Client2.hs DoModify.hs Mime.hs query.hs client.hs DoSearch.hs Modify. hs Request.hs Client.hs Env.hs oldDecodeAll.hs Response.hs ghc-5.00.2: unrecognised flag: -exclude-module=Word.hs Usage: For basic information, try the `--help' option. make: *** [depend] Error 1 [dominic@r341-02 webldap]$ ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

GC options. Reply
by S.D.Mechveliani 07 Aug '01

07 Aug '01

Hello, here are my votes on Simon Marlow's questions. > Issue 1: should the maximum heap size be unbounded by default? > Currently the maximum heap size is bounded at 64M. > [..] > 1. remove the default limit altogether > 2. raise the default limit > 3. no change Put the default to 30M. > Issue 2: Should -M be renamed to -H, and -H renamed to something else? > The argument for this change is that GHC's -M option is closer to the > traditional meaning of -H. Yes. > Issue 3: (suggestion from Julian S.) Perhaps there should be two options > to specify "optimise for memory use" or "optimise for performance", > which have the effect of setting the defaults for various GC options to > appropriate values. > [..] All right. But let the meaning of -O remain as it was. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

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

06 Aug '01

Hmm, we're looking at this. However, I don't really know what C is or is not supposed to do here. Given 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? Also, I don't even know where to look for the specification of details of the C calling conventions. Anyone got a clue? J | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: Monday, August 06, 2001 1:34 AM | To: GHC List | Subject: GHC FFI Return Type Bug | | | Has anyone else come across this? I've only tried this with | Word8 but I | suspect this is a problem with all return types smaller than | four bytes. | | I've entered this as GHC bug #448104. | <http://sourceforge.net/tracker/index.php?func=detail&aid=4481 | 04&group_id=8 | 032&atid=108032> | | Here's the C code: | | extern "C" | { | unsigned char foo(); | } | | inline void use(const char* s) | { | } | | unsigned char foo() | { | const char* s = ""; | use(s); | return 0; | } | | ...and the Haskell looks something like this: | | foreign import foo :: IO Word8 | | do { | w8 <- foo; | putStrLn (show (w8 :: Word8)); | } | | ...and the result is this: | 1074803712 | | Kind of an unusual Word8 value! But note that the low byte of | this value | is zero. | | My setup: | | $ ghc -v | Glasgow Haskell Compiler, Version 5.00, for Haskell 98, | compiled by GHC | version 5.00 | Using package config file: /usr/lib/ghc-5.00/package.conf | Hsc static flags: -static -fignore-interface-pragmas | -fomit-interface-pragmas -fdo-lambda-eta-expansion -flet-no-escape | | $ uname -a | Linux server 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686 unknown | | | -- | Ashley Yakeley, Seattle WA | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgo| w-haskell-users |

2 1

RE: POLL: GC options
by Simon Marlow 06 Aug '01

06 Aug '01

> On Mon, 6 Aug 2001, Simon Marlow wrote: > > > Issue 1: should the maximum heap size be unbounded by default? > > Currently the maximum heap size is bounded at 64M. > Arguments for: this > > stops programs with a space leak eating all your swap > space. Arguments > > against: it's annoying to have to raise the limit when you > legitimately > > need more space. > > > > Options: > > 1. remove the default limit altogether > > 2. raise the default limit > > 3. no change > > > > (any others?) > > > I think that if there should be a default limit it would be nice to be > able to set it at compile time. This is something that I've wanted for > quite some time. If I know that the program I am compiling is > likely to > need 100M of heap space it feels silly having to give the RTS > parameter to > the program each time I run it. It would be much more > convenient to just > tell the compiler where I want the limit. You can do this using the hooks that the RTS provides, although it's a bit inconvenient at the moment because as Sigbjorn points out we don't ship the RtsFlags.h file which contains the definition of the flags structure :-( Documentation is here: http://www.haskell.org/ghc/docs/latest/set/runtime-control.html#RTS-HOOK S You'll need to get RtsFlags.h from fptools/ghc/includes in a GHC source distribution. Cheers, Simon

2 1

GHC FFI Return Type Bug
by Ashley Yakeley 06 Aug '01

06 Aug '01

Has anyone else come across this? I've only tried this with Word8 but I suspect this is a problem with all return types smaller than four bytes. I've entered this as GHC bug #448104. <http://sourceforge.net/tracker/index.php?func=detail&aid=448104&group_id=8 032&atid=108032> Here's the C code: extern "C" { unsigned char foo(); } inline void use(const char* s) { } unsigned char foo() { const char* s = ""; use(s); return 0; } ...and the Haskell looks something like this: foreign import foo :: IO Word8 do { w8 <- foo; putStrLn (show (w8 :: Word8)); } ...and the result is this: 1074803712 Kind of an unusual Word8 value! But note that the low byte of this value is zero. My setup: $ ghc -v Glasgow Haskell Compiler, Version 5.00, for Haskell 98, compiled by GHC version 5.00 Using package config file: /usr/lib/ghc-5.00/package.conf Hsc static flags: -static -fignore-interface-pragmas -fomit-interface-pragmas -fdo-lambda-eta-expansion -flet-no-escape $ uname -a Linux server 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686 unknown -- Ashley Yakeley, Seattle WA

1 0

Missing functions in GHC's RTS?
by Ashley Yakeley 03 Aug '01

03 Aug '01

At 2001-08-03 00:41, I wrote (on the Haskell Cafe list): >When I make a function generator with "foreign export dynamic", GHC spits >out stub files which it apparently then needs for the link. What are >these for? OK, so I don't know what they are, but the link needs the _stub.o file. Unfortunately, the stub file includes these symbols: rts_getWord8 rts_getWord16 rts_getInt16 rts_getInt64 ...which do not appear to be in any library and indeed are not declared in RtsAPI.h, although corresponding rts_mk* functions are. This looks like a bug in GHC. $ ghc -v Glasgow Haskell Compiler, Version 5.00, for Haskell 98, compiled by GHC version 5.00 Using package config file: /usr/lib/ghc-5.00/package.conf Hsc static flags: -static -fignore-interface-pragmas -fomit-interface-pragmas -fdo-lambda-eta-expansion -flet-no-escape $ uname -a Linux server 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686 unknown -- Ashley Yakeley, Seattle WA

2 1

RE: adding isWHNF primop to 5.00.2 native code generator
by Bernard James POPE 03 Aug '01

03 Aug '01

Hi all, Hack alert! I took Julian's advice and looked over the assembly output from ghc. In all the cases I tried, the info pointer in the closure header pointed to the end of the info table. Although a comment in ghc/includes/ClosureMacros.h worries me: "info pointer" The first word of the closure. Might point to either the end or the beginning of the info table, depending on whether we're using the mini interpretter or not. GET_INFO(c) retrieves the info pointer of a closure. Can someone please clarify when the info pointer will point to the beginning or end of the table? Basically I have assumed for the moment that it points to the end of the table, as that is what some other code in ghc seems to assume. This makes it easy (hack?) to find the "type" field of the info table, its just the bottom (or top, depending on which way you look at it) 16 bits prior to the address that the info pointer contains. Essentially dataToTag# gives you these bits. I don't think "dataToTag#" is a great name for this primop, something like: closureType#, or classifyClosure# might be better. My current strategy is to simply compare the type field with the constants from ClosureTypes.h, using the Haskellised names re-exported from SMRep.lhs as suggested by Simon Marlow. My problem is that this is a dodgy assumption since the design of the info table may change in the future, and you get a nasty unchecked dependency between the primops in the NCG and the design of the rts. It seems hard to get the kind of automatic offset calculation in the NCG as you get with the C version of primops. My current idea is to make some C primops that do the structure and array indexing for me, and then use them in the NCG. i.e. primops that essentially export 'closure_flags[type]' and 'get_itbl(c)->type' to the NCG. Does anyone know of a better solution? In any case I am happy for the moment with my hacky solution, since it gives the right results and it is what I need to write up my paper. Cheers, Bernie.

1 0

RE: adding isWHNF primop to 5.00.2 native code generator
by Simon Marlow 01 Aug '01

01 Aug '01

> \begin{code} > primCode [res] IsHNF [arg] > = let res' = amodeToStix res > arg' = amodeToStix arg > arg_info = StInd PtrRep arg' > word_32 = StInd WordRep (StIndex PtrRep > arg_info (StInt (-1))) > masked_le32 = StPrim SrlOp [word_32, StInt 16] > masked_be32 = StPrim AndOp [word_32, StInt 65535] > #ifdef WORDS_BIGENDIAN > ty_info = masked_le32 > #else > ty_info = masked_be32 > #endif > not_a_thunk = StPrim IntEqOp [ StPrim AndOp > [ty_info, StInt 0x10] > , StInt 0x0 > ] > -- ToDo: don't hardwire the value of > _THUNK from InfoTables.h > assign = StAssign IntRep res' not_a_thunk > in > returnUs (\ xs -> assign : xs) > \end{code} This code looks bogus - it is checking a bit in the info table, which would have been correct when we used to store flags in the info table, but that changed a while back. closure_THUNK() works by getting the type field (i.e. get_itbl(c)->type), and using that to index into the table of closure flags (see ghc/rts/ClosureFlags.c), and checking the "THU" flag. This is the portable way to do it. The hacky way to do it would be to compare against the closure types directly - fortunately you can use the names rather than the constants, see ghc/compiler/codeGen/SMRep.lhs. Cheers, Simon

1 0

RE: adding isWHNF primop to 5.00.2 native code generator
by Julian Seward (Intl Vendor) 01 Aug '01

01 Aug '01

| Sigbjorn gave me this suggestion, which is based on DataToTagOp. | | \begin{code} | primCode [res] IsHNF [arg] | = let res' = amodeToStix res | arg' = amodeToStix arg | arg_info = StInd PtrRep arg' | word_32 = StInd WordRep (StIndex PtrRep | arg_info (StInt (-1))) | masked_le32 = StPrim SrlOp [word_32, StInt 16] | masked_be32 = StPrim AndOp [word_32, StInt 65535] | #ifdef WORDS_BIGENDIAN | ty_info = masked_le32 | #else | ty_info = masked_be32 | #endif | not_a_thunk = StPrim IntEqOp [ StPrim AndOp [ty_info, StInt 0x10] | , StInt 0x0 | ] | -- ToDo: don't hardwire the value of | _THUNK from InfoTables.h | assign = StAssign IntRep res' not_a_thunk | in | returnUs (\ xs -> assign : xs) | \end{code} | | | I get different results with the version using the C macro | and the native code version. In particular I get the wrong | (unexpected result from the native code version). | | The C macro version works like this (uses these macros): | | #define closureFlags(c) (closure_flags[get_itbl(c)->type]) | -- in ghc/includes/InfoTables.h | | #define closure_THUNK(c) ( closureFlags(c) & _THU) | -- in ghc/includes/InfoTables.h | | #define get_itbl(c) (INFO_PTR_TO_STRUCT((c)->header.info)) | -- in ghc/includes/ClosureMacros.h | | #define INFO_PTR_TO_STRUCT(info) ((StgInfoTable *)(info) - 1) | -- in ghc/includes/ClosureMacros. | | The (-1) scares me a little bit, in INFO_PTR_TO_STRUCT. | | The array closure_flags[] is just a look up table, indexed by | the closure type. So the key part of the code above is: | | get_itbl(c)->type | | In the native code version above, the lines below act like | get_itbl(c): | | arg_info = StInd PtrRep arg' | word_32 = StInd WordRep (StIndex PtrRep arg_info (StInt (-1))) | | After this I am lost. It seems to be grabbing the top or | bottom 16 bits of word_32 (depending on endianness) and then | ANDing those bits with 0x10 (which is the bit mask for _THU), | and checking for 0. | | My feeling is that I should be finding out the "type" field | from the closure and then switching on its value. What you have started with looks plausible. If you can extract enough info from the NCG, you can usually find the problem without too much difficulty. I suggest you make friends with -ddump-stix, so that you can see directly the result of your extension to the primCode fn above. Then (if you are mad enough) the usual way to go about this is: 1. Write a plausible primCode case -- as you've already done. 2. Compile with -ddump-stix and see if it looks plausible in context. 3. Read the assembly code (-ddump-asm) and relate it to the Stix. 4. Try and relate (3) to the assembly code for the same when compiled with -fvia-C. This usually helps. (3) and (4) are a lot easier if you do it on x86 than sparc because x86 code is a lot less verbose. You do need to be clear about x86 addressing modes, tho. | I don't understand the native code generator well enough. I | am assuming that closures are laid out the same way as via-C, Yes. Code from the NCG and -fvia-C is 100% interoperable. | in particular that there is going to be some stuff in the | info table before the "type" field (this looks variable | depending on how things are built). Basically I'm looking for | a way to do the equivalent of "->type". Maybe there is a | better way to do it. Suggestion: find some other primop which uses the ->type field and which is implemented in the NCG (not all are). That might help. Finally let me point you at ghc/utils/debugNCG, a small but very useful program for debugging the NCG. I would never have got it working as well as it does without it. This should work -- but it might have slight bitrot -- it's very fragile and makes lots of assumptions about gcc's output. I haven't used it for a good few months. J

1 0