- Yhc - Haskell.org

Patch: 'Fix reading from past the end of G_markTable in mkt_firstMarked ()'
by Michał Pałka 20 Mar '06

20 Mar '06

I discovered this using Valgrind and Electric Fence. There are also mallocs of size 0 that are considered errors by efence. Should I attempt to fix them? Michal

1 0

AMD64 port complete (hopefully)
by Michał Pałka 19 Mar '06

19 Mar '06

Tom, I have spotted the bug that was crashing the GC on AMD64 and now YHC seems to run stable on that platform. I'm sending the patches that darcs found missing in the official yhc-devel repo. I can't crash yhi anymore. It ran fine on Queens 4x4 test with QUITE_PARANOID turned on and heap size tuned to force garbage collection cycles. I think you can proclaim YHC ported to Linux/AMD64;) Or do you have ideas of other tests to run? Michal

1 0

Re: [Yhc] building yhc on FreeBSD
by David Frech 16 Mar '06

16 Mar '06

If you come up with a version that you want me to test on FreeBSD, just ping me or the list. Cheers, - David On 3/16/06, Andrew Wilkinson <andrewjwilkinson(a)gmail.com> wrote: > On 3/16/06, David Frech <yhc(a)nimblemachines.com> wrote: > > The issue is that autoconf+configure and gcc aren't looking in > > /usr/local/{include,lib} for the libgmp stuff (gmp.h and the > > libraries). > > > > /usr/local is also a standard location under Linux so configure should have > been looking there. I'm not really sure where exactly to look to change > that, but I have been playing around trying to replace the seperate > Windows/Unix build scripts and the evil autoconf/automake hackery by > replacing them with scons. Currently I've got as far as generating config.h > and building yhi and yhc. I just need to try and build the library now. I > haven't talked to Tom about whether he's actually interested in replacing > automake/autoconf but assuming he is I'll ensure the new build scripts look > in the right place :-) > > Andrew > > > _______________________________________________ > Yhc mailing list > Yhc(a)haskell.org > http://haskell.org/mailman/listinfo/yhc > > > -- Life's better on two wheels. http://nimblemachines.com/browse?name=cycl -- Life's better on two wheels. http://nimblemachines.com/browse?name=cycl

1 0

building yhc on FreeBSD
by David Frech 16 Mar '06

16 Mar '06

Folks - I just recently (last night) did a darcs get of the yhc-devel source and tried to build it on a FreeBSD system. I ran into a couple of small problems, easily solved. It should be easy to tweak the config/make setup to work with BSD systems, which put "external" libraries (like gmp) in /usr/local. The issue is that autoconf+configure and gcc aren't looking in /usr/local/{include,lib} for the libgmp stuff (gmp.h and the libraries). I have gmp 4.1.4 installed - probably because I installed GHC - so I was surprised that libgmp wasn't being discovered. I couldn't figure out - in the time that my patience allowed - how to make autoconf do the right thing so I simply commented out the configure checks (which were bombing out and claiming I didn't have a gmp library) and added -I/usr/local/include to CFLAGS and -L/usr/local/lib to LDFLAGS (in yhc-devel/src/runtime/BCKernel/Makefile), and added "-lgmp" to LIBS in the toplevel Makefile.inc. I was able to build everything (using "gmake" - what GNU make is called on BSD systems), and ran "gmake tests" and got 51/51 passes. Hope this helps, - David -- Life's better on two wheels. http://nimblemachines.com/browse?name=cycl

2 1

Libraries
by Neil Mitchell 14 Mar '06

14 Mar '06

Hi, Just to inform everyone, I've got Data.Map and Data.Set going through with Yhc, so maybe self-compiling isn't as far away as everyone (i.e. Me) thought :) The things that are required to get the haskell.org libraries working are: 1) Directory, which requires FFI (Tom is working on this) 2) Delete haskell98 package supplied with Yhc, most of this is in the haskell.org haskell98 package, which needs setting up (should be easy) (I will do this, after the other steps) 3) Move all the heirarchial stuff in yhc-base to Yhc.Internal.* - absolutely everything must go in that namespace, including Prelude etc. Some of the modules want to die (Data.Maybe) some just need moving. Moving most should be easy, moving Prelude will probably be hard. (I will probably need Tom's help for this) 4) Modify the haskell.org base package to be Yhc compatible, the changes should be minimal. In particular Prelude will need to import Yhc.Internal.Prelude. I have some rough patches, some features required and just some general maintenance required. (Some bits are going to be Tom's domain, I can do the rest). This will make haskell98, base and yhc-base all required packages for a default Yhc installation, and all required to build Yhc itself. Thanks Neil

1 0

Can YHC compile itself?
by Adam Megacz 13 Mar '06

13 Mar '06

Hey, just wondering how far YHC is from being able to self-host... anybody have an idea? - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380

2 1

YHC on AMD64
by Michał Pałka 12 Mar '06

12 Mar '06

