- jhc - Haskell.org

darcs patch: implement grey set as stack rather than ... (and 6 more)
by John Meacham 07 Apr '10

07 Apr '10

Sat Mar 27 15:45:32 PDT 2010 John Meacham <john(a)repetae.net> * implement grey set as stack rather than judy array Sun Mar 28 15:32:43 PDT 2010 John Meacham <john(a)repetae.net> * clean up gc code, rearrange some tests Sun Mar 28 15:32:58 PDT 2010 John Meacham <john(a)repetae.net> * store constant parts of the rts as ByteStrings rather than Haskell Strings Sun Mar 28 20:07:42 PDT 2010 John Meacham <john(a)repetae.net> * clean up gc code Mon Mar 29 13:27:32 PDT 2010 John Meacham <john(a)repetae.net> * add JHC_RTS_INCLUDE #define to easily recompile generated c code with an alternate rts without recompiling via jhc Mon Mar 29 13:51:56 PDT 2010 John Meacham <john(a)repetae.net> * add support for using a supplimental stack for garbage collectable pointers rather than the C stack Mon Mar 29 14:51:33 PDT 2010 John Meacham <john(a)repetae.net> * split up gc rts file into c and h files, handle it similarly to other rts files, clean up code.

1 0

darcs patch: save gc pointer in evaluator function ra... (and 3 more)
by John Meacham 07 Apr '10

07 Apr '10

Fri Mar 26 19:12:22 PDT 2010 John Meacham <john(a)repetae.net> * save gc pointer in evaluator function rather than in eval itself Fri Mar 26 21:45:42 PDT 2010 John Meacham <john(a)repetae.net> * short circuit redirects in the garbage collector Sat Mar 27 11:50:11 PDT 2010 John Meacham <john(a)repetae.net> * greatly simplify garbage collection algorithm, trust underlying malloc implementation more. Sat Mar 27 11:59:13 PDT 2010 John Meacham <john(a)repetae.net> * GC cleanups

1 0

darcs patch: add a lot more of jgc garbage collector (and 2 more)
by John Meacham 07 Apr '10

07 Apr '10

Fri Mar 19 17:55:31 PDT 2010 John Meacham <john(a)repetae.net> * add a lot more of jgc garbage collector Fri Mar 26 17:00:12 PDT 2010 John Meacham <john(a)repetae.net> * remove caf initialization from main routine, let cafs be statically initialized. Fri Mar 26 17:57:13 PDT 2010 John Meacham <john(a)repetae.net> * fix GC bugs so garbage collection works

1 0

darcs patch: redo documentation of internals, clean u... (and 5 more)
by John Meacham 07 Apr '10

07 Apr '10

Thu Mar 18 16:04:04 PDT 2010 John Meacham <john(a)repetae.net> * redo documentation of internals, clean up terminology dealing with smart pointers Thu Mar 18 19:10:48 PDT 2010 John Meacham <john(a)repetae.net> * when storing values inside of smart pointers, be sure to use the proper signedness when extracting/inserting values Thu Mar 18 22:48:50 PDT 2010 John Meacham <john(a)repetae.net> * omit discriminator when it isn't important in structures Fri Mar 19 17:10:34 PDT 2010 John Meacham <john(a)repetae.net> * add some more ToExpression instances Fri Mar 19 17:54:17 PDT 2010 John Meacham <john(a)repetae.net> * include free variables of allocating command when figuring out what to save Fri Mar 19 17:55:02 PDT 2010 John Meacham <john(a)repetae.net> * don't allocate on the stack when using jgc yet

1 0

darcs patch: fix warnings (and 3 more)
by John Meacham 07 Apr '10

07 Apr '10

Mon Mar 1 13:07:54 PST 2010 John Meacham <john(a)repetae.net> * fix warnings Mon Mar 1 13:08:17 PST 2010 John Meacham <john(a)repetae.net> * move core compilation code to E.Main, out of Main Wed Mar 3 02:08:26 PST 2010 John Meacham <john(a)repetae.net> * add gc argument to be passed around for gc context when using jgc Thu Mar 18 16:02:54 PDT 2010 John Meacham <john(a)repetae.net> * produce more compact C names from Grin

