Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Diff of /sml/trunk/HISTORY
ViewVC logotype

Diff of /sml/trunk/HISTORY

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 879, Thu Jul 19 18:59:38 2001 UTC revision 902, Wed Aug 15 21:17:05 2001 UTC
# Line 14  Line 14 
14    
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16  Name: Matthias Blume  Name: Matthias Blume
17    Date: 2001/08/15 17:15:00 EDT
18    Tag: blume-20010815-compreorg
19    Description:
20    
21    This is a first cut at reorganizing the CM libraries that make up the
22    core of the compiler.  The idea is to separate out pieces that could
23    be used independently by tools, e.g., the parser, the typechecker, etc.
24    
25    The current status is a step in this direction, but it is not quite
26    satisfactory yet.  Expect more changes in the future.
27    
28    Here is the current (new) organization...
29    
30        What used to be $smlnj/viscomp/core.cm is now divided into
31        six CM libraries:
32    
33             $smlnj/viscomp/basics.cm
34                           /parser.cm
35                           /elabdata.cm
36                           /elaborate.cm
37                           /execute.cm
38                           /core.cm
39    
40        The CM files for these libraries live under src/system/smlnj/viscomp.
41        All these libraries are proxy libraries that contain precisely
42        one CM library component.  Here are the locations of the components
43        (all within the src/compiler tree):
44    
45             Basics/basics.cm
46             Parse/parser.cm
47             ElabData/elabdata.cm
48             Elaborator/elaborate.cm
49             Execution/execute.cm
50             core.cm
51    
52         [This organization is the same that has been used already
53         for a while for the architecture-specific parts of the visible
54         compiler and for the old version of core.cm.]
55    
56         As you will notice, many source files have been moved from their
57         respective original locations to a new home in one of the above
58         subtrees.
59    
60         The division of labor between the new libraries is the following:
61    
62             basics.cm:
63                - Simple, basic definitions that pertain to many (or all) of
64                  the other libraries.
65             parser.cm:
66                - The SML parser, producing output of type Ast.dec.
67                - The type family for Ast is also defined and exported here.
68             elabdata.cm:
69                - The datatypes that describe input and output of the elaborator.
70                  This includes types, absyn, and static environments.
71             elaborator.cm:
72                - The SML/NJ type checker and elaborator.
73                  This maps an Ast.dec (with a given static environment) to
74                  an Absyn.dec (with a new static environment).
75                - This libraries implements certain modules that used to be
76                  structures as functors (to remove dependencies on FLINT).
77             execute.cm:
78                - Everything having to do with executing binary code objects.
79                - Dynamic environments.
80             core.cm:
81                - SML/NJ-specific instantiations of the elaborator and MLRISC.
82                - Top-level modules.
83                - FLINT (this should eventually become its own library)
84    
85    Notes:
86    
87    I am not 100% happy with the way I separated the elaborator (and its
88    data structures) from FLINT.  Two instances of the same problem:
89    
90        1. Data structures contain certain fields that carry FLINT-specific
91           information.  I hacked around this using exn and the property list
92           module from smlnj-lib.  But the fact that there are middle-end
93           specific fields around at all is a bit annoying.
94    
95        2. The elaborator calculates certain FLINT-related information.  I tried
96           to make this as abstract as I could using functorization, but, again,
97           the fact that the elaborator has to perform calculations on behalf
98           of the middle-end at all is not nice.
99    
100        3. Having to used exn and property lists is unfortunate because it
101           weakens type checking.  The other alternative (parameterizing
102           nearly *everything*) is not appealing, though.
103    
104    I removed the "rebinding =" warning hack because due to the new organization
105    it was awkward to maintain it.  As a result, the compiler now issues some of
106    these warnings when compiling init.cmi during bootstrap compilation. On
107    the plus side, you also get a warning when you do, for example:
108       val op = = Int32.+
109    which was not the case up to now.
110    
111    I placed "assign" and "deref" into the _Core structure so that the
112    code that deals with the "lazy" keyword can find them there.  This
113    removes the need for having access to the primitive environment
114    during elaboration.
115    
116    ----------------------------------------------------------------------
117    Name: Matthias Blume
118    Date: 2001/08/13
119    Tag: blume-20010813-closures
120    Description:
121    
122    This fix was sent to us by Zhong Shao.  It is supposed to improve the
123    performance of certain loops by avoiding needless closure allocation.
124    
125    ----------------------------------------------------------------------
126    Name: Lal George
127    Date: 2001/07/31 10:03:23 EDT 2001
128    Tag: george-20010731-x86-fmalloc
129    Description: Fixed bug in x86 calls
130    
131        There was a bug where call instructions would mysteriously
132        vanish. The call instruction had to be one that returned
133        a floating point value.
134    
135    ----------------------------------------------------------------------
136    Name: Lal George
137    Date: 2001/07/19 16:36:29 EDT 2001
138    Tag: george-20010719-simple-cells
139    Description:
140    
141    I have dramatically simplified the interface for CELLS in MLRISC.
142    
143    In summary, the cells interface is broken up into three parts:
144    
145      1. CellsBasis : CELLS_BASIS
146    
147            CellsBasis is a top level structure and common for all
148            architectures.  it contains the definitions of basic datatypes
149            and utility  functions over these types.
150    
151      2. functor Cells() : CELLS
152    
153            Cells generates an interface for CELLS that incorporates the
154            specific resources on the target architecture, such as the
155            presence of special register classes, their number and size,
156            and various useful substructures.
157    
158      3. <ARCH>CELLS
159    
160            e.g. SparcCells: SPARCCELLS
161    
162            <ARCH>CELLS usually contains additional bindings for special
163            registers  on the architecture, such as:
164    
165                    val r0 : cell           (* register zero *)
166                    val y : cell            (* Y register *)
167                    val psr : cell          (* processor status register *)
168                    ...
169    
170            The structure returned by applying the Cells functor is opened
171            in this interface.
172    
173    The main implication of all this is that the datatypes for cells is
174    split between CellsBasis and CELLS -- a fairly simple change for user
175    code.
176    
177    In the old scheme the CELLS interface had a definitional binding of
178    the form:
179    
180            signature CELLS = sig
181    
182               structure CellsBasis = CellsBasis
183    
184               ...
185    
186            end
187    
188    With all the sharing constraints that goes on in MLRISC, this old
189    design  quickly leads to errors such as:
190    
191            "structure definition spec inside of sharing ... "
192    
193    
194    and appears to require an unacceptable amount of sharing and where
195    constraint hackery.
196    
197    I think this error message (the interaction of definitional specs and
198    sharing) requires more explanation on our web page.
199    
200    ----------------------------------------------------------------------
201    Name: Matthias Blume
202  Date: 2001/07/19 15:00:00 EDT  Date: 2001/07/19 15:00:00 EDT
203  Tag: blume-20010719-libreorg  Tag: blume-20010719-libreorg
204  Description:  Description:

Legend:
Removed from v.879  
changed lines
  Added in v.902

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0