I installed the new Feb 2001 distribution and I saw that NUM_FIXUPS with value 1000 is only possible for large version of hugs interpreter. It would be great if I could get this version because the standard interpreter only has a NUM_FIXUPS of 400 and so I get the error message "Compiled code too complex". Thank you very much. Christian > -----Urspr> üngliche Nachricht----- > Von: Mark P Jones [SMTP:[EMAIL PROTECTED]] > Gesendet am: Montag, 12. Februar 2001 20:07 > An: [EMAIL PROTECTED]; Laaser Christian > Cc: [EMAIL PROTECTED] > Betreff: RE: AW: What does "Compiled code too complex" error message of Hugs >mean? > > I know this is more than a week old, but I've been away ... and > now that I'm back, I'd like to clear up a possible misunderstanding > that began with an exchange along the following lines: > > | > > When loading some Haskell files with Hugs, I get the error > | > > message "Compiled code too complex". However, the compilation > | > > with GHC 4.08.1 succeeds. > | > > What does this message mean? What can I do about it? > | ... > | > You can grep for that sentence in "hugs98/src", it will point to the > | > file "machine.c". There you will see it says "if nextLab>=NUM_FIXUPS) ...". > | > So grep for "NUM_FIXUPS" it will point to the file "prelude.h". I > | > think the default value is 400, you should increase it to 1000 or so. > | > I have it at 10000, but that's probably not necesary in your case > | > and if you increase constants too much starting up Hugs will become > | > slower. > > First of all, an explanation. Inside Hugs, the code for Haskell > functions is translated into a low-level, abstract machine language. > (In today's environment, the way that Java programs are translated > into JVM bytecode is probably a good analogy.) As the machine > language code is generated, the compiler sometimes needs to insert > "jump" instructions to addresses that are not yet known. In this > situation, it instead inserts a dummy address, but adds an entry to > a simple table of "fixups" that will later be filled in with the > correct address. Once the complete section of code has been generated, > Hugs scans over it once again and replaces each unknown address with > the correct value from the fixups table. This process is also quite > commonly described as "back-patching". > > The fixups table can contain at most NUM_FIXUPS entries, which, in the > current distribution, is set to 400. Programs that require more entries > than this in a single block of code will lead to the "Compiled code too > complex" error message that you have seen. There is not particular > reason for the choice of 400; this is just a number that seemed to work > ok for most practical purposes. If you get a compiled code too complex > message, it is perhaps a sign that you would benefit from looking at > ways to break your code down into smaller, simpler, and more > understandable pieces. More likely, however, you will see this error > with code that was generated automatically, in response to a "deriving" > request on a datatype, or by a tool like a parser generator. In this > case, changing the Haskell code that is generated is not an option. > > Increasing the standard setting for NUM_FIXUPS is certainly an option > here. You would have to increase it a great deal for there to be any > impact on the speed with which Hugs starts. In comparison to the > standard heap sizes that people use, the fixups table is a drop in the > ocean. I think Johan has already increased the size for the Feb 2001 > distribution that will be out in a couple of days. > > The fixups table could be allocated dynamically, and expand on demand. > To understand why Hugs doesn't do it that way already, you need to go > back more than a decade to Gofer, the system from which Hugs was > derived, which was designed to work on an 8086 with segmented memory> > and a maximum of 640K. Back in those days, when loading the prelude > took 30 seconds (and it was much smaller then too!), a statically > allocated table made sense because it was slightly faster and because > there wasn't any spare memory for it to expand into anyway, even if > you went to the trouble of dynamically allocating it. > > Historical note: If you'd like to see the heart of the machine that > ran those original versions of Gofer, come visit me; it's sitting > here on the desk lamp in my office :-) > > All the best, > Mark _______________________________________________ Hugs-Bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/hugs-bugs