YHC hackers, I've managed to run hello world with YHC on AMD64. This required changing the definition of UShort type from HALF_TYPE which is 32-bit int to short. The problem lied in mutator.c where jTable variable was meant to contain 2-byte integers but contained 4-byte integers on AMD64 and jumps were calculated wrong. The patch I've attached is only for reference. I don't know what is the correct type for UShort (or maybe jTable shouldn't be UShort * ?). I wanted to run some tests and was pointed to src/tester by Neil. However, all the test failed because of some Makefile problems. Output attached. Do you have any nontrivial code that runs on YHC/i386? I would like to test it on my machine. Thanks, Michal --------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912

4 9

some initial questions
by Robert Dockins 09 Mar '06

09 Mar '06

Hello YHC hackers, I've been looking pretty closely at YHC and I have a couple of questions: 1) I'm interested in the possibility of doing Java-style verification of bytecode, so I've been studying the bytecode docs. Looking at the bytecodes, I notice that all the jump bytecodes seem to indicate that jumps are always forward jumps. Upon reflection it makes perfect sense, but I want to make sure that is a conscious design decision. It certainly makes the kinds of analysis I'm interested in easier... 2) I notice that concurrency is a big unclaimed todo item. Are there any concrete plans in this direction? I'm sort of interested in this, but before I think about it too much, I was wondering what has and has not been thought about/done so far. Thanks! Rob Dockins

6 9

Yhc bytecode thoughts
by Neil Mitchell 05 Mar '06

05 Mar '06

Hi, This message is probably mainly targeted at Tom, but since we have a mailing list and other people may be interested, I thought I'd send it to everyone. I was looking at compiled bytecode, and I noticed things that might be able to be improved - in rough order of difficulty. I don't think any of these impact on the backend at all, but might make faster code in general. == SLIDE 0 == I noticed some of these, I take it they are a noop? If so, lets peephole them away! Probably one line of code... == JUMP_FALSE -> JUMP_ZERO == If we moved from JUMP_FALSE to JUMP_ZERO (which i take it is the same semantics anyway!) then this could often be used for case statements on two constructors (say lists, for example). Also case on a bool is expanded to a case, if we had JUMP_ZERO this could be collapsed back as a more general transformation. Less code, faster code, happier code. == EVAL; JUMP; RETURN == I noticed a few things that EVAL, then JUMP, then RETURN - of course you could collapse the EVAL to EVAL_RETURN and throw away the jump. Less code, more speed, everyone is happy :) == branch factorisation == I noticed a few cases where two branches both jump to the same place, and execute the same code, but the code before the jump's are the same. These could be factorised into the after the jump bit - less code, same speed, there are possibly more important things before worrying about this... Thanks Neil

2 2

Re: [Yhc] Yhc bytecode thoughts
by shackell＠cs.york.ac.uk 05 Mar '06

05 Mar '06

Hi Neil, How did you get the bytecodes you looked at? I suspect you might be printing the bytecode too early (i.e. not the final form). I suspect this because ... > == SLIDE 0 =I noticed some of these, I take it they are a noop? If so, > lets > peephole them away! Probably one line of code... ... this is already implemented, in Bytecode/Peep.hs peepIns (SLIDE 0:is) = peepIns is Along with others like POP 0, SLIDE n;SLIDE m, SLIDE n;RETURN, EVAL;EVAL. > == JUMP_FALSE -> JUMP_ZERO =If we moved from JUMP_FALSE to JUMP_ZERO > (which i take it is the same > semantics anyway!) then this could often be used for case statements > on two constructors (say lists, for example). Also case on a bool is > expanded to a case, if we had JUMP_ZERO this could be collapsed back > as a more general transformation. Less code, faster code, happier > code. You could, on the downside it might complicate Hat G-Machine tracing somewhat though ... (because now you need to issue a case even though the bytecode is for an if etc.) > == EVAL; JUMP; RETURN =I noticed a few things that EVAL, then JUMP, then > RETURN - of course > you could collapse the EVAL to EVAL_RETURN and throw away the jump. > Less code, more speed, everyone is happy :) Again I suspect you're printing the code out too early because I believe it should do this already. The compiler traces the possible paths through the program and if it must end in a return then it replaces the jump with a RETURN instruction instead of a jump. i.e. << BLAH >> << BLAH >> JUMP end becomes RETURN << BLAH >> << BLAH >> end: RETURN RETURN And EVAL ; RETURN is removed by the peepholer peepIns (EVAL:RETURN:is) = peepIns (RETURN_EVAL:is) (infact this is the only place that RETURN_EVAL can be introduced into the code). > == branch factorisation =I noticed a few cases where two branches both > jump to the same place, > and execute the same code, but the code before the jump's are the > same. These could be factorised into the after the jump bit - less > code, same speed, there Yes both this and the related optimisation of common code merging (i.e. if there are two seperate blocks of code that are actually identical) didn't seem to be common enough to merit the effort. Of course it would be possible but I figured it was probably only one or two bytes in one or two functions. Hope that answers your questions :-) Tom

1 0