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 875, Tue Jul 10 21:19:41 2001 UTC revision 915, Fri Aug 24 18:21:00 2001 UTC
# Line 13  Line 13 
13  Description:  Description:
14    
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16    Name: Lal George
17    Date: 2001/08/24 13:47:18 EDT 2001
18    Tag: george-20010824-MLRISC-graphs
19    Description:
20    
21     removed clusters from MLRISC completely and replaced with graphs.
22    
23    ----------------------------------------------------------------------
24    Name: Matthias Blume
25    Date: 2001/08/23 17:50:00 EDT
26    Tag: blume-20010823-toplevel
27    Description:
28    
29    - some reorganization of the code that implements various kinds of
30      environments in the compiler (static, dynamic, symbolic, combined)
31    - re-implemented the EnvRef module so that evalStream works properly
32      (if the stream contains references to "use", "CM.make", etc.)
33    - cleaned up evalloop.sml and interact.sml (but they need more cleaning)
34    
35    ----------------------------------------------------------------------
36    Name: Matthias Blume
37    Date: 2001/08/20 15:50 EDT
38    Tag: blume20010820-slipup
39    Description:
40    
41    I forgot to commit a few files.  Here they are...
42    
43    ----------------------------------------------------------------------
44    Name: Matthias Blume
45    Date: 2001/08/20 15:35:00 EDT
46    Tag: blume-20010820-debugprof
47    Description:
48    
49    !!!! NEW BOOTFILES !!!!
50    
51    This is another round of reorganizing the compiler sources.  This
52    time the main goal was to factor out all the "instrumentation"
53    passes (for profiling and backtracing) into their own library.
54    The difficulty was to do it in such a way that it does not depend
55    on elaborate.cm but only on elabdata.cm.
56    
57    Therefore there have been further changes to both elaborate.cm and
58    elabdata.cm -- more "generic" things have been moved from the former
59    to the latter.  As a result, I was forced to split the assignment
60    of numbers indicating "primtyc"s into two portions: SML-generic and
61    SML/NJ-specific.  Since it would have been awkward to maintain,
62    I bit the bullet and actually _changed_ the mapping between these
63    numbers and primtycs.  The bottom line of this is that you need
64    a new set of bin- and bootfiles.
65    
66    I have built new bootfiles for all architectures, so doing a fresh
67    checkout and config/install.sh should be all you need.
68    
69    The newly created library's name is
70    
71        $smlnj/viscomp/debugprof.cm
72    
73    and its sources live under
74    
75        src/compiler/DebugProf
76    
77    ----------------------------------------------------------------------
78    Name: Matthias Blume
79    Date: 2001/08/15 17:15:00 EDT
80    Tag: blume-20010815-compreorg
81    Description:
82    
83    This is a first cut at reorganizing the CM libraries that make up the
84    core of the compiler.  The idea is to separate out pieces that could
85    be used independently by tools, e.g., the parser, the typechecker, etc.
86    
87    The current status is a step in this direction, but it is not quite
88    satisfactory yet.  Expect more changes in the future.
89    
90    Here is the current (new) organization...
91    
92        What used to be $smlnj/viscomp/core.cm is now divided into
93        six CM libraries:
94    
95             $smlnj/viscomp/basics.cm
96                           /parser.cm
97                           /elabdata.cm
98                           /elaborate.cm
99                           /execute.cm
100                           /core.cm
101    
102        The CM files for these libraries live under src/system/smlnj/viscomp.
103        All these libraries are proxy libraries that contain precisely
104        one CM library component.  Here are the locations of the components
105        (all within the src/compiler tree):
106    
107             Basics/basics.cm
108             Parse/parser.cm
109             ElabData/elabdata.cm
110             Elaborator/elaborate.cm
111             Execution/execute.cm
112             core.cm
113    
114         [This organization is the same that has been used already
115         for a while for the architecture-specific parts of the visible
116         compiler and for the old version of core.cm.]
117    
118         As you will notice, many source files have been moved from their
119         respective original locations to a new home in one of the above
120         subtrees.
121    
122         The division of labor between the new libraries is the following:
123    
124             basics.cm:
125                - Simple, basic definitions that pertain to many (or all) of
126                  the other libraries.
127             parser.cm:
128                - The SML parser, producing output of type Ast.dec.
129                - The type family for Ast is also defined and exported here.
130             elabdata.cm:
131                - The datatypes that describe input and output of the elaborator.
132                  This includes types, absyn, and static environments.
133             elaborator.cm:
134                - The SML/NJ type checker and elaborator.
135                  This maps an Ast.dec (with a given static environment) to
136                  an Absyn.dec (with a new static environment).
137                - This libraries implements certain modules that used to be
138                  structures as functors (to remove dependencies on FLINT).
139             execute.cm:
140                - Everything having to do with executing binary code objects.
141                - Dynamic environments.
142             core.cm:
143                - SML/NJ-specific instantiations of the elaborator and MLRISC.
144                - Top-level modules.
145                - FLINT (this should eventually become its own library)
146    
147    Notes:
148    
149    I am not 100% happy with the way I separated the elaborator (and its
150    data structures) from FLINT.  Two instances of the same problem:
151    
152        1. Data structures contain certain fields that carry FLINT-specific
153           information.  I hacked around this using exn and the property list
154           module from smlnj-lib.  But the fact that there are middle-end
155           specific fields around at all is a bit annoying.
156    
157        2. The elaborator calculates certain FLINT-related information.  I tried
158           to make this as abstract as I could using functorization, but, again,
159           the fact that the elaborator has to perform calculations on behalf
160           of the middle-end at all is not nice.
161    
162        3. Having to used exn and property lists is unfortunate because it
163           weakens type checking.  The other alternative (parameterizing
164           nearly *everything*) is not appealing, though.
165    
166    I removed the "rebinding =" warning hack because due to the new organization
167    it was awkward to maintain it.  As a result, the compiler now issues some of
168    these warnings when compiling init.cmi during bootstrap compilation. On
169    the plus side, you also get a warning when you do, for example:
170       val op = = Int32.+
171    which was not the case up to now.
172    
173    I placed "assign" and "deref" into the _Core structure so that the
174    code that deals with the "lazy" keyword can find them there.  This
175    removes the need for having access to the primitive environment
176    during elaboration.
177    
178    ----------------------------------------------------------------------
179    Name: Matthias Blume
180    Date: 2001/08/13
181    Tag: blume-20010813-closures
182    Description:
183    
184    This fix was sent to us by Zhong Shao.  It is supposed to improve the
185    performance of certain loops by avoiding needless closure allocation.
186    
187    ----------------------------------------------------------------------
188    Name: Lal George
189    Date: 2001/07/31 10:03:23 EDT 2001
190    Tag: george-20010731-x86-fmalloc
191    Description: Fixed bug in x86 calls
192    
193        There was a bug where call instructions would mysteriously
194        vanish. The call instruction had to be one that returned
195        a floating point value.
196    
197    ----------------------------------------------------------------------
198    Name: Lal George
199    Date: 2001/07/19 16:36:29 EDT 2001
200    Tag: george-20010719-simple-cells
201    Description:
202    
203    I have dramatically simplified the interface for CELLS in MLRISC.
204    
205    In summary, the cells interface is broken up into three parts:
206    
207      1. CellsBasis : CELLS_BASIS
208    
209            CellsBasis is a top level structure and common for all
210            architectures.  it contains the definitions of basic datatypes
211            and utility  functions over these types.
212    
213      2. functor Cells() : CELLS
214    
215            Cells generates an interface for CELLS that incorporates the
216            specific resources on the target architecture, such as the
217            presence of special register classes, their number and size,
218            and various useful substructures.
219    
220      3. <ARCH>CELLS
221    
222            e.g. SparcCells: SPARCCELLS
223    
224            <ARCH>CELLS usually contains additional bindings for special
225            registers  on the architecture, such as:
226    
227                    val r0 : cell           (* register zero *)
228                    val y : cell            (* Y register *)
229                    val psr : cell          (* processor status register *)
230                    ...
231    
232            The structure returned by applying the Cells functor is opened
233            in this interface.
234    
235    The main implication of all this is that the datatypes for cells is
236    split between CellsBasis and CELLS -- a fairly simple change for user
237    code.
238    
239    In the old scheme the CELLS interface had a definitional binding of
240    the form:
241    
242            signature CELLS = sig
243    
244               structure CellsBasis = CellsBasis
245    
246               ...
247    
248            end
249    
250    With all the sharing constraints that goes on in MLRISC, this old
251    design  quickly leads to errors such as:
252    
253            "structure definition spec inside of sharing ... "
254    
255    
256    and appears to require an unacceptable amount of sharing and where
257    constraint hackery.
258    
259    I think this error message (the interaction of definitional specs and
260    sharing) requires more explanation on our web page.
261    
262    ----------------------------------------------------------------------
263    Name: Matthias Blume
264    Date: 2001/07/19 15:00:00 EDT
265    Tag: blume-20010719-libreorg
266    Description:
267    
268    This update puts together a fairly extensive but straightforward change
269    to the way the libraries that implement the interactive system are
270    organized:
271    
272       The biggest change is the elimination of structure Compiler.  As a
273       replacement for this structure, there is now a CM library
274       (known as $smlnj/compiler.cm or $smlnj/compiler/current.cm)
275       that exports all the substructures of the original structure Compiler
276       directly.  So instead of saying Compiler.Foo.bar one now simply
277       says Foo.bar.  (The CM libraries actually export a collection of
278       structures that is richer than the collection of substructures of
279       structure Compiler.)
280    
281       To make the transition smooth, there is a separate library called
282       $smlnj/compiler/compiler.cm which puts together and exports the
283       original structure Compiler (or at least something very close to it).
284    
285       There are five members of the original structure Compiler
286       that are not exported directly but which instead became members
287       of a new structure Backend (described by signature BACKEND).  These are:
288       structure Profile (: PROFILE), structure Compile (: COMPILE), structure
289       Interact (: INTERACT), structure Machine (: MACHINE), and val
290       architecture (: string).
291    
292       Structure Compiler.Version has become structure CompilerVersion.
293    
294       Cross-compilers for alpha32, hppa, ppc, sparc, and x86 are provided
295       by $smlnj/compiler/<arch>.cm where <arch> is alpha32, hppa, ppc, sparc,
296       or x86, respectively.
297       Each of these exports the same frontend structures that
298       $smlnj/compiler.cm exports.  But they do not have a structure Backend
299       and instead export some structure <Arch>Backend where <Arch> is Alpha32,
300       Hppa, PPC, Sparc, or X86, respectively.
301    
302       Library $smlnj/compiler/all.cm exports the union of the exports of
303       $smlnj/compiler/<arch>.cm
304    
305       There are no structures <Arch>Compiler anymore, use
306       $smlnj/compiler/<arch>.cm instead.
307    
308       Library host-compiler-0.cm is gone.  Instead, the internal library
309       that instantiates CM is now called cm0.cm.  Selection of the host
310       compiler (backend) is no longer done here but. (Responsibility for it
311       now lies with $smlnj/compiler/current.cm.  This seems to be more
312       logical.)
313    
314       Many individual files have been moved or renamed.  Some files have
315       been split into multiple files, and some "dead" files have been deleted.
316    
317    Aside from these changes to library organization, there are also changes
318    to the way the code itself is organized:
319    
320       Structure Binfile has been re-implemented in such a way that it no
321       longer needs any knowledge of the compiler.  It exclusively deals
322       with the details of binfile layout.  It no longer invokes the
323       compiler (for the purpose of creating new prospective binfile
324       content), and it no longer has any knowledge of how to interpret
325       pickles.
326    
327       Structure Compile (: COMPILE) has been stripped down to the bare
328       essentials of compilation.  It no longer deals with linking/execution.
329       The interface has been cleaned up considerably.
330    
331       Utility routines for dealing with linking and execution have been
332       moved into their own substructures.
333    
334       (The ultimate goal of these changes is to provide a light-weight
335       binfile loader/linker (at least for, e.g., stable libraries) that
336       does not require CM or the compiler to be present.)
337    
338    CM documentation has been updated to reflect the changes to library
339    organization.
340    
341    ----------------------------------------------------------------------
342    Name: Matthias Blume
343    Date: 2001/07/10 17:30:00 EDT
344    Tag: Release_110_34
345    Description:
346    
347    Minor tweak to 110.34 (re-tagged):
348    
349      - README.html file added to CVS repository
350      - runtime compiles properly under FreeBSD 3.X and 4.X
351    
352    ----------------------------------------------------------------------
353  Name: Matthias Blume  Name: Matthias Blume
354  Date: 2001/07/10 17:30:00 EDT  Date: 2001/07/10 17:30:00 EDT
355  Tag: Release_110_34  Tag: Release_110_34

Legend:
Removed from v.875  
changed lines
  Added in v.915

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