1. 25 Jan, 2000 6 commits
    • simonmar's avatar
      [project @ 2000-01-25 10:31:08 by simonmar] · 4efea26a
      simonmar authored
      urk, Solaris sh doesn't understand [^0-9] in patterns, it seems.
    • sewardj's avatar
      [project @ 2000-01-25 10:25:15 by sewardj] · ddc83d41
      sewardj authored
      Add missing final paragraph of explaination about x86 FP trickery.
    • sewardj's avatar
      [project @ 2000-01-25 10:23:34 by sewardj] · 88f6ec67
      sewardj authored
      Minor improvements to x86 FP fake-to-real insn translation.
    • sewardj's avatar
      [project @ 2000-01-25 10:22:55 by sewardj] · b539a820
      sewardj authored
      genCCall for x86, as supplied, used PUSH et al to move args onto the C
      stack ready for the call.  Reasonable as this seems, it causes a
      problem with spill code, since the spiller spills relative to %esp and
      assumes that %esp doesn't move.  If the args of a ccall involved any
      spilled values, the resulting code would be wrong.
      The One True Way is to do it like a RISC: move args to the stack
      without adjusting %esp for each argument, then adjust it all at once
      immediately prior to the call insn and un-adjust it immediately
      afterwards.  genCCall now does this.  In general, push/pop and other
      C-stack effecting operations should not be generated for the same
    • simonmar's avatar
      [project @ 2000-01-25 10:15:55 by simonmar] · 0f74861a
      simonmar authored
      Add -optCrts-M80m for older compilers.  Sigh.
    • panne's avatar
      [project @ 2000-01-25 10:06:31 by panne] · 415a9993
      panne authored
      Added intToWord to PrelAddr.
      Use it instead of int2Word#-hacks.
  2. 24 Jan, 2000 16 commits
    • sewardj's avatar
      [project @ 2000-01-24 18:33:34 by sewardj] · 3ba6150e
      sewardj authored
      Start a NOTES file, recording known but un-fixed nativeGen bugs.
    • sewardj's avatar
      [project @ 2000-01-24 18:28:53 by sewardj] · 243924b8
      sewardj authored
      Fix syntax errors in #ifdef'd Alpha/Sparc bits.
    • sewardj's avatar
      [project @ 2000-01-24 18:25:17 by sewardj] · 8f43a965
      sewardj authored
      Insert large commit message re x86 FP rehash as a comment.
    • sewardj's avatar
      [project @ 2000-01-24 18:22:07 by sewardj] · 9ac31f7c
      sewardj authored
      ARR_HDR_SIZE --> ARR_WORDS_HDR_SIZE, and derived quantities in
      Constants.h, Constants.lhs et al are similarly renamed.
      new constant ARR_PTRS_HDR_SIZE, with corresponding derivatives.
    • rrt's avatar
      [project @ 2000-01-24 17:44:52 by rrt] · c81c46d2
      rrt authored
      Changed default paper size for SGML output to A4 (%paper-type%).
    • sewardj's avatar
      [project @ 2000-01-24 17:24:23 by sewardj] · e2a7f079
      sewardj authored
      Major reworking of the x86 floating point code generation.
      Intel, in their infinite wisdom, selected a stack model for floating
      point registers on x86.  That might have made sense back in 1979 --
      nowadays we can see it for the nonsense it really is.  A stack model
      fits poorly with the existing nativeGen infrastructure, which assumes
      flat integer and FP register sets.  Prior to this commit, nativeGen
      could not generate correct x86 FP code -- to do so would have meant
      somehow working the register-stack paradigm into the register
      allocator and spiller, which sounds very difficult.
      We have decided to cheat, and go for a simple fix which requires no
      infrastructure modifications, at the expense of generating ropey but
      correct FP code.  All notions of the x86 FP stack and its insns have
      been removed.  Instead, we pretend (to the instruction selector and
      register allocator) that x86 has six floating point registers, %fake0
      .. %fake5, which can be used in the usual flat manner.  We further
      claim that x86 has floating point instructions very similar to SPARC
      and Alpha, that is, a simple 3-operand register-register arrangement.
      Code generation and register allocation proceed on this basis.
      When we come to print out the final assembly, our convenient fiction
      is converted to dismal reality.  Each fake instruction is
      independently converted to a series of real x86 instructions.
      %fake0 .. %fake5 are mapped to %st(0) .. %st(5).  To do reg-reg
      arithmetic operations, the two operands are pushed onto the top of the
      FP stack, the operation done, and the result copied back into the
      relevant register.  There are only six %fake registers because 2 are
      needed for the translation, and x86 has 8 in total.
      The translation is inefficient but is simple and it works.  A cleverer
      translation would handle a sequence of insns, simulating the FP stack
      contents, would not impose a fixed mapping from %fake to %st regs, and
      hopefully could avoid most of the redundant reg-reg moves of the
      current translation.
    • rrt's avatar
      [project @ 2000-01-24 17:09:40 by rrt] · 55400852
      rrt authored
      Added table example.
    • panne's avatar
      [project @ 2000-01-24 16:55:45 by panne] · f5b98196
      panne authored
      Added autoconf magic for size/alignment of some more C types
    • rrt's avatar
      [project @ 2000-01-24 16:47:24 by rrt] · 7db602a0
      rrt authored
      Changed double quotes to “ and ”. Improvements to Windows
      installation instructions.
    • simonmar's avatar
      [project @ 2000-01-24 15:40:57 by simonmar] · 17a29073
      simonmar authored
      Update the Hall of Fame.
    • rrt's avatar
      [project @ 2000-01-24 13:05:01 by rrt] · e5f1291c
      rrt authored
      Stylesheet used for processing SGML. Initially it's identical to the Cygnus
      DocBook Tools stylesheet, with %section-autonumber% set to true for HTML, so
      that all sections are numbered.
    • rrt's avatar
      [project @ 2000-01-24 12:50:16 by rrt] · 1cf8a5ea
      rrt authored
      Set SRC_SGML2XXX_OPTS variables rather than SGML2XXX_OPTS
    • rrt's avatar
      [project @ 2000-01-24 12:43:45 by rrt] · 1e34a97e
      rrt authored
      Wrote 4.06 release notes and updated version numbers in the rest of the user
    • rrt's avatar
      [project @ 2000-01-24 12:42:32 by rrt] · ba714d9f
      rrt authored
      Added SGMLSTYLESHEET variable and set SGML2XXX_OPTS to -d $(SGMLSTYLESHEET)
    • simonpj's avatar
      [project @ 2000-01-24 10:40:05 by simonpj] · 8b298c81
      simonpj authored
      Extra install stuff
    • simonmar's avatar
      [project @ 2000-01-24 09:25:36 by simonmar] · b6547814
      simonmar authored
      Increase the heap size for Parser.hs to 80M (for 4.04).
  3. 23 Jan, 2000 1 commit
    • andy's avatar
      [project @ 2000-01-23 09:55:17 by andy] · ee152a67
      andy authored
      GHC now uses the "Hugs" split function, which is believed to have
      better behaviour: it is not unsafe, is deterministic, and works
      better with QuickCheck, a major client.
      Rational for the Record, quoted from Mark Jones mail on the Hugs list:
      [Mark Jones]
      A couple of months ago, John Hughes sent me mail about a problem that
      he had uncovered with the implementation of the Random library in Hugs.
      He had been using the "split" function in an attempt to generate a
      stream of random number generators, each of which he hoped would be
      different from the others.  But instead he found that he actually
      ended with many different copies of the *same* random number generator.
      A disappointing, and frustratingly non-random result.
      If you don't happen to recall, split is a member of the RandomGen class,
      with type RandomGen g => g -> (g,g); it takes a single random number
      generator as its argument, and returns a pair of two new generators as
      its result.  The only thing that the specification requires is that the
      two generators returned are (a) distinct and (b) `independently robust'
      from a statistical point of view.  To the best of my knowledge, the
      implementation in Hugs meets this modest specification.  Sadly, assuming
      only this specification, you cannot write the function that John was
      looking for and be sure that it will generate more than two different
      For example, the specification allows even the following trivial
      implementation for split:  split _ = (g1, g2), where g1 and g2 are some
      arbitrary but constant pair of distinct, and independently robust
      generators.  With this implementation, you can split as often as you
      want and you'll never get more that two generators.
      Hugs and GHC (as far as I can tell) both use definitions of the form:
         split g = (g, f g)
      for some function f.  (My understanding of the code in GHC is that it
      uses an unsafe function for f, breaking referential transparency; I hope
      the optimizer knows about this.)  Note that this definition returns the
      argument as a result; the specification doesn't prohibit that; all it
      requires is that the two results returned be distinct.  But if you try
      to generate a list of n different generators using:
         take n (iterate (fst . split) g)
      then you will be sorely disappointed; you might as well have written
      replicate n g.  (On the other hand, if you were lucky enough to have
      used (snd . split), instead of (fst . split), then you wouldn't have
      noticed the problem ...)
      I know very little about the mathematics or pragmatics of random
      number generators, so I'm not sure that I know how to fix this
      problem.  However, starting from this position of ignorance, I have
      hacked up a new version of "split" for the standard "StdGen" that
      will appear in the next release of Hugs (real soon now!).  Judging
      from the tests that I've tried so far, it seems to work much
      better than the old version.  That said:
       - Take care if you use Random.split in your programs, because it
         may not do what you expect.
       - There should probably be an errata about this for the Haskell 98
         library report ... if somebody can figure out what it should say.
       - If you use Hugs, be aware that the implementation of Random.split
         was hacked up by someone who has no way of justifying that
         implementation, beyond some simple experiments.
       - If you know something about the mechanics of random number
         generators, here's an area where Haskell specifications and
         implementations could benefit from your knowledge!
      All the best,
      [end quote]
  4. 22 Jan, 2000 5 commits
  5. 20 Jan, 2000 5 commits
  6. 19 Jan, 2000 5 commits
  7. 18 Jan, 2000 2 commits