comment updates

compiler/cmm/CmmDecl.hs

@@ -63,13 +63,6 @@ data GenCmmTop d h g
         [d]
 
 
--- A basic block containing a single label, at the beginning.
--- The list of basic blocks in a top-level code block may be re-ordered.
--- Fall-through is not allowed: there must be an explicit jump at the
--- end of each basic block, but the code generator might rearrange basic
--- blocks in order to turn some jumps into fallthroughs.
-
-
 -----------------------------------------------------------------------------
 --     Info Tables
 -----------------------------------------------------------------------------

compiler/cmm/CmmMachOp.hs

@@ -30,31 +30,13 @@ import Outputable
 --              MachOp
 -----------------------------------------------------------------------------
 
-{-
-Implementation notes:
-
-It might suffice to keep just a width, without distinguishing between
-floating and integer types.  However, keeping the distinction will
-help the native code generator to assign registers more easily.
--}
-
-
 {- |
 Machine-level primops; ones which we can reasonably delegate to the
-native code generators to handle.  Basically contains C's primops
-and no others.
-
-Nomenclature: all ops indicate width and signedness, where
-appropriate.  Widths: 8\/16\/32\/64 means the given size, obviously.
-Nat means the operation works on STG word sized objects.
-Signedness: S means signed, U means unsigned.  For operations where
-signedness is irrelevant or makes no difference (for example
-integer add), the signedness component is omitted.
-
-An exception: NatP is a ptr-typed native word.  From the point of
-view of the native code generators this distinction is irrelevant,
-but the C code generator sometimes needs this info to emit the
-right casts.
+native code generators to handle.
+
+Most operations are parameterised by the 'Width' that they operate on.
+Some operations have separate signed and unsigned versions, and float
+and integer versions.
 -}
 
 data MachOp

compiler/cmm/CmmNode.hs

@@ -35,12 +35,15 @@ data CmmNode e x where
 
   CmmComment :: FastString -> CmmNode O O
 
-  CmmAssign :: CmmReg -> CmmExpr -> CmmNode O O  -- Assign to register
+  CmmAssign :: CmmReg -> CmmExpr -> CmmNode O O
+    -- Assign to register
 
-  CmmStore :: CmmExpr -> CmmExpr -> CmmNode O O  -- Assign to memory location.  Size is
-                                                 -- given by cmmExprType of the rhs.
+  CmmStore :: CmmExpr -> CmmExpr -> CmmNode O O
+    -- Assign to memory location.  Size is
+    -- given by cmmExprType of the rhs.
 
-  CmmUnsafeForeignCall ::         -- An unsafe foreign call; see Note [Foreign calls]
+  CmmUnsafeForeignCall ::         -- An unsafe foreign call;
+                                  -- see Note [Foreign calls]
   		       		  -- Like a "fat machine instruction"; can occur
 				  -- in the middle of a block
       ForeignTarget ->            -- call target

compiler/cmm/CmmType.hs

@@ -49,10 +49,6 @@ instance Outputable CmmType where
 instance Outputable CmmCat where
   ppr FloatCat  = ptext $ sLit("F")
   ppr _         = ptext $ sLit("I")
--- Temp Jan 08
---  ppr FloatCat        = ptext $ sLit("float")
---  ppr BitsCat   = ptext $ sLit("bits")
---  ppr GcPtrCat  = ptext $ sLit("gcptr")
 
 -- Why is CmmType stratified?  For native code generation,
 -- most of the time you just want to know what sort of register
@@ -244,7 +240,7 @@ definition of a function is not visible at all of its call sites, so
 the compiler cannot infer the hints.
 
 Here in Cmm, we're taking a slightly different approach.  We include
-the int vs. float hint in the MachRep, because (a) the majority of
+the int vs. float hint in the CmmType, because (a) the majority of
 platforms have a strong distinction between float and int registers,
 and (b) we don't want to do any heavyweight hint-inference in the
 native code backend in order to get good code.  We're treating the
@@ -272,7 +268,7 @@ of analysis that propagates hints around.  In Cmm we don't want to
 have to do this, so we plump for having richer types and keeping the
 type information consistent.
 
-If signed/unsigned hints are missing from MachRep, then the only
+If signed/unsigned hints are missing from CmmType, then the only
 choice we have is (a), because we don't know whether the result of an
 operation should be sign- or zero-extended.
 
@@ -287,7 +283,7 @@ convention can specify that signed 8-bit quantities are passed as
 sign-extended 32 bit quantities, for example (this is the case on the
 PowerPC).  So we *do* need sign information on foreign call arguments.
 
-Pros for adding signed vs. unsigned to MachRep:
+Pros for adding signed vs. unsigned to CmmType:
 
   - It would let us use convention (b) above, and get easier
     code generation for extending loads.
@@ -300,10 +296,10 @@ Cons:
 
   - More complexity
 
-  - What is the MachRep for a VanillaReg?  Currently it is
+  - What is the CmmType for a VanillaReg?  Currently it is
     always wordRep, but now we have to decide whether it is
     signed or unsigned.  The same VanillaReg can thus have
-    different MachReps in different parts of the program.
+    different CmmType in different parts of the program.
 
   - Extra coercions cluttering up expressions.