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 840, Fri Jun 15 19:05:19 2001 UTC revision 890, Thu Jul 19 20:38:56 2001 UTC
# Line 13  Line 13 
13  Description:  Description:
14    
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16    Name: Lal George
17    Date: 2001/07/19 16:36:29 EDT 2001
18    Tag: george-20010719-simple-cells
19    Description:
20    
21    I have dramatically simplified the interface for CELLS in MLRISC.
22    
23    In summary, the cells interface is broken up into three parts:
24    
25      1. CellsBasis : CELLS_BASIS
26    
27            CellsBasis is a top level structure and common for all
28            architectures.  it contains the definitions of basic datatypes
29            and utility  functions over these types.
30    
31      2. functor Cells() : CELLS
32    
33            Cells generates an interface for CELLS that incorporates the
34            specific resources on the target architecture, such as the
35            presence of special register classes, their number and size,
36            and various useful substructures.
37    
38      3. <ARCH>CELLS
39    
40            e.g. SparcCells: SPARCCELLS
41    
42            <ARCH>CELLS usually contains additional bindings for special
43            registers  on the architecture, such as:
44    
45                    val r0 : cell           (* register zero *)
46                    val y : cell            (* Y register *)
47                    val psr : cell          (* processor status register *)
48                    ...
49    
50            The structure returned by applying the Cells functor is opened
51            in this interface.
52    
53    The main implication of all this is that the datatypes for cells is
54    split between CellsBasis and CELLS -- a fairly simple change for user
55    code.
56    
57    In the old scheme the CELLS interface had a definitional binding of
58    the form:
59    
60            signature CELLS = sig
61    
62               structure CellsBasis = CellsBasis
63    
64               ...
65    
66            end
67    
68    With all the sharing constraints that goes on in MLRISC, this old
69    design  quickly leads to errors such as:
70    
71            "structure definition spec inside of sharing ... "
72    
73    
74    and appears to require an unacceptable amount of sharing and where
75    constraint hackery.
76    
77    I think this error message (the interaction of definitional specs and
78    sharing) requires more explanation on our web page.
79    
80    ----------------------------------------------------------------------
81    Name: Matthias Blume
82    Date: 2001/07/19 15:00:00 EDT
83    Tag: blume-20010719-libreorg
84    Description:
85    
86    This update puts together a fairly extensive but straightforward change
87    to the way the libraries that implement the interactive system are
88    organized:
89    
90       The biggest change is the elimination of structure Compiler.  As a
91       replacement for this structure, there is now a CM library
92       (known as $smlnj/compiler.cm or $smlnj/compiler/current.cm)
93       that exports all the substructures of the original structure Compiler
94       directly.  So instead of saying Compiler.Foo.bar one now simply
95       says Foo.bar.  (The CM libraries actually export a collection of
96       structures that is richer than the collection of substructures of
97       structure Compiler.)
98    
99       To make the transition smooth, there is a separate library called
100       $smlnj/compiler/compiler.cm which puts together and exports the
101       original structure Compiler (or at least something very close to it).
102    
103       There are five members of the original structure Compiler
104       that are not exported directly but which instead became members
105       of a new structure Backend (described by signature BACKEND).  These are:
106       structure Profile (: PROFILE), structure Compile (: COMPILE), structure
107       Interact (: INTERACT), structure Machine (: MACHINE), and val
108       architecture (: string).
109    
110       Structure Compiler.Version has become structure CompilerVersion.
111    
112       Cross-compilers for alpha32, hppa, ppc, sparc, and x86 are provided
113       by $smlnj/compiler/<arch>.cm where <arch> is alpha32, hppa, ppc, sparc,
114       or x86, respectively.
115       Each of these exports the same frontend structures that
116       $smlnj/compiler.cm exports.  But they do not have a structure Backend
117       and instead export some structure <Arch>Backend where <Arch> is Alpha32,
118       Hppa, PPC, Sparc, or X86, respectively.
119    
120       Library $smlnj/compiler/all.cm exports the union of the exports of
121       $smlnj/compiler/<arch>.cm
122    
123       There are no structures <Arch>Compiler anymore, use
124       $smlnj/compiler/<arch>.cm instead.
125    
126       Library host-compiler-0.cm is gone.  Instead, the internal library
127       that instantiates CM is now called cm0.cm.  Selection of the host
128       compiler (backend) is no longer done here but. (Responsibility for it
129       now lies with $smlnj/compiler/current.cm.  This seems to be more
130       logical.)
131    
132       Many individual files have been moved or renamed.  Some files have
133       been split into multiple files, and some "dead" files have been deleted.
134    
135    Aside from these changes to library organization, there are also changes
136    to the way the code itself is organized:
137    
138       Structure Binfile has been re-implemented in such a way that it no
139       longer needs any knowledge of the compiler.  It exclusively deals
140       with the details of binfile layout.  It no longer invokes the
141       compiler (for the purpose of creating new prospective binfile
142       content), and it no longer has any knowledge of how to interpret
143       pickles.
144    
145       Structure Compile (: COMPILE) has been stripped down to the bare
146       essentials of compilation.  It no longer deals with linking/execution.
147       The interface has been cleaned up considerably.
148    
149       Utility routines for dealing with linking and execution have been
150       moved into their own substructures.
151    
152       (The ultimate goal of these changes is to provide a light-weight
153       binfile loader/linker (at least for, e.g., stable libraries) that
154       does not require CM or the compiler to be present.)
155    
156    CM documentation has been updated to reflect the changes to library
157    organization.
158    
159    ----------------------------------------------------------------------
160    Name: Matthias Blume
161    Date: 2001/07/10 17:30:00 EDT
162    Tag: Release_110_34
163    Description:
164    
165    Minor tweak to 110.34 (re-tagged):
166    
167      - README.html file added to CVS repository
168      - runtime compiles properly under FreeBSD 3.X and 4.X
169    
170    ----------------------------------------------------------------------
171    Name: Matthias Blume
172    Date: 2001/07/10 17:30:00 EDT
173    Tag: Release_110_34
174    Description:
175    
176    New version number (110.34). New bootfiles.
177    
178    ----------------------------------------------------------------------
179    Name: Matthias Blume
180    Date: 2001/07/09 16:00:00 EDT
181    Tag: blume-20010709-more-varargs
182    Description:
183    
184    I changed the handling of varargs in ml-nlffigen again:
185    The ellipsis ... will now simply be ignored (with an accompanying warning).
186    
187    The immediate effect is that you can actually call a varargs function
188    from ML -- but you can't actually supply any arguments beyond the ones
189    specified explicitly.  (For example, you can call printf with its format
190    string, but you cannot pass additional arguments.)
191    
192    This behavior is only marginally more useful than the one before, but
193    it has the advantage that a function or, more importantly, a function
194    type never gets dropped on the floor, thus avoiding follow-up problems with
195    other types that refer to the offending one.
196    
197    ----------------------------------------------------------------------
198    Name: Matthias Blume
199    Date: 2001/07/09 11:25:00 EDT
200    Tag: blume-20010709-varargs
201    Description:
202    
203    1. ckit-lib.cm now exports structure Error
204    2. ml-nlffigen reports occurences of "..." (i.e., varargs function types)
205       with a warning accompanied by a source location.  Moreover, it
206       merely skips the offending function or type and proceeds with the
207       rest of its work.u  As a result, one can safely feed C code containing
208       "..." to ml-nlffigen.
209    3. There are some internal improvements to CM, providing slightly
210       more general string substitutions in the tools subsystem.
211    
212    ----------------------------------------------------------------------
213    Name: Matthias Blume
214    Date: 2001/06/27 15:10:00 EDT
215    Tag: blume-20010627-concur
216    Description:
217    
218    Fixed a small bug in CM's handling of parallel compilation.
219    (You could observe the bug by Control-C-interrupting an ordinary
220    CMB.make or CM.stabilize and then attaching some compile servers.
221    The result was that all of a sudden the previously interrupted
222    compilation would continue on its own.  This was because of
223    an over-optimization: CM did not bother to clean out certain queues
224    when no servers were attached "anyway", resulting in the contents
225    of these queues to grab control when new servers did get attached.)
226    
227    There is also another minor update to the CM manual.
228    
229    ----------------------------------------------------------------------
230    Name: Matthias Blume
231    Date: 2001/06/26 16:15:00 EDT
232    Tag: blume-20010626-cmdoc
233    Description:
234    
235    Minor typo fixed in CM manual (syntax diagram for libraries).
236    
237    ----------------------------------------------------------------------
238    Name: Matthias Blume
239    Date: 2001/06/25 22:55:00 EDT
240    Tag: blume-20010625-x86pc
241    Description:
242    
243    Fixed a nasty bug in the X86 assembly code that caused signal
244    handlers to fail (crash) randomly.
245    
246    ----------------------------------------------------------------------
247    Name: Matthias Blume
248    Date: 2001/06/25 12:05:00 EDT
249    Tag: blume-20010625-nlffigen
250    Description:
251    
252    This update fixes a number of minor bugs in ml-nlffigen as reported by
253    Nick Carter <nbc@andrew.cmu.edu>.
254    
255      1. Silly but ok typedefs of the form "typedef void myvoid;" are now accepted.
256      2. Default names for generated files are now derived from the name of
257         the C file *without its directory*.  In particular, this causes generated
258         files to be placed locally even if the C file is in some system directory.
259      3. Default names for generated signatures and structures are also derived
260         from the C file name without its directory.  This avoids silly things
261         like "structure GL/GL".
262         (Other silly names are still possible because ml-nlffigen does not do
263          a thorough check of whether generated names are legal ML identifiers.
264          When in doubt, use command line arguments to force particular names.)
265    
266    ----------------------------------------------------------------------
267    Name: Matthias Blume
268    Date: 2001/06/21 12:25:00 EDT
269    Tag: blume-20010621-eXene
270    Description:
271    
272    eXene now compiles and (sort of) works again.
273    
274    The library name (for version > 110.33) is $/eXene.cm.
275    
276    I also added an new example in src/eXene/examples/nbody.  See the
277    README file there for details.
278    
279    ----------------------------------------------------------------------
280    Name: Matthias Blume
281    Date: 2001/06/20 16:40:00 EDT
282    Tag: blume-20010620-cml
283    Description:
284    
285    CML now compiles and works again.
286    
287    Libraries (for version > 110.33):
288    
289      $cml/cml.cm            Main CML library.
290      $cml/basis.cm          CML's version of $/basis.cm.
291      $cml/cml-internal.cm   Internal helper library.
292      $cml/core-cml.cm       Internal helper library.
293      $cml-lib/trace-cml.cm  Tracing facility.
294      $cml-lib/smlnj-lib.cm  CML's version of $/smlnj-lib.cm
295    
296    The installer (config/install.sh) has been taught how to properly
297    install this stuff.
298    
299    ----------------------------------------------------------------------
300    Name: Matthias Blume
301    Date: 2001/06/19 17:55:00 EDT
302    Tag: blume-20010619-instantiate
303    Description:
304    
305    This un-breaks the fix for bug 1432.
306    (The bug was originally fixed in 110.9 but I broke it again some
307    time after that.)
308    
309    ----------------------------------------------------------------------
310    Name: Matthias Blume
311    Date: 2001/06/19 17:25:00 EDT
312    Tag: blume-20010619-signals
313    Description:
314    
315    This should (hopefully) fix the long-standing signal handling bug.
316    (The runtime system was constructing a continuation record with an
317    incorrect descriptor which would cause the GC to drop data on the floor...)
318    
319    ----------------------------------------------------------------------
320    Name: Matthias Blume
321    Date: 2001/06/15 15:05:00 EDT
322    Tag: blume-20010615-moresparc
323    Description:
324    
325    Here is a short late-hour update related to Sparc c-calls:
326    
327     -- made handling of double-word arguments a bit smarter
328    
329     -- instruction selection phase tries to collapse certain clumsily
330        constructed ML-Trees; typical example:
331    
332            ADD(ty,ADD(_,e,LI d1),LI d2)  ->  ADD(ty,e,LI(d1+d2))
333    
334        This currently has no further impact on SML/NJ since mlriscGen does
335        not seem to generate such patterns in the first place, and c-calls
336        (which did generate them in the beginning) has meanwhile been fixed
337        so as to avoid them as well.
338    
339    ----------------------------------------------------------------------
340  Name: Matthias Blume  Name: Matthias Blume
341  Date: 2001/06/15 15:05:00 EDT  Date: 2001/06/15 15:05:00 EDT
342  Tag: blume-20010615-sparc  Tag: blume-20010615-sparc

Legend:
Removed from v.840  
changed lines
  Added in v.890

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