1 0

Re: [Haskell-cafe] GHC vs GCC vs JHC
by John Meacham 28 Mar '10

28 Mar '10

On Sat, Mar 27, 2010 at 07:30:30PM -0300, Rafael Cunha de Almeida wrote: > John Meacham wrote: > > Here are jhc's timings for the same programs on my machine. gcc and ghc > > both used -O3 and jhc had its full standard optimizations turned on. > > > > jhc: > > ./hs.out 5.12s user 0.07s system 96% cpu 5.380 total > > > > gcc: > > ./a.out 5.58s user 0.00s system 97% cpu 5.710 total > > > > ghc: > > ./try 31.11s user 0.00s system 96% cpu 32.200 total > > > > > > As you can see, jhc shines at this example, actually beating gcc -O3. It > > isn't too surprising, this is exactly the sort of haskell code that jhc > > excels at. I have not thoroughly checked it, but I think there are a couple things going on here: jhc is able to determine that all the arguments to the various functions are strict, so it can avoid all heap allocations and evaluations. ghc also benefits from this optimization. jhc sees that all the functions are fully applied to all their arguments, this means that they can always be directly called with optimized calling conventions as they will never have to represent generic 'eval' thunks or partial applications. it sees that all the functions are local to 'main' and not exported, so it can actually translate them to local functions in main in grin, allowing some more useful optimizations. Now the most important one, after optimizing the local functions, jhc sees that they are only called in tail-call position, so jhc is able to turn the function calls into direct jumps, turning them directly into C while/for loops operating fully on automatic variables on the stack. These last two optimizations are enabled by an incredibly useful extension to boquist's GRIN which is to allow a form of local function definitions, which solve a number of issues raised in his paper. Via a series of Grin->Grin transformations I am able to turn these local funciton definitions into direct conditional jumps in the resulting code. (which translate to looping constructs, if's and goto's in C) John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

1 0

Darcs head
by humasect 27 Mar '10

27 Mar '10

