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

SCM Repository

[smlnj] Annotation of /sml/releases/release-110.37/READMES/110.27-README.html
ViewVC logotype

Annotation of /sml/releases/release-110.37/READMES/110.27-README.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 994 - (view) (download) (as text)

1 : dbm 620 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2 :     <html>
3 :     <head>
4 :     <title>SML/NJ Version 110.25 NEWS</title>
5 :     </head>
6 :    
7 :     <body bgcolor="white">
8 :     <center><h1>Standard ML of New Jersey<BR>
9 :     Version 110.27, April 10, 2000</h1>
10 :     </center>
11 :    
12 :     <center>
13 :     <tt> http://cm.bell-labs.com/cm/cs/what/smlnj/index.html </tt>
14 :     </center>
15 :    
16 :     <blockquote>
17 :     <center>
18 :     <h2> Warning </h2>
19 :     </center>
20 :     <blockquote>
21 :     <blockquote>
22 :     <em>
23 :     This version is intended for compiler hackers.
24 :     We are in the midst of substantial structural changes,
25 :     and this is a snapshot.
26 :     </em>
27 :     </blockquote>
28 :     </blockquote>
29 :    
30 :     <hr>
31 :    
32 :     <center><h2>Summary:</h2></center>
33 :     <UL>
34 :     <LI> This version has some minor tweeks to FLINT (after the major merge
35 :     in 110.26). Work continues on tuning FLINT and the various optimizations
36 :     it implements.
37 :     <p>
38 :     <LI> CM has been revised extensively, and the modmap environment mechanism
39 :     supporting stubbified pickles has been reworked completely. The pathconfig
40 :     file has been simplified. Installation scripts have been further
41 :     modified. See src/system/README and the latest version of the
42 :     CM manual at
43 :     <blockquote>
44 :     <//http://www.kurims.kyoto-u.ac.jp/~blume/SMLNJ-DEV/manual/index.html>
45 :     <//http://www.kurims.kyoto-u.ac.jp/~blume/SMLNJ-DEV/manual.ps>
46 :     </blockquote>
47 :     for further information about these changes.
48 :     <p>
49 :     <li> MRISC, and particularly the x86 back end have been modified extensively.
50 :     <p>
51 :     <li> There are a few updates to the SML/NJ Library
52 :     <p>
53 :     <li> Reported bug fixes:<br>
54 :     1556. (jhr) signal race condition<br>
55 :     Some CM bugs (not recorded)
56 :     <p>
57 :     <li> Distribution file names have been simplified. They no longer start
58 :     with the version number (e.g. "110.27-config.tar.gz" is now
59 :     simply "config.tar.gz"). The boot directory tarballs are now
60 :     "boot.alpha32-unix.tar.gz", etc. (i.e. no version number and the
61 :     "sml." prefix is dropped). The new install script will restore
62 :     the usual name (e.g. "sml.boot.alpha32-unix" when the tarball is
63 :     unpacked. [We dropped the initial "sml." for the boot tarballs to
64 :     get the file names under 28 characters because of a limitation of
65 :     the Bell Labs ftp server.]
66 :     The version README file is still named 110.27-README, however.
67 :     <blockquote>
68 :     <pre>
69 :     110.27-README
70 :     HISTORY
71 :     MLRISC.tar.gz
72 :     boot.alpha32-unix.tar.gz
73 :     boot.hppa-unix.tar.gz
74 :     boot.ppc-unix.tar.gz
75 :     boot.sparc-unix.tar.gz
76 :     boot.x86-unix.tar.gz
77 :     cm.tar.gz
78 :     compiler.tar.gz
79 :     config.tar.gz
80 :     ml-burg.tar.gz
81 :     ml-lex.tar.gz
82 :     ml-yacc.tar.gz
83 :     runtime.tar.gz
84 :     smlnj-lib.tar.gz
85 :     system.tar.gz
86 :     </pre>
87 :     </blockquote>
88 :    
89 :     <hr>
90 :     <h2> Change Details </h2>
91 :     <center><h3> FLINT </h3></center>
92 :     Improved handling of branches (mostly those generated from
93 :     polymorphic equality), removed switchoff and changed the
94 :     default optimization settings (more cpsopt and less flintopt).
95 :    
96 :     <hr>
97 :     <center><h3> MLRISC </h3></center>
98 :     <ol>
99 :     <li> Register Allocator
100 :     <ol type="a">
101 :     <li> The interface and implementation of the register allocator have been
102 :     changed slightly to accommodate the possibility of skipping
103 :     the register allocation phases completely and go directly to
104 :     memory allocation. This is needed for C-- use.
105 :     <li> I've improved the spill propagation algorithm, using an approximation
106 :     of maximal weighted independent sets. This affects only the x86
107 :     platform.
108 :     </ol>
109 :     <p>
110 :     <li> MLTREE
111 :     <ol type="a">
112 :     <li> Renamed the constructor CALL in MLTREE by popular demand.
113 :     </ol>
114 :     <p>
115 :     <li> X86
116 :     <ol type="a">
117 :     <li> More assembly output problems involving the indexed addressing mode
118 :     on the x86 have been found and corrected. Thanks to Fermin Reig for the
119 :     fix.
120 :     <li> x86Rewrite bug with MUL3 (found by Lal)
121 :     <li> Added the instructions FSTS, FSTL
122 :     <li> The old code generated for SETcc was completely wrong.
123 :     The Intel optimization guide is VERY misleading.
124 :     <li> Various fixes related floating point, and extensions.
125 :     <li> Things like
126 :     <pre>
127 :     jmp %eax
128 :     jmp (%eax)
129 :     </pre>
130 :     are now output as
131 :     <pre>
132 :     jmp *%eax
133 :     jmp *(%eax)
134 :     </pre>
135 :     <li> Yet another fix for x86 assembly for idivl, imull, mull and friends.
136 :     <li> I've changed andl to testl in the floating point test sequence
137 :     whenever appropriate. The Intel optimization guide states that
138 :     testl is perferable to andl.
139 :     </ol>
140 :     <p>
141 :     <li> Alpha
142 :     <ol type="a">
143 :     <li> Some extra patterns related to loads with signed/zero extension
144 :     provided by Fermin.
145 :     <li> Added the instructions LDBU, LDWU, STB, STW as per Fermin's suggestion.
146 :     <li> Added a new mode byteWordLoadStores to the functor parameter to Alpha()
147 :     <li> Added reassociation code for address computation.
148 :     </ol>
149 :     <p>
150 :     <li> PA-RISC
151 :     <ol type="a">
152 :     <li> B label should not be a delay slot candidate! Why did this work?
153 :     <li> <code>ADDT(32, REG(32, r), LI n)</code> now generates one
154 :     instruction instead of two, as it should be.
155 :     <li> The assembly syntax for fstds and fstdd was wrong.
156 :     <li> Added the composite instruction <code>COMICLR/LDO</code>, which is the immediate
157 :     operand variant of <code>COMCLR/LDO</code>.
158 :     <li> Long jumps in span dependence resolution used to depend on the existence
159 :     of the base pointer in the SML/NJ runtime.
160 :     <p>
161 :     A jump to a long label <code>L</code> was expanded into the following sequence:
162 :     <pre>
163 :     LDIL %hi(L-8192), %r29
164 :     LDO %lo(L-8192)(%r29), %r29
165 :     ADD %r29, baseptr, %r29
166 :     BV,n %r0(%r29)
167 :     </pre>
168 :     I've changed it so that the following sequence of instructions
169 :     are generated, which doesn't mention the base pointer at all:
170 :     <pre>
171 :     BL,n L', %r29 /* branch and link, L' + 4 -> %r29 */
172 :     L': ADDIL L-(L'+4), %r29 /* Compute address of L */
173 :     BV,n %r0(%r29) /* Jump */
174 :     </pre>
175 :     </ol>
176 :     <p>
177 :     <li> Generic MLRISC
178 :     <ol type="a">
179 :     <li> shuffle.sml rewritten to be slightly more efficient
180 :     <li> <code>DIV</code> bug in mltree-simplify fixed (found by Fermin)
181 :     </ol>
182 :     <p>
183 :     <li> Assembly Output
184 :     <ol type="a">
185 :     <li> When generating assemby, resolve the value of client defined constants,
186 :     instead of generating symbolic values. This is controlled by the
187 :     new flag "asm-resolve-constants", which is default to true.
188 :     <li> Added a new flag
189 :     <blockquote>
190 :     <code>asm-indent-copies</code> (default to false)
191 :     </blockquote>
192 :     When this flag is on, parallel copies will be indented an extra level.
193 :     <li> Machine Descriptions/Generation
194 :     <ol type="i">
195 :     <li> The precedence parser was slightly broken when parsing infixr symbols.
196 :     <li> The type generalizing code had the bound variables reversed, resulting
197 :     in a problem during arity raising.
198 :     <li> Various fixes in machine descriptions.
199 :     </ol>
200 :     </ol>
201 :     </ol>
202 :     <h3> CPS->MLRISC Code Generation </h3>
203 :     <p>
204 :     This release contains *MAJOR* changes to the way code is generated from CPS
205 :     in the module mlriscGen, and in various backend modules.
206 :     <p>
207 :     <ol>
208 :     <li> <strong>Forward propagation fix</strong>.
209 :     <p>
210 :     There was a bug in forward propagation introduced at about the same time
211 :     as the MLRISC x86 backend, which prohibits coalescing to be
212 :     performed effectively in loops.
213 :     <p>
214 :     Effect: speed up of loops in RISC architectures.
215 :     By itself, this actually slowed down certain benchmarks on the x86.
216 :     <p>
217 :     <li> <strong>Forward propagating addresses from consing</strong>.
218 :     <p>
219 :     I've changed the way consing code is generated. Basically I separated
220 :     out the initialization part:
221 :     <pre>
222 :     store tag, offset(allocptr)
223 :     store elem1, offset+4(allocptr)
224 :     store elem2, offset+8(allocptr)
225 :     ...
226 :     store elemn, offset+4n(allocptr)
227 :     </pre>
228 :     and the address computation part:
229 :     <pre>
230 :     celladdr <- offset+4+alloctpr
231 :     </pre>
232 :     and move the address computation part
233 :     <p>
234 :     Effect: register pressure is generally lower as a result. This
235 :     makes compilation of certain expressions much faster, such as
236 :     long lists with non-trivial elements.
237 :     <pre>
238 :     [(0,0), (0,0), .... (0,0)]
239 :     </pre>
240 :     <p>
241 :     <li> <strong>Base pointer elimination</strong>.
242 :     <p>
243 :     As part of the linkage mechanism, we generate the sequence:
244 :     <pre>
245 :     L: ... <- start of the code fragment
246 :    
247 :     L1:
248 :     base pointer <- linkreg - L1 + L
249 :     </pre>
250 :     The base pointer was then used for computing relocatable addresses
251 :     in the code fragment. Frequently (such as in lots of continuations)
252 :     this is not needed. We now eliminate this sequence whenever possible.
253 :     <p>
254 :     For compile time efficiency, I'm using a very stupid local heuristic.
255 :     But in general, this should be done as a control flow analysis.
256 :     <p>
257 :     Effect: Smaller code size. Speed up of most programs.
258 :     <p>
259 :     <li> <strong>Frequency annotations</strong>.
260 :     <p>
261 :     I've added an annotation that states that all call gc blocks have zero
262 :     execution frequencies. This improves register allocation on the x86.
263 :     </ol>
264 :     <p>
265 :     <h3> Aliasing </h3>
266 :     <p>
267 :     This update contains a rewritten (and hopefully more correct) module
268 :     for extracting aliasing information from CPS.
269 :     <p>
270 :     To turn on this feature:
271 :     <pre>
272 :     Compiler.Control.CG.memDisambiguate := true
273 :     </pre>
274 :     To pretty print the region information with assembly
275 :     <pre>
276 :     Compiler.Control.MLRISC.getFlag "asm-show-region" := true;
277 :     </pre>
278 :     To control how many levels of aliasing information are printed, use:
279 :     <pre>
280 :     Compiler.Control.MLRISC.getInt "points-to-show-level" := n
281 :     </pre>
282 :     The default value of n is 3.
283 :    
284 :     <h3> Benchmarks </h3>
285 :     <p>
286 :     I've only performed the comparison with 110.25.
287 :     <p>
288 :     The platforms are:
289 :     <pre>
290 :     HPPA A four processor HP machine (E9000) with 5G of memory.
291 :     X86 A 300Hhz Pentium II with 128M of memory, and
292 :     SPARC An Ultra sparc 2 with 512M of memory.
293 :     </pre>
294 :     I used the following parameters for the SML benchmarks:
295 :     <pre>
296 :     @SMLalloc
297 :     HPPA 256k
298 :     SPARC 512k
299 :     X86 256k
300 :     </pre>
301 :     <p>
302 :     <h4> COMPILATION TIME </h4>
303 :     <p>
304 :     Here are the numbers comparing the compilation times of the compilers.
305 :     I've only compared 110.25 compiling the new sources versus
306 :     a fixpoint version of the new compiler compiling the same.
307 :     <pre>
308 :     110.25 New
309 :     Total Time in RA Spill+Reload Total Time In RA Spill+Reload
310 :     HPPA 627s 116s 2684+3584 599s 95s 1003+1879
311 :     SPARC 892s 173s 2891+3870 708s 116s 1004+1880
312 :     X86 999s 315s 94006+130691 987s 296s 108877+141957
313 :    
314 :     110.25 New
315 :     Code Size Code Size
316 :     HPPA 8596736 8561421
317 :     SPARC 8974299 8785143
318 :     X86 9029180 8716783
319 :     </pre>
320 :     So in summary, things are at least as good as before. Dramatic
321 :     reduction in compilation is obtained on the Sparc; I can't explain it,
322 :     but it is reproducible. Perhaps someone should try to reproduce this
323 :     on their own machines.
324 :    
325 :     <h4> SML BENCHMARKS </h4>
326 :     <p>
327 :     On the average, all benchmarks perform at least as well as before.
328 :     <pre>
329 :     HPPA Compilation Time Spill+Reload Run Time
330 :     110.25 New 110.25 New 110.25 New
331 :    
332 :     barnesHut 3.158 3.015 4.75% 1+1 0+0 2.980 2.922 2.00%
333 :     boyer 6.152 5.708 7.77% 0+0 0+0 0.218 0.213 2.34%
334 :     count-graphs 1.168 1.120 4.32% 0+0 0+0 22.705 23.073 -1.60%
335 :     fft 0.877 0.792 10.74% 1+3 1+3 0.602 0.587 2.56%
336 :     knuthBendix 3.180 2.857 11.32% 0+0 0+0 0.675 0.662 2.02%
337 :     lexgen 6.190 5.290 17.01% 0+0 0+0 0.913 0.788 15.86%
338 :     life 0.803 0.703 14.22% 25+25 0+0 0.153 0.140 9.52%
339 :     logic 2.048 2.007 2.08% 6+6 1+1 4.133 4.008 3.12%
340 :     mandelbrot 0.077 0.080 -4.17% 0+0 0+0 0.765 0.712 7.49%
341 :     mlyacc 22.932 20.937 9.53% 154+181 32+57 0.468 0.430 8.91%
342 :     nucleic 5.183 5.060 2.44% 2+2 0+0 0.125 0.120 4.17%
343 :     ratio-regions 3.357 3.142 6.84% 0+0 0+0 116.225 113.173 2.70%
344 :     ray 1.283 1.290 -0.52% 0+0 0+0 2.887 2.855 1.11%
345 :     simple 6.307 6.032 4.56% 28+30 5+7 3.705 3.658 1.28%
346 :     tsp 0.888 0.862 3.09% 0+0 0+0 7.040 6.893 2.13%
347 :     vliw 24.378 23.455 3.94% 106+127 25+45 2.758 2.707 1.91%
348 :     --------------------------------------------------------------------------
349 :     Average 6.12% 4.09%
350 :    
351 :     SPARC Compilation Time Spill+Reload Run Time
352 :     110.25 New 110.25 New 110.25 New
353 :    
354 :     barnesHut 3.778 3.592 5.20% 2+2 0+0 3.648 3.453 5.65%
355 :     boyer 6.632 6.110 8.54% 0+0 0+0 0.258 0.242 6.90%
356 :     count-graphs 1.435 1.325 8.30% 0+0 0+0 33.672 34.737 -3.07%
357 :     fft 0.980 0.940 4.26% 3+9 2+6 0.838 0.827 1.41%
358 :     knuthBendix 3.590 3.138 14.39% 0+0 0+0 0.962 0.967 -0.52%
359 :     lexgen 6.593 6.072 8.59% 1+1 0+0 1.077 1.078 -0.15%
360 :     life 0.972 0.868 11.90% 26+26 0+0 0.143 0.140 2.38%
361 :     logic 2.525 2.387 5.80% 7+7 1+1 5.625 5.158 9.05%
362 :     mandelbrot 0.090 0.093 -3.57% 0+0 0+0 0.855 0.728 17.39%
363 :     mlyacc 26.732 23.827 12.19% 162+189 32+57 0.550 0.560 -1.79%
364 :     nucleic 6.233 6.197 0.59% 3+3 0+0 0.163 0.173 -5.77%
365 :     ratio-regions 3.780 3.507 7.79% 0+0 0+0 133.993 131.035 2.26%
366 :     ray 1.595 1.550 2.90% 1+1 0+0 3.440 3.418 0.63%
367 :     simple 6.972 6.487 7.48% 29+32 5+7 3.523 3.525 -0.05%
368 :     tsp 1.115 1.063 4.86% 0+0 0+0 7.393 7.265 1.77%
369 :     vliw 27.765 24.818 11.87% 110+135 25+45 2.265 2.135 6.09%
370 :     ----------------------------------------------------------------------------
371 :     Average 6.94% 2.64%
372 :    
373 :     X86 Compilation Time Spill+Reload Run Time
374 :     110.25 New 110.25 New 110.25 New
375 :    
376 :     barnesHut 5.530 5.420 2.03% 593+893 597+915 3.532 3.440 2.66%
377 :     boyer 8.768 7.747 13.19% 493+199 301+289 0.327 0.297 10.11%
378 :     count-graphs 2.040 2.010 1.49% 298+394 315+457 26.578 28.660 -7.26%
379 :     fft 1.327 1.302 1.92% 112+209 115+210 1.055 0.962 9.71%
380 :     knuthBendix 5.218 5.475 -4.69% 451+598 510+650 0.928 0.932 -0.36%
381 :     lexgen 9.970 9.623 3.60% 1014+841 1157+885 0.947 0.928 1.97%
382 :     life 1.183 1.183 0.00% 162+182 145+148 0.127 0.103 22.58%
383 :     logic 3.285 3.512 -6.45% 514+684 591+836 5.682 5.577 1.88%
384 :     mandelbrot 0.147 0.143 2.33% 38+41 33+54 0.703 0.690 1.93%
385 :     mlyacc 35.457 32.763 8.22% 3496+4564 3611+4860 0.552 0.550 0.30%
386 :     nucleic 7.100 6.888 3.07% 239+168 201+158 0.175 0.173 0.96%
387 :     ratio-regions 6.388 6.843 -6.65% 1182+257 981+300 120.142 120.345 -0.17%
388 :     ray 2.332 2.338 -0.29% 346+398 402+494 3.593 3.540 1.51%
389 :     simple 9.912 9.903 0.08% 1475+941 1579+1168 3.057 3.178 -3.83%
390 :     tsp 1.623 1.532 5.98% 266+200 250+211 8.045 7.878 2.12%
391 :     vliw 33.947 35.470 -4.29% 2629+2774 2877+3171 2.072 1.890 9.61%
392 :     ----------------------------------------------------------------------------
393 :     Average 1.22% 3.36%
394 :     </pre>
395 :    
396 :    
397 :     <hr>
398 :     <center><h3> Boot code and glue scripts </h3></center>
399 :    
400 :     <h4> Size info in BOOTLIST </h4>
401 :     <p>
402 :     The BOOTLIST file now has an optional first line that specifies an
403 :     upper bound on the number of boot files and an upper bound on the
404 :     length of each individual name. With this, there are no longer
405 :     hard-wired restrictions on these values in the runtime system.
406 :     (If the specification is missing in BOOTLIST, the runtime system
407 :     falls back to its old behavior, i.e., hard-wired defaults.)
408 :     <p>
409 :     <h4> Allocation-size heuristics in .run-sml </h4>
410 :     <p>
411 :     The .run-sml scripts tries to read processor cache size from
412 :     /proc/cpuinfo. This works on Linux and is important for small-cache
413 :     Celeron systems that suffer badly when allocation size is set too
414 :     high.
415 :     <p>
416 :     <h4> Install script </h4>
417 :     <p>
418 :     <ul>
419 :     <li> Written in a more modular fashion (using shell functions).
420 :     <li> Made more robust.
421 :     <li> Automagically fetches archive files over the network if they do not
422 :     exist locally. Thus, you only need to fetch config.tar.gz yourself.
423 :     Unpack it and go!
424 :     (Requires "wget" or "lynx" to be installed on the system and a
425 :     live connection to the internet. Moreover, the contents of
426 :     config/srcarchiveurl must be set properly.)
427 :     For CVS users, this may be convenient when fetching new sets of binfiles.
428 :     <li> Handles archive files with or without version number and compressed
429 :     with one of "gzip", "compress", or "bzip2". Recognized suffixes are
430 :     ".tar.gz", ".tgz", ".tar", ".tar.Z", and ".tar.bz2".
431 :     </ul>
432 :     <p>
433 :     <h4> PIDMAP file </h4>
434 :     <p>
435 :     There is a file called PIDMAP in the bootfile directory.
436 :     It is used to minimize the amount of dynamic state that needs to be
437 :     stowed away for the purpose of sharing between interactive system
438 :     and user code.
439 :     <p>
440 :     <h4> Building standalone programs </h4>
441 :     <p>
442 :     The command ml-build can be used to build standalone programs.
443 :     ml-build takes three arguments:
444 :     <ol>
445 :     <li> the name of the CM library that implements and exports the "main"
446 :     function of your program
447 :     <li> the name of the "main" function of your program as exported by 1.
448 :     (The function must have a type that makes it suitable as an argument
449 :     to SMLofNJ.exportFn.)
450 :     <li> the name of the heapfile to be generated
451 :     </ol>
452 :     <h4> Other build scripts </h4>
453 :     <p>
454 :     ml-{lex,yacc} build scripts now make use of the new mechanism for
455 :     building standalone programs.
456 :     <p>
457 :     <h4> Fixpoint script </h4>
458 :     <p>
459 :     I added a re-written version of Dave's fixpt script to src/system.
460 :     Changes relative to the original version:
461 :     <p>
462 :     <ul>
463 :     <li> sh-ified (not everybody has ksh)
464 :     <li> automatically figures out which architecture it runs on
465 :     <li> uses ./makeml a bit more cleverly
466 :     <li> never invokes ./installml (and, thus, does not clobber your
467 :     good and working installation of sml in case something goes wrong)
468 :     <li> accepts max iteration count using option "-iter <n>"
469 :     <li> accepts a "base" name using option "-base <base>"
470 :     </ul>
471 :     <p>
472 :     It does not build any extraneous heap images but directly rebuilds
473 :     bin- and boot-hierarchies using makeml's "-rebuild" switch. Finally,
474 :     it can incorporate existing bin- and boot- hierarchies. For example,
475 :     suppose the base is set to "sml" (which is the default). Then it
476 :     successively builds
477 :     <pre>
478 :     sml.bin.&lt;arch&gt;-unix and sml.boot.&lt;arch&gt;-unix
479 :     then sml1.bin.&lt;arch&gt;-unix and sml1.boot.&lt;arch&gt;-unix
480 :     then sml2.bin.&lt;arch&gt;-unix and sml2.boot.&lt;arch&gt;-unix
481 :     ...
482 :     then sml&lt;n&gt;.bin.&lt;arch&gt;-unix and sml&lt;n&gt;.boot.&lt;arch&gt;-unix
483 :     </pre>
484 :     and so on. If any of these already exist, it will just use what's
485 :     there. In particular, many people will have the initial set of bin
486 :     and boot files around, so this saves time for at least one full
487 :     rebuild. Having sets of the form &lt;base&gt;&lt;k&gt;.{bin,boot}.&lt;arch&gt;-unix for
488 :     &lt;k&gt;=1,2,... is normally not a good idea when invoking fixpt. However,
489 :     they might be the result of an earlier partial run of fixpt (which
490 :     perhaps got accidentially killed). In this case, fixpt will quickly
491 :     move through what exists before continuing where it left off earlier,
492 :     and, thus, saves a lot of time.
493 :     <p>
494 :     <h4> Runtime system code </h4>
495 :     <p>
496 :     <ul>
497 :     <li> fixed several gcc -Wall warnings that were caused by missing header
498 :     files, missing initializations, etc., in runtime (not all warnings
499 :     eliminated, though)
500 :     <li> had to "un-fix" some of them later because they broke the HPPA compile
501 :     </ul>
502 :     <p>
503 :     <hr>
504 :     <center><h3> CM </h3></center>
505 :     <p>
506 :     <h4> Several manual updates </h4>
507 :     <p>
508 :     I always try to keep the manual in sync with CM's latest features.
509 :     <p>
510 :     <h4> Bootstrap compilation </h4>
511 :     <p>
512 :     No more "CMB.deliver"
513 :     <p>
514 :     <ul>
515 :     <li> All work is done by CMB.make (as it used to be in the old CM).
516 :     <li> CMB.make can be used even with existing bootfiles, i.e., bootfiles do
517 :     not have to be removed beforehand.
518 :     <li> In "paranoid mode" CM checks a stable libraries CRC checksum to
519 :     verify that it is "valid". (In "normal mode", such checks do not
520 :     occur.) Paranoid mode is used for bootstrap compilation. This is
521 :     what makes it possible to re-use existing bootfiles.
522 :     </ul>
523 :     <p>
524 :     <h4> Initial glue code (init.cmi) </h4>
525 :     <ul>
526 :     <li> treated as a genuine library now
527 :     <li> there are no more "built-in" modules
528 :     </ul>
529 :     <p>
530 :     <h4> CM API </h4>
531 :     <p>
532 :     <ol>
533 :     <li> CM.Anchor.anchor instead of CM.Anchor.{set,cancel}
534 :     <ul>
535 :     <li>Upon request by Elsa. Anchors now controlled by get-set-pair
536 :     like most other CM state variables.
537 :     </ul>
538 :     <p>
539 :     <li> CM tools:
540 :     <ul>
541 :     <li> It is now possible to have tools that accept additional
542 :     "command line" parameters (specified in the .cm file at each
543 :     instance where the tool's class is used).
544 :     <li> The parser understands named parameters and recursive options.
545 :     <li> new "make" and "shell" tools added to facilitate fairly seemless
546 :     hookup to portions of code managed using Makefiles or Shell scripts.
547 :     <li> There are no classes "shared" or "private" anymore. Instead,
548 :     the sharing annotation is now a parameter to the "sml" class.
549 :     <li> Tools.registerStdShellCmdTool (from smlnj/cm/tool.cm) takes an
550 :     additional argument called "template" which is an optional
551 :     string that specifiel the layout of the tool command line. See
552 :     the CM manual for explanation.
553 :     <li> A special-purpose tool can be "registered" by simply dropping
554 :     the corresponding &lt;...&gt;-tool.cm (and/or &lt;...&gt;-ext.cm) into the
555 :     same directory where the .cm file lives that uses this tool.
556 :     (The behavior/misfeature until now was to look for the tool
557 :     description files in the current working directory.) As
558 :     before, tool description files could also be anchored -- in
559 :     which case they can live anywhere they like. Following the
560 :     recent e-mail discussion, this change should make it easier to
561 :     have special-purpose tools that are shipped together with the
562 :     sources of the program that uses them.
563 :     <strong>Bug</strong>: such a tool does not get un-registered after being done.
564 :     </ul>
565 :     </ol>
566 :     <p>
567 :     <h4> Library names </h4>
568 :     <p>
569 :     Library names have been completely re-organized.
570 :     Many libraries have been consolidated so that they share the same
571 :     path anchor. For example, all MLRISC-related libraries are
572 :     anchored at MLRISC, most libraries that are SML/NJ-specific are
573 :     under "smlnj". Notice that names like host-cmb.cm or
574 :     host-compiler.cm no longer exist. See system/README for a
575 :     complete description of the new naming scheme. Quick reference:
576 :     <pre>
577 :     host-cmb.cm -&gt; smlnj/cmb.cm
578 :     host-compiler.cm -&gt; smlnj/compiler.cm
579 :     full-cm.cm -&gt; smlnj/cm.cm
580 :     &lt;arch&gt;-&lt;os&gt;.cm -&gt; smlnj/cmb/&lt;arch&gt;-&lt;os&gt;.cm
581 :     &lt;arch&gt;-compiler.cm -&gt; smlnj/compiler/&lt;arch&gt;.cm
582 :     </pre>
583 :     <p>
584 :     <h4> CM bug fixes </h4>
585 :     <ul>
586 :     <li> exceptions in user code are being passed through (i.e., reach top level)
587 :     <li> more bugs in paranoia mode fixed
588 :     <li> bug related to checking group owners fixed
589 :     <li> better error handling (suppresses many followup-messages)
590 :     </ul>
591 :     <p>
592 :     <h4> Internals </h4>
593 :     <p>
594 :     <dl>
595 :     <dt>"Global" modmap:
596 :     <dd>CM now maintains one "global" modmap that is used for all stable
597 :     libraries. The use of such a global modmap maximizes sharing and
598 :     minimizes the need for re-traversing parts of environments during
599 :     modmap construction. (However, this has minor impact since modmap
600 :     construction seems to account for just one percent or less of total
601 :     compile time.)
602 :     </dl>
603 :     <p>
604 :    
605 :     <hr>
606 :     <center><h3> Compiler Internals </h3></center>
607 :     <h4> Environment data structures: No more <code>CMStaticEnv</code> </h4>
608 :     <ul>
609 :     <li> no <code>CMEnv</code>, no <code>BareEnvironment</code> (actually,
610 :     <em>only</em> <code>BareEnvironment</code>,
611 :     but it is called <code>Environment</code>), no conversions between different
612 :     kinds of static environments.
613 :     <p>
614 :     <li> There is still a notion of a "modmap", but such modmaps are generated
615 :     on demand at the time when they are needed. This sounds slow, but I
616 :     sped up the code that generates modmaps enough for this not to lead to
617 :     a slowdown of the compiler (at least I didn't detect any).
618 :     <p>
619 :     <li> To facilitate rapid modmap generation, static environments now
620 :     contain an (optional) "modtree" structure. Modtree annotations are
621 :     constructed by the unpickler during unpickling. (This means that
622 :     the elaborator does not have to worry about modtrees at all.)
623 :     Modtrees have the advantage that they are compositional in the same
624 :     way as the environment data structure itself is compositional.
625 :     As a result, modtrees never hang on to parts of an environment that
626 :     has already been rendered "stale" by filtering or rebinding.
627 :     <p>
628 :     <li> all files that I touched now compile without warnings (other than
629 :     "polyEqual" warnings).
630 :     <p>
631 :     <li> compiler now tends to run "leaner" (i.e., ties up less memory in
632 :     redundant modmaps)
633 :     </ul>
634 :     <p>
635 :     <h4> Stats phase "genmap" added </h4>
636 :     <ul>
637 :     <li>It measures time spent during on-the-fly modmap generation.
638 :     </ul>
639 :     <p>
640 :     <h4> Changes on behalf of CM </h4>
641 :     <p>
642 :     <ul>
643 :     <li><code>Compiler.CMSA</code> eliminated
644 :     <p>
645 :     No longer supported by CM anyway.
646 :     <p>
647 :     <li> Fixed bugs in pickler that kept biting Stefan
648 :     <ul>
649 :     <li> past refs to past refs (was caused by the possibility that
650 :     ad-hoc sharing is more discriminating than hash-cons sharing)
651 :     <li> integer overflow on LargeInt.minInt
652 :     </ul>
653 :     <p>
654 :     <li> Handling of "core" environment
655 :     <p>
656 :     I eliminated coreEnv from compInfo. Access to the <code>Core</code>
657 :     structure is now done via the ordinary static environment that is
658 :     context to each compilation unit.
659 :     <p>
660 :     To this end, I arranged that instead of "structure Core" a
661 :     "structure _Core" is bound in the pervasive environment. Core
662 :     access is done via _Core (which can never be accidentially rebound
663 :     because _Core is not a legal surface-syntax symbol).
664 :     <p>
665 :     The current solution is much cleaner because the core environment
666 :     is now simply part of the pervasive environment which is part of
667 :     every compilation unit's context anyway. In particular, this
668 :     eliminates all special-case handling that was necessary until now
669 :     in order to deal with dynamic and symbolic parts of the core
670 :     environment.
671 :     <p>
672 :     Remaining hackery (to bind the "magic" symbol <code>_Core</code>) is localized
673 :     in the compilation mananger's bootstrap compiler (actually: in the
674 :     "init group" handling). See the comments in
675 :     src/system/smlnj/init/init.cmi for more details.
676 :     <p>
677 :     I also tried to track down all mentions of <code>"Core"</code> (as string
678 :     argument to Symbol.strSymbol) in the compiler and replaced them
679 :     with a reference to the new <code>CoreSym.coreSym</code>. Seems cleaner since
680 :     the actual name appears in one place only.
681 :     </ul>
682 :     <p>
683 :    
684 :     <hr>
685 :    
686 :     <font size=-2>
687 :     <address><a href="mailto:george@research.bell-labs.com">
688 :     Lal George</a></address>
689 :     <!-- Created: Thu Aug 6 00:13:09 EDT 1998 -->
690 :     <!-- hhmts start -->
691 :     Last modified: Wed Apr 19 16:24:39 EDT 2000
692 :     <!-- hhmts end -->
693 :     </font>
694 :     </blockquote>
695 :     </body>
696 :     </html>

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