Commit 7d14e369 authored by Simon Marlow's avatar Simon Marlow
Browse files

comment updates

parent 619941b4
...@@ -63,13 +63,6 @@ data GenCmmTop d h g ...@@ -63,13 +63,6 @@ data GenCmmTop d h g
[d] [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 -- Info Tables
----------------------------------------------------------------------------- -----------------------------------------------------------------------------
......
...@@ -30,31 +30,13 @@ import Outputable ...@@ -30,31 +30,13 @@ import Outputable
-- MachOp -- 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 Machine-level primops; ones which we can reasonably delegate to the
native code generators to handle. Basically contains C's primops native code generators to handle.
and no others.
Most operations are parameterised by the 'Width' that they operate on.
Nomenclature: all ops indicate width and signedness, where Some operations have separate signed and unsigned versions, and float
appropriate. Widths: 8\/16\/32\/64 means the given size, obviously. and integer versions.
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.
-} -}
data MachOp data MachOp
......
...@@ -35,12 +35,15 @@ data CmmNode e x where ...@@ -35,12 +35,15 @@ data CmmNode e x where
CmmComment :: FastString -> CmmNode O O 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 CmmStore :: CmmExpr -> CmmExpr -> CmmNode O O
-- given by cmmExprType of the rhs. -- 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 -- Like a "fat machine instruction"; can occur
-- in the middle of a block -- in the middle of a block
ForeignTarget -> -- call target ForeignTarget -> -- call target
......
...@@ -49,10 +49,6 @@ instance Outputable CmmType where ...@@ -49,10 +49,6 @@ instance Outputable CmmType where
instance Outputable CmmCat where instance Outputable CmmCat where
ppr FloatCat = ptext $ sLit("F") ppr FloatCat = ptext $ sLit("F")
ppr _ = ptext $ sLit("I") 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, -- Why is CmmType stratified? For native code generation,
-- most of the time you just want to know what sort of register -- 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 ...@@ -244,7 +240,7 @@ definition of a function is not visible at all of its call sites, so
the compiler cannot infer the hints. the compiler cannot infer the hints.
Here in Cmm, we're taking a slightly different approach. We include 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, platforms have a strong distinction between float and int registers,
and (b) we don't want to do any heavyweight hint-inference in the 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 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 ...@@ -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 have to do this, so we plump for having richer types and keeping the
type information consistent. 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 choice we have is (a), because we don't know whether the result of an
operation should be sign- or zero-extended. operation should be sign- or zero-extended.
...@@ -287,7 +283,7 @@ convention can specify that signed 8-bit quantities are passed as ...@@ -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 sign-extended 32 bit quantities, for example (this is the case on the
PowerPC). So we *do* need sign information on foreign call arguments. 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 - It would let us use convention (b) above, and get easier
code generation for extending loads. code generation for extending loads.
...@@ -300,10 +296,10 @@ Cons: ...@@ -300,10 +296,10 @@ Cons:
- More complexity - 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 always wordRep, but now we have to decide whether it is
signed or unsigned. The same VanillaReg can thus have 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. - Extra coercions cluttering up expressions.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment