1. 25 Jan, 2000 1 commit
  2. 24 Jan, 2000 1 commit
    • 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.
      e2a7f079
  3. 18 Jan, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-01-18 13:29:35 by sewardj] · 7f748c5f
      sewardj authored
      Don't spew floating/double literals into assembly output, since this
      causes difficulties with FP numbers near the edges of the allowed
      ranges.  Instead, convert them to a sequence of bytes and emit those.
      7f748c5f
  4. 29 Jul, 1999 1 commit
  5. 02 Dec, 1998 1 commit
  6. 14 Aug, 1998 1 commit
    • sof's avatar
      [project @ 1998-08-14 12:00:22 by sof] · 91b4fb8d
      sof authored
      StCall now takes extra callconv arg; StixPrim.primCode doesn't flush stdout and stderr anymore (it's done in the .hc code)
      91b4fb8d
  7. 30 Jan, 1998 1 commit
  8. 08 Jan, 1998 1 commit
    • simonm's avatar
      [project @ 1998-01-08 18:03:08 by simonm] · 9dd6e1c2
      simonm authored
      The Great Multi-Parameter Type Classes Merge.
      
      Notes from Simon (abridged):
      
      * Multi-parameter type classes are fully implemented.
      * Error messages from the type checker should be noticeably improved
      * Warnings for unused bindings (-fwarn-unused-names)
      * many other minor bug fixes.
      
      Internally there are the following changes
      
      * Removal of Haskell 1.2 compatibility.
      * Dramatic clean-up of the PprStyle stuff.
      * The type Type has been substantially changed.
      * The dictionary for each class is represented by a new
        data type for that purpose, rather than by a tuple.
      9dd6e1c2
  9. 24 Nov, 1997 1 commit
  10. 19 Oct, 1997 1 commit
    • sof's avatar
      [project @ 1997-10-19 22:11:54 by sof] · 452789f2
      sof authored
      Updated to reflect MachRegs.Addr to MachRegs.Address renaming; x86: Hp and HpLim are located relative to BaseReg, not StorageMgrInfo
      452789f2
  11. 05 Jul, 1997 1 commit
  12. 20 Jun, 1997 1 commit
  13. 18 Jun, 1997 1 commit
  14. 06 Jun, 1997 1 commit
  15. 19 May, 1997 1 commit
  16. 30 Jun, 1996 1 commit
  17. 26 Jun, 1996 1 commit
  18. 05 Jun, 1996 1 commit
  19. 16 May, 1996 1 commit
  20. 30 Apr, 1996 1 commit
  21. 07 Apr, 1996 1 commit
  22. 05 Apr, 1996 1 commit