> Am I right in thinking that by just putting > > GhcUnregisterised=YES > SplitObjs=NO > > in mk/build.mk every time you build GHC it ought to not only work on > arches with bit-rotted mangler support but also those with none > attempted? Where work means compiles the same set of programs, but the > result (as well as the compilation) will be slower?
Yes, with the caveat that this applies only to the the code *generated* by the GHC you're building. > Starting with a reg compiler producing reg code and iterating > a standard > configure/make/make install with 6.0.1 gives these numbers on x86: > > 70m5.850s > 86m27.550s > 86m26.350s > > so it looks like this is about 25% slower, although I don't know how > much it will vary by architecture. This isn't purely testing GHC of > course, but I think it's probably pretty close. Interesting. Bear in mind that a lot of the time is spent in GCC, and that is going to be roughly the same for registerised vs. unregisterised, so overall compile times don't look much different. However, I think you'll find that ordinary Haskell programs will vary by about a factor of 2 in performance between registerised & unregisterised (last time I checked was a few years ago, though). What are the binary sizes like? > This seems better than no GHC at all for unsupported arch/OS > combinations, and I unfortunately don't have the time to learn the > details of what needs to be done and all the assembly languages and > calling conventions that Debian supports. > > It would also mean that anyone who does want to try to get it working > registerised on an arch could skip the cross-porting stage. Sure, shipping an unregisterised port is completely acceptable. > Incidentally, it looks to me like the comment > > # NOTE: this is not the same as building the compiler itself > # unregisterised. That's done by either (a) bootstrapping with a > # compiler that was built with GhcUnregisterised=YES, or (b) > # bootstrapping with a compiler that has way 'u' libraries, and the > # flag '-unreg' is added to GhcHcOpts above. > > about GhcUnregisterised in mk/config.mk is outdated given the 2-stage > building process that is now the default? Hmm, I should update that comment. Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users