1. 27 Apr, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-04-27 15:39:18 by sewardj] · 276ff6e8
      sewardj authored
      merge rev 1.69.2.1, which was:
      Remove x86-specific implementation of {intToInt,wordToWord}{8,16,32}#
      primops, and replace them with platform-independent versions expressed
      purely in Stix terms.
      276ff6e8
  2. 28 Feb, 2001 1 commit
    • qrczak's avatar
      [project @ 2001-02-28 00:01:01 by qrczak] · 871db587
      qrczak authored
      * Add {intToInt,wordToWord}{8,16,32}# primops. WARNING: Not implemented
        in ncg for Alpha and Sparc. But -O -fasm is not going to go far anyway
        because of other omissions.
      
      * Have full repertoire of 8,16,32-bit signed and unsigned MachMisc.Size
        values. Again only x86 is fully supported. They are used for
        {index,read,write}{Int,Word}{8,16,32}{OffAddr,Array}# and
        {intToInt,wordToWord}{8,16,32}# primops.
      
      * Have full repertoire of
        {index,read,write}\
        {Char,WideChar,Int,Word,Addr,Float,Double,StablePtr,\
         {Int,Word}{8,16,32,64}}\
        {OffAddr,Array} primops and appropriate instances.
        There were various omissions in various places.
      
      * Add {plus,minus,times}Word# primops to avoid so many Word# <-> Int#
        coercions.
      
      * Rewrite modules PrelWord and PrelInt almost from scratch.
      
      * Simplify fromInteger and realToFrac rules. For each of
        {Int,Word}{8,16,32} there is just a pair of fromInteger rules
        replacing the source or target type with Int or Word. For
        {Int,Word,Int64,Word64} there are rules from any to any.
        Don't include rules which are derivable from inlining anyway,
        e.g. those mentioning Integer. Old explicit coercions are simply
        defined as appropriately typed fromInteger.
      
      * Various old coercion functions marked as deprecated.
      
      * Add instance Bits Int, and
        instance {Show,Num,Real,Enum,Integral,Bounded,Ix,Read,Bits} Word.
      
      * Coercions to sized integer types consistently behave as cutting the
        right amount of bits from the infinite two-complement representation.
        For example (fromIntegral (-1 :: Int8) :: Word64) == maxBound.
      
      * ghc/tests/numeric/should_run/arith011 tests {Int,Word}64 and instance
        Bits Int, and does not try to use overflowing toEnum. arith011.stdout
        is not updated yet because of a problem I will tell about soon.
      
      * Move fromInteger and realToFrac from Prelude to PrelReal.
        Move fromInt from PrelNum to PrelReal and define as fromInteger.
        Define toInt as fromInteger. fromInteger is the place to write
        integer conversion rules for.
      
      * Remove ArrayBase.newInitialisedArray, use default definition of
        newArray instead.
      
      * Bugs fixed:
        - {quot,rem}Word# primop attributes.
        - integerToInt64# for small negative values.
        - {min,max}Bound::Int on 64-bit platforms.
        - iShiftRL64#.
        - Various Bits instances.
      
      * Polishing:
        - Use 'ppr' instead of 'pprPrimOp' and 'text . showPrimRep'.
        - PrimRep.{primRepString,showPrimRepToUser} removed.
        - MachMisc.sizeOf returns Int instead of Integer.
        - Some eta reduction, parens, spacing, and reordering cleanups -
          sorry, couldn't resist.
      
      * Questions:
        - Should iShiftRL and iShiftRL64 be removed? IMHO they should,
          s/iShiftRA/iShiftR/, s/shiftRL/shiftR/. The behaviour on shifting
          is a property of the signedness of the type, not the operation!
          I haven't done this change.
      871db587
  3. 19 Feb, 2001 2 commits
    • sewardj's avatar
      [project @ 2001-02-19 11:38:55 by sewardj] · 8384f6dd
      sewardj authored
      Expand on comments re StString lifting activity
      8384f6dd
    • sewardj's avatar
      [project @ 2001-02-19 10:15:54 by sewardj] · 0879ee32
      sewardj authored
      Fix two bugs exposed when trying to boot HEAD on sparc with NCG and -O:
      
      1.  StScratchWords on sparc were in the wrong place; they were
          immediately above %fp and should have been immediately below.
          Fixed.  Also removed a suspicious-looking "+1" in the x86
          version of same.
      
      2.  (Potentially affects all platforms): Lift strings out from
          top-level literal data, and place them at the end of the block.
          The motivating example (bug) was:
      
           Stix:
              (DataSegment)
              Bogon.ping_closure :
              (Data P_ Addr.A#_static_info)
              (Data StgAddr (Str `alalal'))
              (Data P_ (0))
           results in:
              .data
                      .align 8
              .global Bogon_ping_closure
              Bogon_ping_closure:
                      .long   Addr_Azh_static_info
                      .long   .Ln1a8
              .Ln1a8:
                      .byte   0x61
                      .byte   0x6C
                      .byte   0x61
                      .byte   0x6C
                      .byte   0x61
                      .byte   0x6C
                      .byte   0x00
                      .long   0
         ie, the Str is planted in-line, when what we really meant was to place
         a _reference_ to the string there.  This is Way Wrong (tm).  Fixed.
      0879ee32
  4. 01 Feb, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-02-01 13:35:10 by sewardj] · 9e358c7e
      sewardj authored
      Fix a long-standing roaring bogon in mangleIndexTree, to do with
      not-necessarily-valid assumptions about PrimRep sizes.  In future all
      enquiries about PrimRep sizes should go via MachMisc.primRepToSize
      and/or MachMisc.sizeOf.  The Lord preserve us from random, unportable
      hacks in the NCG.
      9e358c7e
  5. 31 Jan, 2001 1 commit
    • sewardj's avatar
      [project @ 2001-01-31 12:27:24 by sewardj] · 6142c28f
      sewardj authored
      Create PrimReps: {Int|Word}{8|16|32}Rep, for use in the native code
      generator.  And change the rep for character ops from Int8Rep to
      Word8Rep.  This fixes a bug in the sparc NCG in which chars loaded from
      memory were incorrectly sign-extended to 32 bits.  This problem
      appeared when CharRep was turned into a 32-bit quantity, and
      previous uses of it were replaced with Int8Rep, incorrectly, since
      Int8Rep is signed.  Also undo the kludge in the x86 section which
      had (unknown to all) kept it working despite the change to Int8Rep.
      
      sparc NCG now appears to work; hope the x86 side isn't now broken.
      6142c28f
  6. 17 Jan, 2001 1 commit
  7. 20 Dec, 2000 1 commit
  8. 04 Dec, 2000 1 commit
  9. 24 Nov, 2000 1 commit
  10. 13 Nov, 2000 1 commit
    • simonmar's avatar
      [project @ 2000-11-13 11:04:06 by simonmar] · ae034542
      simonmar authored
      Merge register allocation fix for idiv from before-ghci-branch:
      
        1.59.2.1  +2 -37     fptools/ghc/compiler/nativeGen/MachCode.lhs
        1.40.2.1  +15 -4     fptools/ghc/compiler/nativeGen/MachMisc.lhs
        1.43.2.1  +20 -1     fptools/ghc/compiler/nativeGen/PprMach.lhs
        1.26.2.1  +8 -15     fptools/ghc/compiler/nativeGen/RegAllocInfo.lhs
      ae034542
  11. 22 Aug, 2000 1 commit
  12. 21 Aug, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-08-21 15:40:14 by sewardj] · b71148fc
      sewardj authored
      Make the register allocator deal properly with switch tables.
      Previously, it didn't calculate the correct flow edges away from the
      indirect jump (in fact it didn't reckon there were any flow edges
      leaving it :) which makes a nonsense of the live variable analysis in
      the branches.
      
      A jump insn can now optionally be annotated with a list of destination
      labels, and if so, the register allocator creates flow edges to all of
      them.
      
      Jump tables are now re-enabled.  They remain disabled for 4.08.1,
      since we aren't fixing the problem properly on that branch.
      
      I assume this problem wasn't exposed by the old register allocator
      because of the live-range-approximation hacks used in it.  Since it
      was undocumented, we'll never know.
      
      Sparc builds will now break until I fix them.
      b71148fc
  13. 07 Aug, 2000 1 commit
    • qrczak's avatar
      [project @ 2000-08-07 23:37:19 by qrczak] · 4b172698
      qrczak authored
      Now Char, Char#, StgChar have 31 bits (physically 32).
      "foo"# is still an array of bytes.
      
      CharRep represents 32 bits (on a 64-bit arch too). There is also
      Int8Rep, used in those places where bytes were originally meant.
      readCharArray, indexCharOffAddr etc. still use bytes. Storable and
      {I,M}Array use wide Chars.
      
      In future perhaps all sized integers should be primitive types. Then
      some usages of indexing primops scattered through the code could
      be changed to then-available Int8 ones, and then Char variants of
      primops could be made wide (other usages that handle text should use
      conversion that will be provided later).
      
      I/O and _ccall_ arguments assume ISO-8859-1. UTF-8 is internally used
      for string literals (only).
      
      Z-encoding is ready for Unicode identifiers.
      
      Ranges of intlike and charlike closures are more easily configurable.
      
      I've probably broken nativeGen/MachCode.lhs:chrCode for Alpha but I
      don't know the Alpha assembler to fix it (what is zapnot?). Generally
      I'm not sure if I've done the NCG changes right.
      
      This commit breaks the binary compatibility (of course).
      
      TODO:
      * is* and to{Lower,Upper} in Char (in progress).
      * Libraries for text conversion (in design / experiments),
        to be plugged to I/O and a higher level foreign library.
      * PackedString.
      * StringBuffer and accepting source in encodings other than ISO-8859-1.
      4b172698
  14. 27 Jul, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-07-27 09:02:05 by sewardj] · 023fea0f
      sewardj authored
      Redo the sparc Ccall machinery, so as to correctly handle the case
      where one or more of the args to a Ccall is itself a Ccall.  Prior to
      the advent of the Stix inliner, this could never happen, but now it
      does.
      023fea0f
  15. 14 Jul, 2000 1 commit
    • simonpj's avatar
      [project @ 2000-07-14 08:17:36 by simonpj] · 77a8c0db
      simonpj authored
      This commit completely re-does the kind-inference mechanism.
      Previously it was inter-wound with type inference, but that was
      always hard to understand, and it finally broke when we started
      checking for ambiguity when type-checking a type signature (details
      irrelevant).
      
      So now kind inference is more clearly separated, so that it never
      takes place at the same time as type inference.  The biggest change
      is in TcTyClsDecls, which does the kind inference for a group of
      type and class declarations.  It now contains comments to explain
      how it all works.
      
      There are also comments in TypeRep which describes the slightly
      tricky way in which we deal with the fact that kind 'type' (written
      '*') actually has 'boxed type' and 'unboxed type' as sub-kinds.
      The whole thing is a bit of a hack, because we don't really have 
      sub-kinding, but it's less of a hack than before.
      
      A lot of general tidying up happened at the same time.
      In particular, I removed some dead code here and there
      77a8c0db
  16. 13 Jul, 2000 1 commit
  17. 12 Jul, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-07-12 13:04:31 by sewardj] · df0e0b7f
      sewardj authored
      Make the x86 NCG work again following recent sparc hackage.
      
      Also, fix the x86 bits pertaining to the floats-promoted-to-doubles-
      in-ccalls problem.  So this problem should no longer exist on x86
      or sparc via NCG.
      df0e0b7f
  18. 11 Jul, 2000 2 commits
    • simonmar's avatar
      [project @ 2000-07-11 16:24:57 by simonmar] · ff755dd9
      simonmar authored
      remove unused imports
      ff755dd9
    • sewardj's avatar
      [project @ 2000-07-11 15:26:33 by sewardj] · 6254fd4a
      sewardj authored
      Fix up the sparc native code generator.  Mostly dull stuff.  Notable
      changes:
      
      * Cleaned up ccall mechanism for sparc somewhat.
      
      * Rearranged assignment of sparc floating point registers (includes/MachRegs.h)
        so the NCG's register allocator can handle the double-single pairing
        issue without modification.  Split VirtualRegF into VirtualRegF and
        VirtualRegD, and split RcFloating into RcFloat and RcDouble.  Net effect
        is that there are now three register classes -- int, float and double,
        and we pretend that sparc has some float and some double real regs.
      
      * (A fix for all platforms): propagate MachFloats through as StFloats,
        not StDoubles.  Amazingly, until now literal floats had been converted
        to and treated as doubles, including in ccalls.
      6254fd4a
  19. 16 Jun, 2000 1 commit
  20. 15 Jun, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-06-15 08:38:25 by sewardj] · 665229e5
      sewardj authored
      Major thing: new register allocator.  Brief description follows.
      Should correctly handle code with loops in, even though we don't
      generate any such at the moment.  A lot of comments.  The previous
      machinery for spilling is retained, as is the idea of a fast-and-easy
      initial allocation attempt intended to deal with the majority of code
      blocks (about 60% on x86) very cheaply.  Many comments explaining
      in detail how it works :-)
      
      The Stix inliner is now on by default.  Integer code seems to run
      within about 1% of that -fvia-C.  x86 fp code is significantly worse,
      up to about 30% slower, depending on the amount of fp activity.
      
      Minor thing: lazyfication of the top-level NCG plumbing, so that the
      NCG doesn't require any greater residency than compiling to C, just a
      bit more time.  Created lazyThenUs and lazyMapUs for this purpose.
      
      The new allocator is somewhat, although not catastophically, slower
      than the old one.  Fixing of the long-standing NCG space leak more
      than makes up for it; overall hsc run-time is down about 5%, due to
      significantly reduced GC time.
      
      --------------------------------------------------------------------
      
      Instructions are numbered sequentially, starting at zero.
      
      A flow edge (FE) is a pair of insn numbers (MkFE Int Int) denoting
      a possible flow of control from the first insn to the second.
      
      The input to the register allocator is a list of instructions, which
      mention Regs.  A Reg can be a RealReg -- a real machine reg -- or a
      VirtualReg, which carries a unique.  After allocation, all the
      VirtualReg references will have been converted into RealRegs, and
      possibly some spill code will have been inserted.
      
      The heart of the register allocator works in four phases.
      
      1.  (find_flow_edges) Calculate all the FEs for the code list.
          Return them not as a [FE], but implicitly, as a pair of
          Array Int [Int], being the successor and predecessor maps
          for instructions.
      
      2.  (calc_liveness) Returns a FiniteMap FE RegSet.  For each
          FE, indicates the set of registers live on that FE.  Note
          that the set includes both RealRegs and VirtualRegs.  The
          former appear because the code could mention fixed register
          usages, and we need to take them into account from the start.
      
      3.  (calc_live_range_sets) Invert the above mapping, giving a
          FiniteMap Reg FeSet, indicating, for each virtual and real
          reg mentioned in the code, which FEs it is live on.
      
      4.  (calc_vreg_to_rreg_mapping) For virtual reg, try and find
          an allocatable real register for it.  Each real register has
          a "current commitment", indicating the set of FEs it is
          currently live on.  A virtual reg v can be assigned to
          real reg r iff v's live-fe-set does not intersect with r's
          current commitment fe-set.  If the assignment is made,
          v's live-fe-set is union'd into r's current commitment fe-set.
          There is also the minor restriction that v and r must be of
          the same register class (integer or floating).
      
          Once this mapping is established, we simply apply it to the
          input insns, and that's it.
      
          If no suitable real register can be found, the vreg is mapped
          to itself, and we deem allocation to have failed.  The partially
          allocated code is returned.  The higher echelons of the allocator
          (doGeneralAlloc and runRegAlloc) then cooperate to insert spill
          code and re-run allocation, until a successful allocation is found.
      665229e5
  21. 19 May, 2000 1 commit
  22. 18 May, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-05-18 13:55:36 by sewardj] · 963cf411
      sewardj authored
      Teach the NCG about the dereferencing and naming conventions to be
      used when compiling for a DLLised world.  Some cleanups on the way
      too.  The scheme is that
      
      * All CLabels which are in different DLLs from the current module
        will, via the renamer, already be such that labelDynamic returns
        True for them.
      
      * Redo the StixPrim/StixMacro stuff so that all references to symbols
        in the RTS are via CLabels.  That means that the usual labelDynamic
        story can be used.
      
      * When a label is printed in PprMach, labelDynamic is consulted, to
        generate the __imp_ prefix if necessary.
      
      * In MachCode.stmt2Instrs, selectively ask derefDLL to walk trees
        before code generation and insert deferencing code around other-DLL
        symbols.
      
      * When generating Stix for SRTs, add 1 to other-DLL refs.
      
      * When generating static closures, insert a zero word before
        the _closure label.
      963cf411
  23. 16 Mar, 2000 1 commit
  24. 29 Feb, 2000 1 commit
  25. 28 Feb, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-02-28 12:02:31 by sewardj] · 4070b105
      sewardj authored
      Many changes to improve the quality and correctness of generated code,
      both for x86 and all-platforms.  The intent is that the x86 NCG will
      now be good enough for general use.
      
      -- Add an almost-trivial Stix (generic) peephole optimiser, whose sole
         purpose is elide assignments to temporaries used only once, in the
         very next tree.  This generates substantially better code for
         conditionals on all platforms.  Enhance Stix constant folding to
         take advantage of the inlining.
      
         The inlining presents subsequent insn selection phases with more
         complex trees than would have previously been used to.  This has
         shown up several bugs in the x86 insn selectors, now fixed.
         (assumptions that data size is Word, when could be Byte,
          assumptions that an operand will always be in a temp reg, etc)
      
      -- x86: Use the FLDZ and FLD1 insns.
      
      -- x86: spill FP registers with 80-bit loads/stores so that
         Intel's extra 16 bits of accuracy are not lost.  If this isn't
         done, FP spills are not suitably transparent.  Increase the
         number of spill words available to 2048.
      
      -- x86: give the register allocator more flexibility in choosing
         spill temporaries.
      
      -- x86, RegAllocInfo.regUsage: fix error for GST, and rewrite to
         make it clearer.
      
      -- Correctly track movements in the C stack pointer, and generate
         correct spill code for archs which spill against the stack pointer
         even when the stack pointer moves.  Redo the x86 ccall mechanism
         to push args on the C stack in the normal way.  Rather than have
         the spiller have to analyse code sequences to determine the current
         stack offset, the insn selectors communicate the current offset
         whenever it changes by inserting a DELTA pseudo-insn.  Then the
         spiller only has to spot DELTAs.
      
         This means having a new native-code-generator monad (Stix.NatM)
         which carries both a UniqSupply and the current stack offset.
      
      -- Remove the asmPar/asmSeq ways of grouping insns together.
         In the presence of fixed registers, it is hard to demonstrate
         that insn selectors using asmPar always give correct code, and
         the extra complication doesn't help any.
      
         Also, directly construct code sequences using tree-based ordered
         lists (utils/OrdList.lhs) for linear-time appends, rather than
         the bizarrely complex method using fns and fn composition.
      
      -- Inline some hcats in printing of x86 address modes.
      
      -- Document more of the hidden assumptions which insn selection relies
         on, particular wrt addressing modes.
      4070b105
  26. 03 Feb, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-02-03 18:01:03 by sewardj] · 1aa0765b
      sewardj authored
      Fix x86 NCG so the compiler can compile itself `-O':
      
      -- Implement fake x86 insn GITOD/GITOF.
      -- Implement primops ReadMutVarOp and WriteMutVarOp.
      -- Pro tem, disable use of %eax as a spill temp.
      -- Clarify wording of Rules of the Game comment in MachCode.
      1aa0765b
  27. 02 Feb, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-02-02 11:40:33 by sewardj] · a040ea4a
      sewardj authored
      trivialCode on x86 is the heart of instruction selection for
      expressions.  It is definitely a non-trivial in complexity.
      To generate correct code it needs to observe preserve several
      delicate invariants, but didn't.
      
      -- Recorded in MachCode.lhs the "Rules of the Game"; ie what I think
         the required invariants are.
      
      -- Completely rewrote trivialCode (also shift_code).  I think it should
         handle all cases correctly, and has special treatment for literal
         operands.
      
      -- Updated NOTES file to record issues which need to be resolved
         before x86 nativeGen can be considered ready for public use.
      a040ea4a
  28. 01 Feb, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-02-01 14:02:02 by sewardj] · 85ef3b32
      sewardj authored
      -- Cosmetic changes in register allocator.
      
      -- Implement macro HP_GEN_SEQ_NP.
      
      -- MachCode(trivialCode, x86): because one of the operands is also
         the destination (on this 2-address arch), it's invalid to sequence
         the code to compute the operands using asmParThen [code1, code2].
         since the order of assignments matters.  Fixed.
      85ef3b32
  29. 31 Jan, 2000 1 commit
  30. 28 Jan, 2000 2 commits
    • sewardj's avatar
      [project @ 2000-01-28 18:07:55 by sewardj] · c39373f1
      sewardj authored
      Modifications to make x86 register spilling to work reasonably.  It
      should work ok most of the time, although there is still a remote
      possibility that the allocator simply will be unable to complete
      spilling, and will just give up.
      
      -- Incrementally try with 0, 1, 2 and 3 spill regs, so as not to
         unduly restrict the supply of regs in code which doesn't need spilling.
      
      -- Remove the use of %ecx for shift values, so it is always available
         as the first-choice spill temporary.  For code which doesn't do
         int division, make %edx and %eax available for spilling too.
         Shifts by a non-constant amount (very rare) are now done by
         a short test-and-jump sequence, so that %ecx is not tied up.
      
      -- x86 FP: do sin, cos, tan in-line so we get the same answers as gcc.
      
      -- Moved a little code around to remove recursive dependencies.
      
      -- Fix a subtle bug in x86 regUsage, which could cause underestimation
         of live ranges.
      c39373f1
    • sewardj's avatar
      [project @ 2000-01-28 09:40:05 by sewardj] · 8252a068
      sewardj authored
      Commit all changes prior to addressing the x86 spilling situation in
      the register allocator.
      
      -- Fix nonsensical x86 addressing mode hacks in mangleIndexTree
         and getAmode.
      
      -- Make char-sized loads work properly, using MOVZBL.
      
      -- In assignIntCode, use primRep on the assign node to determine
         the size of data transfer, not the size of the source.
      
      -- Redo Integer primitives to be in line with current representation
         of Integers.
      8252a068
  31. 26 Jan, 2000 1 commit
  32. 25 Jan, 2000 4 commits
    • sewardj's avatar
      [project @ 2000-01-25 20:08:33 by sewardj] · db0b3140
      sewardj authored
      Print a useful panic msg if getRegister(x86) can't reduce a tree.
      db0b3140
    • sewardj's avatar
      [project @ 2000-01-25 19:33:32 by sewardj] · 7ed63dba
      sewardj authored
      Handle float args correctly for x86 ccalls.
      7ed63dba
    • sewardj's avatar
      [project @ 2000-01-25 19:18:42 by sewardj] · 172e212b
      sewardj authored
      Disable a dubious looking clause for trivialCode (x86), which was
      generating bad code for some subtracts.
      172e212b
    • 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
      reason.
      b539a820
  33. 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
  34. 20 Jan, 2000 1 commit