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 836, Fri May 25 19:28:51 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
203    Tag: blume-20010719-libreorg
204    Description:
205    
206    This update puts together a fairly extensive but straightforward change
207    to the way the libraries that implement the interactive system are
208    organized:
209    
210       The biggest change is the elimination of structure Compiler.  As a
211       replacement for this structure, there is now a CM library
212       (known as $smlnj/compiler.cm or $smlnj/compiler/current.cm)
213       that exports all the substructures of the original structure Compiler
214       directly.  So instead of saying Compiler.Foo.bar one now simply
215       says Foo.bar.  (The CM libraries actually export a collection of
216       structures that is richer than the collection of substructures of
217       structure Compiler.)
218    
219       To make the transition smooth, there is a separate library called
220       $smlnj/compiler/compiler.cm which puts together and exports the
221       original structure Compiler (or at least something very close to it).
222    
223       There are five members of the original structure Compiler
224       that are not exported directly but which instead became members
225       of a new structure Backend (described by signature BACKEND).  These are:
226       structure Profile (: PROFILE), structure Compile (: COMPILE), structure
227       Interact (: INTERACT), structure Machine (: MACHINE), and val
228       architecture (: string).
229    
230       Structure Compiler.Version has become structure CompilerVersion.
231    
232       Cross-compilers for alpha32, hppa, ppc, sparc, and x86 are provided
233       by $smlnj/compiler/<arch>.cm where <arch> is alpha32, hppa, ppc, sparc,
234       or x86, respectively.
235       Each of these exports the same frontend structures that
236       $smlnj/compiler.cm exports.  But they do not have a structure Backend
237       and instead export some structure <Arch>Backend where <Arch> is Alpha32,
238       Hppa, PPC, Sparc, or X86, respectively.
239    
240       Library $smlnj/compiler/all.cm exports the union of the exports of
241       $smlnj/compiler/<arch>.cm
242    
243       There are no structures <Arch>Compiler anymore, use
244       $smlnj/compiler/<arch>.cm instead.
245    
246       Library host-compiler-0.cm is gone.  Instead, the internal library
247       that instantiates CM is now called cm0.cm.  Selection of the host
248       compiler (backend) is no longer done here but. (Responsibility for it
249       now lies with $smlnj/compiler/current.cm.  This seems to be more
250       logical.)
251    
252       Many individual files have been moved or renamed.  Some files have
253       been split into multiple files, and some "dead" files have been deleted.
254    
255    Aside from these changes to library organization, there are also changes
256    to the way the code itself is organized:
257    
258       Structure Binfile has been re-implemented in such a way that it no
259       longer needs any knowledge of the compiler.  It exclusively deals
260       with the details of binfile layout.  It no longer invokes the
261       compiler (for the purpose of creating new prospective binfile
262       content), and it no longer has any knowledge of how to interpret
263       pickles.
264    
265       Structure Compile (: COMPILE) has been stripped down to the bare
266       essentials of compilation.  It no longer deals with linking/execution.
267       The interface has been cleaned up considerably.
268    
269       Utility routines for dealing with linking and execution have been
270       moved into their own substructures.
271    
272       (The ultimate goal of these changes is to provide a light-weight
273       binfile loader/linker (at least for, e.g., stable libraries) that
274       does not require CM or the compiler to be present.)
275    
276    CM documentation has been updated to reflect the changes to library
277    organization.
278    
279    ----------------------------------------------------------------------
280    Name: Matthias Blume
281    Date: 2001/07/10 17:30:00 EDT
282    Tag: Release_110_34
283    Description:
284    
285    Minor tweak to 110.34 (re-tagged):
286    
287      - README.html file added to CVS repository
288      - runtime compiles properly under FreeBSD 3.X and 4.X
289    
290    ----------------------------------------------------------------------
291    Name: Matthias Blume
292    Date: 2001/07/10 17:30:00 EDT
293    Tag: Release_110_34
294    Description:
295    
296    New version number (110.34). New bootfiles.
297    
298    ----------------------------------------------------------------------
299    Name: Matthias Blume
300    Date: 2001/07/09 16:00:00 EDT
301    Tag: blume-20010709-more-varargs
302    Description:
303    
304    I changed the handling of varargs in ml-nlffigen again:
305    The ellipsis ... will now simply be ignored (with an accompanying warning).
306    
307    The immediate effect is that you can actually call a varargs function
308    from ML -- but you can't actually supply any arguments beyond the ones
309    specified explicitly.  (For example, you can call printf with its format
310    string, but you cannot pass additional arguments.)
311    
312    This behavior is only marginally more useful than the one before, but
313    it has the advantage that a function or, more importantly, a function
314    type never gets dropped on the floor, thus avoiding follow-up problems with
315    other types that refer to the offending one.
316    
317    ----------------------------------------------------------------------
318    Name: Matthias Blume
319    Date: 2001/07/09 11:25:00 EDT
320    Tag: blume-20010709-varargs
321    Description:
322    
323    1. ckit-lib.cm now exports structure Error
324    2. ml-nlffigen reports occurences of "..." (i.e., varargs function types)
325       with a warning accompanied by a source location.  Moreover, it
326       merely skips the offending function or type and proceeds with the
327       rest of its work.u  As a result, one can safely feed C code containing
328       "..." to ml-nlffigen.
329    3. There are some internal improvements to CM, providing slightly
330       more general string substitutions in the tools subsystem.
331    
332    ----------------------------------------------------------------------
333    Name: Matthias Blume
334    Date: 2001/06/27 15:10:00 EDT
335    Tag: blume-20010627-concur
336    Description:
337    
338    Fixed a small bug in CM's handling of parallel compilation.
339    (You could observe the bug by Control-C-interrupting an ordinary
340    CMB.make or CM.stabilize and then attaching some compile servers.
341    The result was that all of a sudden the previously interrupted
342    compilation would continue on its own.  This was because of
343    an over-optimization: CM did not bother to clean out certain queues
344    when no servers were attached "anyway", resulting in the contents
345    of these queues to grab control when new servers did get attached.)
346    
347    There is also another minor update to the CM manual.
348    
349    ----------------------------------------------------------------------
350    Name: Matthias Blume
351    Date: 2001/06/26 16:15:00 EDT
352    Tag: blume-20010626-cmdoc
353    Description:
354    
355    Minor typo fixed in CM manual (syntax diagram for libraries).
356    
357    ----------------------------------------------------------------------
358    Name: Matthias Blume
359    Date: 2001/06/25 22:55:00 EDT
360    Tag: blume-20010625-x86pc
361    Description:
362    
363    Fixed a nasty bug in the X86 assembly code that caused signal
364    handlers to fail (crash) randomly.
365    
366    ----------------------------------------------------------------------
367    Name: Matthias Blume
368    Date: 2001/06/25 12:05:00 EDT
369    Tag: blume-20010625-nlffigen
370    Description:
371    
372    This update fixes a number of minor bugs in ml-nlffigen as reported by
373    Nick Carter <nbc@andrew.cmu.edu>.
374    
375      1. Silly but ok typedefs of the form "typedef void myvoid;" are now accepted.
376      2. Default names for generated files are now derived from the name of
377         the C file *without its directory*.  In particular, this causes generated
378         files to be placed locally even if the C file is in some system directory.
379      3. Default names for generated signatures and structures are also derived
380         from the C file name without its directory.  This avoids silly things
381         like "structure GL/GL".
382         (Other silly names are still possible because ml-nlffigen does not do
383          a thorough check of whether generated names are legal ML identifiers.
384          When in doubt, use command line arguments to force particular names.)
385    
386    ----------------------------------------------------------------------
387    Name: Matthias Blume
388    Date: 2001/06/21 12:25:00 EDT
389    Tag: blume-20010621-eXene
390    Description:
391    
392    eXene now compiles and (sort of) works again.
393    
394    The library name (for version > 110.33) is $/eXene.cm.
395    
396    I also added an new example in src/eXene/examples/nbody.  See the
397    README file there for details.
398    
399    ----------------------------------------------------------------------
400    Name: Matthias Blume
401    Date: 2001/06/20 16:40:00 EDT
402    Tag: blume-20010620-cml
403    Description:
404    
405    CML now compiles and works again.
406    
407    Libraries (for version > 110.33):
408    
409      $cml/cml.cm            Main CML library.
410      $cml/basis.cm          CML's version of $/basis.cm.
411      $cml/cml-internal.cm   Internal helper library.
412      $cml/core-cml.cm       Internal helper library.
413      $cml-lib/trace-cml.cm  Tracing facility.
414      $cml-lib/smlnj-lib.cm  CML's version of $/smlnj-lib.cm
415    
416    The installer (config/install.sh) has been taught how to properly
417    install this stuff.
418    
419    ----------------------------------------------------------------------
420    Name: Matthias Blume
421    Date: 2001/06/19 17:55:00 EDT
422    Tag: blume-20010619-instantiate
423    Description:
424    
425    This un-breaks the fix for bug 1432.
426    (The bug was originally fixed in 110.9 but I broke it again some
427    time after that.)
428    
429    ----------------------------------------------------------------------
430    Name: Matthias Blume
431    Date: 2001/06/19 17:25:00 EDT
432    Tag: blume-20010619-signals
433    Description:
434    
435    This should (hopefully) fix the long-standing signal handling bug.
436    (The runtime system was constructing a continuation record with an
437    incorrect descriptor which would cause the GC to drop data on the floor...)
438    
439    ----------------------------------------------------------------------
440    Name: Matthias Blume
441    Date: 2001/06/15 15:05:00 EDT
442    Tag: blume-20010615-moresparc
443    Description:
444    
445    Here is a short late-hour update related to Sparc c-calls:
446    
447     -- made handling of double-word arguments a bit smarter
448    
449     -- instruction selection phase tries to collapse certain clumsily
450        constructed ML-Trees; typical example:
451    
452            ADD(ty,ADD(_,e,LI d1),LI d2)  ->  ADD(ty,e,LI(d1+d2))
453    
454        This currently has no further impact on SML/NJ since mlriscGen does
455        not seem to generate such patterns in the first place, and c-calls
456        (which did generate them in the beginning) has meanwhile been fixed
457        so as to avoid them as well.
458    
459    ----------------------------------------------------------------------
460    Name: Matthias Blume
461    Date: 2001/06/15 15:05:00 EDT
462    Tag: blume-20010615-sparc
463    Description:
464    
465    The purpose of this update is to provide an implementation of NLFFI
466    on Sparc machines.
467    
468    Here are the changes in detail:
469    
470       * src/MLRISC/sparc/c-calls/sparc-c-calls.sml is a new file containing
471       the Sparc implementation of the c-calls API.
472       * The Sparc backend of SML/NJ has been modified to uniformely use %fp
473       for accessing the ML frame.  Thus, we have a real frame pointer and
474       can freely modify %sp without need for an omit-frame-ptr phase.
475       The vfp logic in src/compiler/CodeGen/* has been changed to accomodate
476       this case.
477       * ml-nlffigen has been taught to produce code for different architectures
478       and calling conventions.
479       * In a way similar to what was done in the x86 case, the Sparc
480       backend uses its own specific extension to mltree.  (For example,
481       it needs to be able to generate UNIMP instructions which are part
482       of the calling convention.)
483       * ml-nlffi-lib was reorganized to make it more modular (in particular,
484       to make it easier to plug in new machine- and os-dependent parts).
485    
486    There are some other fairly unrelated bug fixes and cleanups as well:
487    
488       * I further hacked the .cm files for MLRISC tools (like MDLGen) so
489       that they properly share their libraries with existing SML/NJ libraries.
490       * I fixed a minor cosmetic bug in CM, supressing certain spurious
491       follow-up error messages.
492       * Updates to CM/CMB documentation.
493    
494    TODO items:
495    
496       * MLRISC should use a different register as its asmTemp on the Sparc.
497         (The current %o2 is a really bad choice because it is part of the
498         calling conventions, so things might interfere in unexpected ways.)
499    
500    ----------------------------------------------------------------------
501    Name: Matthias Blume
502    Date: 2001/06/07
503    Tag: blume-20010607-calls
504    Description:
505    
506    A number of internal changes related to C calls and calling conventions:
507    
508    1. ML-Tree CALL statements now carry a "pops" field.  It indicates the
509       number of bytes popped implicitly (by the callee).  In most cases
510       this field is 0 but on x86/win32 it is some non-zero value.  This
511       is information provided for the benefit of the "omit-frameptr" pass.
512    2. The CALL instruction on the x86 carries a similar "pops" field.
513       The instruction selection phase copies its value from the ML-Tree
514       CALL statement.
515    3. On all other architectures, the instruction selection phase checks
516       whether "pops=0" and complains if not.
517    4. The c-calls implementation for x86 now accepts two calling conventions:
518       "ccall" and "stdcall".  When "ccall" is selected, the caller cleans
519       up after the call and pops is set to 0.  For "stdcall", the caller
520       does nothing, leaving the cleanup to the callee; pops is set to
521       the number of bytes that were pushed onto the stack.
522    5. The cproto decoder (compiler/Semant/types/cproto.sml) now can
523       distinguish between "ccall" and "stdcall".
524    6. The UNIMP instruction has been added to the supported Sparc instruction
525       set. (This is needed for implementing the official C calling convention
526       on this architecture.)
527    7. I fixed some of the .cm files under src/MLRISC/Tools to make them
528       work with the latest CM.
529    
530    ----------------------------------------------------------------------
531    Name: Matthias Blume
532    Date: 2001/06/05 15:10:00 EDT
533    Tag: blume-20010605-cm-index
534    Description:
535    
536    0. The "lambdasplit" parameter for class "sml" in CM has been documented.
537    
538    1. CM can now generate "index files".  These are human-readable files
539       that list on a per-.cm-file basis each toplevel symbol defined or
540       imported.  The location of the index file for
541       <p>/<d>.cm is <p>/CM/INDEX/<d>.cm.
542       To enable index-file generation, set CM.Control.generate_index to true
543       or export an environment-symbol: export CM_GENERATE_INDEX=true.
544    
545       The CM manual has been updated accordingly.
546    
547    2. I made some slight modifications to the c-calls API in MLRISC.
548    
549         a) There is now a callback to support saving/restoring of
550            dedicated but caller-save registers around the actual call
551            instruction.
552         b) One can optionally specify a comment-annotation for the
553            call instruction.
554    
555    3. SML/NJ (mlriscGen.sml) uses this new API for the rawccall primop.
556       (For example, the comment annotation shows the C prototype of
557        the function being called.)
558    
559    ----------------------------------------------------------------------
560    Name: Matthias Blume
561    Date: 2001/06/01 13:30:00 EDT
562    Tag: blume-20010601-nlffi-cleanup
563    Description:
564    
565    This is mostly a cleanup of MLFFI stuff:
566    
567       - some signature files have been put into a more exposed place
568       - the ugly 'f type parameter is gone (simplifies types tremendously!)
569       - ml-nlffigen changed accordingly
570       - tutorial updated
571    
572    Other changes:
573    
574       - author's affiliation in CM manual(s) updated
575       - some more recognized keywords added to Allen's sml.sty
576    
577    ----------------------------------------------------------------------
578    Name: Matthias Blume
579  Date: 2001/05/25 15:30:00 EDT  Date: 2001/05/25 15:30:00 EDT
580  Tag: blume-20010525-iptr  Tag: blume-20010525-iptr
581  Description:  Description:

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

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