Hello friends; I have great interest and need for using Haskell with the iPhone. Here I am with JHC, looking to compile, the tarballs seem out of date for GHC 6.12.x but here is a message right after the website instructions of ./autoreconf -i , then ./configure, then make : happy -a -g -c src/FrontEnd/HsParser.y -o src/FrontEnd/HsParser.hs unused rules: 2 shift/reduce conflicts: 73 reduce/reduce conflicts: 23 sed -e 's/^{-# OPTIONS[A-Z_]*/{-# OPTIONS_GHC -w /' -i src/FrontEnd/HsParser.hs sed: -i may not be used with stdin make: *** [src/FrontEnd/HsParser.hs] Error 1 make: *** Deleting file `src/FrontEnd/HsParser.hs' I had looked in the sources a bit to see where 'sed' is called and what other way the -i option is to be used. System is Mac 10.6 I am thinking the -i could be turned into a '<' , but i cannot find where in the source very well. Thanks! -humasect

1 0

updates to internals documentation
by John Meacham 22 Mar '10

22 Mar '10

I spent some time cleaning up and updating the documentation on the internal run-time system. Here it is. # The Run Time System Jhc is very minimalist in that it does not have a precompiled run time system, but rather generates what is needed as part of the compilation process. However, back ends do have specific run-time representations of data, which can be affected by things like the choice of garbage collector. The following describes the general layout for the C based back-ends, but compiler options such as garbage collection method or whether we do full program analysis, will affect which features are used and whether certain optimized layouts are possible. Unboxed values directly translate to values in the target language, an unboxed Int will translate directly into an 'int' as an argument and an unboxed pointer will be a raw pointer. Unboxed values have no special interpretation and are _not_ followed by the garbage collector. If the target language does not support a feature such as multiple return values, it will have to be simulated. It would not be wrong to think of Grin code that only deals with unboxed values to be isomorphic to C-- or C augmented with multiple return values. Boxed values have a standard representation and can be followed. Unlike some other implementation, being boxed does not imply the object is located on the heap. It may be on the stack, heap, or even embedded within the smart pointer itself. Being boxed only means that the object may be represented by a smart pointer, which may or may not actually be a pointer in the traditional sense. A boxed value in jhc is represented by a 'smart pointer' of c type sptr_t. a smart pointer is the size of a native pointer, but can take on different roles depending on a pair of tag bits, called the ptype. smart pointers take on a general form as follows: ------------------------- | payload | GL| ------------------------- G - if set, then the garbage collector should not treat value as a pointer to be followed L - lazy, this bit being set means the value is potentially not in WHNF A sptr_t on its own in the wild can only take on one of the following forms: ------------------------- | whnf raw value | 10| ------------------------- ------------------------- | whnf location | 00| ------------------------- WHNF stands for 'Weak Head Normal Form' and means that the value is not a suspended function and hence not a pointer to a thunk. It may be directly examined and need not be evaluated. wptr_t is an alias for sptr_t that is guarenteed to be of one of the above forms. It is used to improve safety for when we can statically know that a value is WHNF and hence we can skip the expensive 'eval'. The difference between the raw value and the whnf location is that the first contains uninterpreted bits, while the second is a pointer to a location on the heap or stack and hence the garbage collector should follow it. The format of the memory pointed to by the whnf location is unspecified and dependent on the actual type being represented. Partial (unsaturated) applications are normal WHNF values. Saturated applications which may be 'eval'ed and updated are called thunks and must not be pointed to by WHNF pointers. Their representation follows. ------------------------- | lazy location | 01| ------------------------- A lazy location points to either a thunk, or a redirection to a WHNF value. A lazy location is always a pointer to an allocated block of memory which always begins with a restricted smart pointer. This restricted smart pointer is represented by the C type alias 'fptr_t'. fptr_t's only occur as the first entry in a lazy location, they never are passed around as objects in their own right. A fptr_t may be a whnf value or a code pointer. If a fptr_t is a whnf value (of one of the two forms given above) then it is called a redirection, the lazy location should be treated exactly as if it were the whnf given. This is used to redirect an evaluated thunk to its computed value. A fptr_t may also be a 'code pointer' in which case the lazy location is called a thunk. A code pointer is a pointer to executable machine code that evaluates a closure and returns a wptr_t, the returned wptr_t is then generally written over the code pointer, turning the thunk into a redirection. It is the responsibility of the code pointed to to perform this redirection. ------------------------- | code pointer | 11| ------------------------- | data ... | When debugging, the special code pointer BLACK_HOLE is also sometimes stored in a fptr_t to detect certain run-time errors. Note that unlike other implementations, a fptr_t may _not_ be another lazy location. you can not have chained redirections, a redirection is always a redirection to a whnf value. sptr_t - a tagged smart pointer, may contain a whnf value or a lazy location. wptr_t - a tagged smart pointer that contains a whnf value (either raw or a location) fptr_t - a tagged smart pointer, may contain a whnf value indicating a redirection, or a code pointer indicating a thunk. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

2 1

Initial compiling of a source file
by iæfai 06 Mar '10

06 Mar '10

I have managed to get jhc compiled with ghc 6.12.1 and used containers 0.2.0.1. But a problem comes up when I want to compile something that uses Data.Map. Some very basic code: import Data.Map (Map) import Data.Set When compiled, I get this: $ jhc logic1.hs jhc logic1.hs jhc 0.7.4 (-n 0.7.3-1 ) Finding Dependencies... Using Ho Cache: '/Users/iaefai/.jhc/cache' Main [logic1.hs] Error: Module not found: Data.Map Error: Module not found: Data.Set However, I do have containers installed: $ jhc --list-libraries - applicative-1.0 - base-1.0 - jhc-1.0 - containers-0.2.0.1 - haskell98-1.0 What would be the proper way to compile this, or at the very least let it find the modules? Also, is there some documentation generated? I noticed calls to pandoc but didn't notice where they went. - iaefai.

2 1

ghc 6.10
by John Meacham 28 Feb '10

28 Feb '10

Just a note, now that ghc 6.12 is out, I am going to start requiring ghc 6.10 to compile jhc. 0.7.3 should work with 6.8 and 6.10, future versions should work with both 6.10 and 6.12. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

1 0