- Glasgow-haskell-users

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

01 Aug '01

Hi all, More mind boggling questions on prim ops :) I am happy with isWHNF that is implemented with: #define isHNFzh(r,a) r=(! closure_THUNK((StgClosure *)a)) I will re-write for the IO Monad later. I want to mimic this behaviour in the native code generator. 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. I don't understand the native code generator well enough. I am assuming that closures are laid out the same way as via-C, 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. Thanks once again, and apologies if I missed something obvious. Cheers, Bernie.

1 0

RE: help needed for adding isWHNF primop to 5.00.2
by Bernard James POPE 01 Aug '01

01 Aug '01

Hi all, Apologies for my large number of postings to this list of late. > the normal definition of WHNF applies only > to types containing _|_, i.e. pointed types. Unpointed types are never > represented by thunks, so I would be inclined to include them in WHNF. Yes, I agree here. It is useful for me since I am using WHNF to determine whether expressions are evaluated. Perhaps it is a slight abuse of the terminology, but it gives me what I want :) > You also have to deal with indirections, although you can assume (at the > moment) that an indirection will eventually lead to an object in WHNF. Good point. I did make this assumption. Well to be precise I made the assumption that the thunk and indirection closure flags were mututally exclusive. If things change I guess I will have to follow the indirections. currently my definition is: #define isHNFzh(r,a) r=(! closure_THUNK((StgClosure *)a)) I believe under this definition that unpointed types and indirections are considered to be in WHNF. My initial tests seem to indicate that this is working well. > You have to declare the primitive like this, > BTW: > > isWHNF# :: a -> (# State# RealWorld, Int# #) > > because the compiler doesn't know about the IO type and you can't return > a Bool directly. I'm not too fussed about the unboxed Int, although as Marcin points out it does look like some of the comparision primops can return a Bool. I couldn't figure out how they did it so I left it with the Int#. > There's no problem with the simplifier as long as you declare the > primitive to have the correct properties, i.e. that the polymorphic > argument is lazy. Great. > It sounds like you also need a way to take apart arbitrary objects and > look at their components. Yes indeed. I use type classes for this with deriving rules for user defined types. I'm in the midst of writing this up for IFL, in Stockholm, mid September. In particular, I am looking for "portable" ways of taking objects apart, that's why type classes are attractive. Of course, isWHNF cannot be written in Haskell, but if I can get it to work for Hugs, GHC and NHC, then that is good enough for me :) What I hope is that some of this can appear as a Meta-programming library for Haskell, which is more powerful than Read and Show. Something a bit similar to the semantic domain of Meta-ML. > I know that Andy Gill was also interested in > having similar facilities, perhaps he can help out. I wonder if Andy is reading this? Possibly there are other people around who are also interested in this. I think the HAT people at NHC headquarters are also interested in these things. There once was talk of starting a debugging group for Haskell, but I don't know what happened. Thanks heaps for your help. Bernie.

3 3

RE: FFI and Control-C
by Simon Marlow 01 Aug '01

01 Aug '01

> So, my questions are: > > 1) Does anyone know what exactly happens when control-C is > pressed during foreign function evaluation? Yes. Two cases: if the program hasn't requested that Ctrl-C be trapped (using the Posix library's installHandler), then the SIGINT handler just sets a flag which causes the scheduler to kill all the running threads and exit. If the program is in a foreign call, then the scheduler won't get to run until the foreign call returns. If the program has installed a handler for SIGINT (which GHCi does), then the SIGINT handler in the RTS sets a different flag. The next time the scheduler runs, it creates a new thread for the handler and puts it on the run queue. In the case of GHCi, the handler thread raises an exception in the main thread, which is caught by the GHCi loop. Again, if the main thread is in a foreign call, none of this will happen until the call returns. > 2) Does anyone know how this can be controlled in a more > finegrained way? We don't have a good solution for this at the moment. Where possible, don't do blocking foreign calls. The threadWaitRead/threadWaitWrite primitives can be used to avoid blocking if you know the file descriptor that the foreign call is going to block on. Cheers, Simon

1 0

FFI and Control-C
by Koen Claessen 31 Jul '01

31 Jul '01

Hi, I recently started experimenting using the FFI in GHC and GHCi. In GHCi, one would like to press control-C in the middle of a computation, and get back to the prompt. It is however hard to understand how control-C and the foreign function calls interact. I noticed that GHCi does not react to control-C when the program in inside a foreign function. Instead, it then breaks when the foreign function comes back. This behavior would be fine in many applications if it were consistent. However, often after I have pressed control-C, the internal state of the foreign library is usually completely messed up. Even beyond what one can think is possible when allowing to abruptly break computations. So, my questions are: 1) Does anyone know what exactly happens when control-C is pressed during foreign function evaluation? 2) Does anyone know how this can be controlled in a more finegrained way? For example, in old Hugses, it was possible to use the function "breakOn", which allowed/disallowed control-C breaking. /Koen.

1 0

RE: help needed for adding isWHNF primop to 5.00.2
by Simon Marlow 31 Jul '01

31 Jul '01

> I wonder if Andy is reading this? Possibly there are other people > around who are also interested in this. I think the HAT people > at NHC headquarters are also interested in these things. There > once was talk of starting a debugging group for Haskell, but I > don't know what happened. There's a mailing list for debugger-related discussion at debuggers(a)haskell.org (subscribe in the usual way). To date it has received a single message, namely the nhc 1.06 announcement :-) Cheers, Simon

1 0

RE: help needed for adding isWHNF primop to 5.00.2
by Simon Marlow 31 Jul '01

31 Jul '01

> Tue, 31 Jul 2001 12:38:03 +0100, Simon Marlow > <simonmar(a)microsoft.com> pisze: > > > That's the way I'd go. You have to declare the primitive like this, > > BTW: > > > > isWHNF# :: a -> (# State# RealWorld, Int# #) > > > > because the compiler doesn't know about the IO type and you > can't return > > a Bool directly. > > It can return a Bool, e.g. ==# returns a Bool. But ==# doesn't also return an unboxed tuple, and the code generator has special hacks to deal with primops that return enumerated types. The ==# primop actually returns an Int# which the code generator arranges to convert into a real Bool using the closure table. I guess you could return a Bool by actually indexing into the closure table, or by just returning {False,True}_static_closure. Cheers, Simon

1 0

Re: help needed for adding isWHNF primop to 5.00.2
by Marcin 'Qrczak' Kowalczyk 31 Jul '01

31 Jul '01

Tue, 31 Jul 2001 12:38:03 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > That's the way I'd go. You have to declare the primitive like this, > BTW: > > isWHNF# :: a -> (# State# RealWorld, Int# #) > > because the compiler doesn't know about the IO type and you can't return > a Bool directly. It can return a Bool, e.g. ==# returns a Bool. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: help needed for adding isWHNF primop to 5.00.2
by Simon Marlow 31 Jul '01

31 Jul '01

> From reading the documentation that comes with GHC and > glancing over the > source code, I came to these set of assumptions, please > correct me if I am > wrong: > > - values of unpointed types are never in WHNF That's really up to you, but the normal definition of WHNF applies only to types containing _|_, i.e. pointed types. Unpointed types are never represented by thunks, so I would be inclined to include them in WHNF. > - values of pointed types may be in WHNF, in particular: > > - data constructors are in WHNF > - partial applications are in WHNF > - functions are in WHNF > - thunks are not in WHNF > (this list is probably not exhaustive as you say, but > I am happy > with this set of definitions for the moment) You also have to deal with indirections, although you can assume (at the moment) that an indirection will eventually lead to an object in WHNF. > > I can also imagine it > > could interact badly with the complexities of GHC's > > simplifer. > > This is something I do not know. In the end I may define it > with this type: > > isWHNF :: a -> IO Bool That's the way I'd go. You have to declare the primitive like this, BTW: isWHNF# :: a -> (# State# RealWorld, Int# #) because the compiler doesn't know about the IO type and you can't return a Bool directly. There's no problem with the simplifier as long as you declare the primitive to have the correct properties, i.e. that the polymorphic argument is lazy. > I want it for the purposes of meta-programming, and also for > debugging since > that is what I am working on. At the end of a computation > (that results in > a value of pointed type, say) I want to know to what extent > expressions were > evaluated: > > foo xs = take 3 xs > > ... foo [4..] ... > > debugger> foo [4,5,6,_ = [4,5,6] It sounds like you also need a way to take apart arbitrary objects and look at their components. I know that Andy Gill was also interested in having similar facilities, perhaps he can help out. Cheers, Simon

1 0

RE: help needed for adding isWHNF primop to 5.00.2
by Julian Seward (Intl Vendor) 31 Jul '01

31 Jul '01

| > I would like to add a primitive to GHC 5.00.2 of the form: | > | > isWHNF :: a -> Bool One might be inclined to ask what for? Such a primitive is probably difficult to implement, given the variety of GHC's closures, and is potentially dangerous -- you could conceivably break referential transparency (?) I can also imagine it could interact badly with the complexities of GHC's simplifer. What would you hope to gain from such a thing? Perhaps you have some wider purpose which could be achieved some other way? J

2 1

RE: linking with c++ libraries
by Julian Seward (Intl Vendor) 30 Jul '01

30 Jul '01

| To reliably link with C++, you need to compile both the code | which invokes C++ (i.e. whatever uses the C++ library) and | "main" (that is, ghc/rts/Main.c, not main.hs) with a C++ compiler. | | So, in summary: | | - Compile any code which may call the C++ library (and keep | inter-module inlining in mind; probably safest to compile | all of your code this way) via C, and compile the C with g++. | | - Re-compile the run-time system (at least Main.c) with | g++, too. | | That may not fix your specific core dump, but you'll need to | do this anyway. After some discussion in the GHC office, we're unsure about why you need to compile Main.c with a C++ compiler for this to work. Pls can you clarify? J

2 1