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

Legend:
Removed from v.847  
changed lines
  Added in v.920

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