%
% (c) The GRASP/AQUA Project, Glasgow University, 1992-1998
%
-% $Id: AbsCSyn.lhs,v 1.36 2001/05/22 13:43:14 simonpj Exp $
+% $Id: AbsCSyn.lhs,v 1.45 2002/02/06 11:13:47 sewardj Exp $
%
\section[AbstractC]{Abstract C: the last stop before machine code}
module AbsCSyn {- (
-- export everything
AbstractC(..),
+ C_SRT(..)
CStmtMacro(..),
CExprMacro(..),
CAddrMode(..),
import Literal ( mkMachInt, Literal(..) )
import ForeignCall ( CCallSpec )
import PrimRep ( PrimRep(..) )
+import MachOp ( MachOp(..) )
import Unique ( Unique )
-import StgSyn ( StgOp, SRT(..) )
+import StgSyn ( StgOp )
import TyCon ( TyCon )
import BitSet -- for liveness masks
import FastTypes
+import Outputable
\end{code}
@AbstractC@ is a list of Abstract~C statements, but the data structure
| CInitHdr -- to initialise the header of a closure (both fixed/var parts)
ClosureInfo
CAddrMode -- address of the info ptr
- CAddrMode -- cost centre to place in closure
+ !CAddrMode -- cost centre to place in closure
-- CReg CurCostCentre or CC_HDR(R1.p{-Node-})
+ Int -- size of closure, for profiling
+
+ -- NEW CASES FOR EXPANDED PRIMOPS
+
+ | CMachOpStmt -- Machine-level operation
+ CAddrMode -- result
+ MachOp
+ [CAddrMode] -- Arguments
+ (Maybe [MagicId]) -- list of regs which need to be preserved
+ -- across the primop. This is allowed to be Nothing only if
+ -- machOpIsDefinitelyInline returns True. And that in turn may
+ -- only return True if we are absolutely sure that the mach op
+ -- can be done inline on all platforms.
+
+ | CSequential -- Do the nested AbstractCs sequentially.
+ [AbstractC] -- In particular, as far as the AbsCUtils.doSimultaneously
+ -- is concerned, these stmts are to be treated as atomic
+ -- and are not to be reordered.
+
+ -- end of NEW CASES FOR EXPANDED PRIMOPS
| COpStmt
[CAddrMode] -- Results
| CRetDirect -- Direct return
!Unique -- for making labels
AbstractC -- return code
- (CLabel,SRT) -- SRT info
+ C_SRT -- SRT info
Liveness -- stack liveness at the return point
-- see the notes about these next few; they follow below...
-- *** the next three [or so...] are DATA (those above are CODE) ***
| CStaticClosure
- CLabel -- The (full, not base) label to use for labelling the closure.
- ClosureInfo
+ ClosureInfo -- Todo: maybe info_lbl & closure_lbl instead?
CAddrMode -- cost centre identifier to place in closure
[CAddrMode] -- free vars; ptrs, then non-ptrs.
| CSRT CLabel [CLabel] -- SRT declarations: basically an array of
-- pointers to static closures.
- | CBitmap CLabel LivenessMask -- A larger-than-32-bits bitmap.
+ | CBitmap CLabel LivenessMask -- A bitmap to be emitted if and only if
+ -- it is larger than a target machine word.
| CClosureInfoAndCode
ClosureInfo -- Explains placement and layout of closure
| CRetVector -- A labelled block of static data
CLabel
[CAddrMode]
- (CLabel,SRT) -- SRT info
+ C_SRT -- SRT info
Liveness -- stack liveness at the return point
| CClosureTbl -- table of constructors for enumerated types
-- CostCentre.lhs)
| CSplitMarker -- Split into separate object modules here
+
+-- C_SRT is what StgSyn.SRT gets translated to...
+-- we add a label for the table, and expect only the 'offset/length' form
+
+data C_SRT = NoC_SRT
+ | C_SRT CLabel !Int{-offset-} !Int{-length-}
+
+needsSRT :: C_SRT -> Bool
+needsSRT NoC_SRT = False
+needsSRT (C_SRT _ _ _) = True
\end{code}
About @CMacroStmt@, etc.: notionally, they all just call some
-- which gives the magic location itself
-- (NB: superceded by CReg)
+ -- JRS 2002-02-05: CAddr is really scummy and should be fixed.
+ -- The effect is that the semantics of CAddr depend on what the
+ -- contained RegRelative is; it is decidely non-orthogonal.
+
| CReg MagicId -- To replace (CAddr MagicId 0)
| CTemp !Unique !PrimRep -- Temporary locations
!PrimRep -- the kind of the result
CExprMacro -- the macro to generate a value
[CAddrMode] -- and its arguments
+
+ | CBytesPerWord -- Word size, in bytes, on this platform
+ -- required for: half-word loads (used in fishing tags
+ -- out of info tables), and sizeofByteArray#.
\end{code}
Various C macros for values which are dependent on the back-end layout.
representation really is a bitmap). These are pinned onto case return
vectors to indicate the state of the stack for the garbage collector.
+In the compiled program, liveness bitmaps that fit inside a single
+word (StgWord) are stored as a single word, while larger bitmaps are
+stored as a pointer to an array of words. When we compile via C
+(especially when we bootstrap via HC files), we generate identical C
+code regardless of whether words are 32- or 64-bit on the target
+machine, by postponing the decision of how to store each liveness
+bitmap to C compilation time (or rather, C preprocessing time).
+
\begin{code}
type LivenessMask = [BitSet]
-data Liveness = LvSmall BitSet
- | LvLarge CLabel
+data Liveness = Liveness CLabel LivenessMask
\end{code}
%************************************************************************
| CurrentTSO -- pointer to current thread's TSO
| CurrentNursery -- pointer to allocation area
+ | HpAlloc -- allocation count for heap check failure
node = VanillaReg PtrRep (_ILIT 1) -- A convenient alias for Node
projects / ghc-hetmet.git / blobdiff