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 576, Fri Mar 10 07:27:16 2000 UTC revision 605, Fri Apr 7 14:06:42 2000 UTC
# Line 12  Line 12 
12  Tag: <post-commit CVS tag>  Tag: <post-commit CVS tag>
13  Description:  Description:
14  ----------------------------------------------------------------------  ----------------------------------------------------------------------
15    Name: Stefan
16    Date: 2000/04/07 10:00:00 EDT
17    Tag: monnier-20000406-branch-handling
18    Description:
19    
20    Improved handling of branches (mostly those generated from
21    polymorphic equality), removed switchoff and changed the
22    default optimization settings (more cpsopt and less flintopt).
23    
24    ----------------------------------------------------------------------
25    Name: Allen Leung
26    Date: 2000/04/06 01:30:00 EST
27    Tag: leunga-20000406-peephole-x86-SSA-2
28    Description:
29    
30       Forgot a few files.
31    
32    ----------------------------------------------------------------------
33    Name: Allen Leung
34    Date: 2000/04/06 00:36:00 EST
35    Tag: leunga-20000406-peephole-x86-SSA
36    Description:
37    
38    1.  New Peephole code
39    
40    2.  Minor improvement to X86 instruction selection
41    
42    3.  Various fixes to SSA and machine description -> code translator
43    
44    ----------------------------------------------------------------------
45    Name: Matthias Blume
46    Date: 2000/04/05 12:30:00 JST
47    Tag: blume_main_v110p26p2_3
48    Description:
49    
50    This update just merges three minor cosmetic updates to CM's sources
51    to get ready for the 110.27 code freeze on Friday.  No functionality
52    has changed.
53    
54    ----------------------------------------------------------------------
55    Name: Allen Leung
56    Date: 2000/04/04 19:39:00 EST
57    Tag: leunga-20000404-x86-asm
58    Description:
59    
60    1.  Fixed a problem in X86 assembly.
61    
62        Things like
63    
64           jmp %eax
65           jmp (%eax)
66    
67        should be output as
68    
69           jmp *%eax
70           jmp *(%eax)
71    
72    2.  Assembly output
73    
74          Added a new flag
75    
76              "asm-indent-copies" (default to false)
77    
78          When this flag is on, parallel copies will be indented an extra level.
79    
80    ----------------------------------------------------------------------
81    Name: Allen Leung
82    Date: 2000/04/04 03:18:00 EST
83    Tag: leunga-20000404-C--Moby
84    Description:
85    
86        All of these fixes are related to C--, Moby, and my own optimization
87        stuff; so they shouldn't affect SML/NJ.
88    
89    1.  X86
90    
91        Various fixes related floating point, and extensions.
92    
93    2.  Alpha
94    
95        Some extra patterns related to loads with signed/zero extension
96        provided by Fermin.
97    
98    3.  Assembly
99    
100        When generating assemby, resolve the value of client defined constants,
101        instead of generating symbolic values.  This is controlled by the
102        new flag "asm-resolve-constants", which is default to true.
103    
104    4.  Machine Descriptions
105    
106        a. The precedence parser was slightly broken when parsing infixr symbols.
107        b. The type generalizing code had the bound variables reversed, resulting
108           in a problem during arity raising.
109        c. Various fixes in machine descriptions.
110    
111    ----------------------------------------------------------------------
112    Name: Matthias Blume
113    Date: 2000/04/03 16:05:00 JST
114    Tag: blume_main_v110p26p2_2
115    Description:
116    
117    I eliminated coreEnv from compInfo.  Access to the "Core" structure is
118    now done via the ordinary static environment that is context to each
119    compilation unit.
120    
121    To this end, I arranged that instead of "structure Core" as "structure
122    _Core" is bound in the pervasive environment.  Core access is done via
123    _Core (which can never be accidentially rebound because _Core is not a
124    legal surface-syntax symbol).
125    
126    The current solution is much cleaner because the core environment is
127    now simply part of the pervasive environment which is part of every
128    compilation unit's context anyway.  In particular, this eliminates all
129    special-case handling that was necessary until now in order to deal
130    with dynamic and symbolic parts of the core environment.
131    
132    Remaining hackery (to bind the "magic" symbol _Core) is localized in the
133    compilation mananger's bootstrap compiler (actually: in the "init group"
134    handling).  See the comments in src/system/smlnj/init/init.cmi for
135    more details.
136    
137    I also tried to track down all mentions of "Core" (as string argument
138    to Symbol.strSymbol) in the compiler and replaced them with a
139    reference to the new CoreSym.coreSym.  Seems cleaner since the actual
140    name appears in one place only.
141    
142    Binfile and bootfile format have not changed, but the switchover from
143    the old "init.cmi" to the new one is a bit tricky, so I supplied new
144    bootfiles anyway.
145    
146    ----------------------------------------------------------------------
147    Name: Allen Leung
148    Date: 2000/04/02 21:17:00 EST
149    Tag: leunga-20000402-mltree
150    Description:
151    
152       1. Renamed the constructor CALL in MLTREE by popular demand.
153       2. Added a bunch of files from my repository.  These are currently
154          used by other non-SMLNJ backends.
155    
156    ----------------------------------------------------------------------
157    Name: Allen Leung
158    Date: 2000/03/31 21:15:00 EST
159    Tag: leunga-20000331-aliasing
160    Description:
161    
162    This update contains a rewritten (and hopefully more correct) module
163    for extracting aliasing information from CPS.
164    
165       To turn on this feature:
166    
167            Compiler.Control.CG.memDisambiguate := true
168    
169       To pretty print the region information with assembly
170    
171           Compiler.Control.MLRISC.getFlag "asm-show-region" := true;
172    
173       To control how many levels of aliasing information are printed, use:
174    
175           Compiler.Control.MLRISC.getInt "points-to-show-level" := n
176    
177       The default of n is 3.
178    
179    ----------------------------------------------------------------------
180    Name: David MacQueen
181    Date: 2000/03/31 11:15:00 EST
182    Tag: dbm-20000331-runtime_fix
183    Description:
184    
185    This update contains:
186    
187    1. runtime/c-lib/c-libraries.c
188       includes added in revision 1.2 caused compilation errors on hppa-hpux
189    
190    2. fix for bug 1556
191       system/Basis/Implementation/NJ/internal-signals.sml
192    
193    ----------------------------------------------------------------------
194    Name: Matthias Blume
195    Date: 2000/03/31 18:00:00 JST
196    Tag: blume_main_v110p26p2_1
197    Description:
198    
199    This update contains:
200    
201    1. A small change to CM's handling of stable libraries:
202       CM now maintains one "global" modmap that is used for all stable
203       libraries.  The use of such a global modmap maximizes sharing and
204       minimizes the need for re-traversing parts of environments during
205       modmap construction.  (However, this has minor impact since modmap
206       construction seems to account for just one percent or less of total
207       compile time.)
208    
209    2. I added a "genmap" phase to the statistics.  This is where I got the
210       "one percent" number (see above).
211    
212    3. CM's new tool parameter mechanism just became _even_ better. :)
213       - The parser understands named parameters and recursive options.
214       - The "make" and "shell" tools use these new features.
215         (This makes it a lot easier to cascade these tools.)
216       - There is a small syntax change: named parameters use a
217    
218           <name> : ( <option> ... )            or
219           <name> : <string>
220    
221         syntax.  Previously, named parameters were implemented in an
222         ad-hoc fashion by each tool individually (by parsing strings)
223         and had the form
224    
225           <name>=<string>
226    
227       See the CM manual for a full description of these issues.
228    
229    ----------------------------------------------------------------------
230    Name: Matthias Blume
231    Date: 2000/03/30 18:00:00 JST
232    Tag: blume_main_v110p26p2_0
233    Description:
234    
235    !!!!! WARNING !!!!!!
236    !!  New binfiles  !!
237    !!!!!!!!!!!!!!!!!!!!
238    
239    This update contains:
240    
241    1. Moderate changes to CM:
242    
243       - Changes to CM's tools mechanism.  In particular, it is now possible
244       to have tools that accept additional "command line" parameters
245       (specified in the .cm file at each instance where the tool's class is
246       used).
247    
248       This was done to accomodate the new "make" and "shell" tools which
249       facilitate fairly seemless hookup to portions of code managed using
250       Makefiles or Shell scripts.
251    
252       There are no classes "shared" or "private" anymore.  Instead, the
253       sharing annotation is now a parameter to the "sml" class.
254    
255       There is a bit of generic machinery for implementing one's own
256       tools that accept command-line parameters.  However, I am not yet fully
257       satisfied with that part, so expect changes here in the future.
258    
259       All existing tools are described in the CM manual.
260    
261       - Slightly better error handling.  (CM now surpresses many followup
262       error messages that tended to be more annoying than helpful.)
263    
264    2. Major changes to the compiler's static environment data structures.
265    
266       - no CMStaticEnv anymore.
267            - no CMEnv, no "BareEnvironment" (actually, _only_ BareEnvironment,
268              but it is called Environment), no conversions between different
269              kinds of static environments
270    
271       - There is still a notion of a "modmap", but such modmaps are generated
272         on demand at the time when they are needed.  This sounds slow, but I
273         sped up the code that generates modmaps enough for this not to lead to
274         a slowdown of the compiler (at least I didn't detect any).
275    
276       - To facilitate rapid modmap generation, static environments now
277         contain an (optional) "modtree" structure.  Modtree annotations are
278         constructed by the unpickler during unpickling.  (This means that
279         the elaborator does not have to worry about modtrees at all.)
280         Modtrees have the advantage that they are compositional in the same
281         way as the environment data structure itself is compositional.
282         As a result, modtrees never hang on to parts of an environment that
283         has already been rendered "stale" by filtering or rebinding.
284    
285       - I went through many, many trials and errors before arriving at the
286         current solution.  (The initial idea of "linkpaths" did not work.)
287         But the result of all this is that I have touched a lot of files that
288         depend on the "modules" and "types" data structures (most of the
289         elaborator). There were a lot of changes during my "linkpath" trials
290         that could have been reverted to their original state but weren't.
291         Please, don't be too harsh on me for messing with this code a bit more
292         than what was strictly necessary...  (I _did_ resist the tempation
293         of doing any "global reformatting" to avoid an untimely death at
294         Dave's hands. :)
295    
296       - One positive aspect of the previous point:  At least I made sure that
297         all files that I touched now compile without warnings (other than
298         "polyEqual").
299    
300       - compiler now tends to run "leaner" (i.e., ties up less memory in
301         redundant modmaps)
302    
303    ----------------------------------------------------------------------
304    Name: Allen Leung
305    Date: 2000/03/29 18:00:00
306    Tag: leunga-20000327-mlriscGen_hppa_alpha_x86
307    Boot files (optional): ftp://react-ilp.cs.nyu.edu/leunga/110.26.1-sml.boot.x86-unix-20000330.tar.gz
308    Description:
309    
310       This update contains *MAJOR* changes to the way code is generated from CPS
311    in the module mlriscGen, and in various backend modules.
312    
313    CHANGES
314    =======
315    
316    1. MLRiscGen: forward propagation fix.
317    
318       There was a bug in forward propagation introduced at about the same time
319       as the MLRISC x86 backend, which prohibits coalescing to be
320       performed effectively in loops.
321    
322       Effect: speed up of loops in RISC architectures.
323               By itself, this actually slowed down certain benchmarks on the x86.
324    
325    2. MLRiscGen:  forward propagating addresses from consing.
326    
327       I've changed the way consing code is generated.  Basically I separated
328       out the initialization part:
329    
330            store tag,   offset(allocptr)
331            store elem1, offset+4(allocptr)
332            store elem2, offset+8(allocptr)
333            ...
334            store elemn, offset+4n(allocptr)
335    
336       and the address computation part:
337    
338            celladdr <- offset+4+alloctpr
339    
340       and move the address computation part
341    
342       Effect:  register pressure is generally lower as a result.  This
343                makes compilation of certain expressions much faster, such as
344                long lists with non-trivial elements.
345    
346                 [(0,0), (0,0), .... (0,0)]
347    
348    3. MLRiscGen: base pointer elimination.
349    
350        As part of the linkage mechanism, we generate the sequence:
351    
352         L:  ...  <- start of the code fragment
353    
354         L1:
355             base pointer <- linkreg - L1 + L
356    
357         The base pointer was then used for computing relocatable addresses
358       in the code fragment.  Frequently (such as in lots of continuations)
359       this is not needed.  We now eliminate this sequence whenever possible.
360    
361         For compile time efficiency, I'm using a very stupid local heuristic.
362       But in general, this should be done as a control flow analysis.
363    
364       Effect:  Smaller code size.  Speed up of most programs.
365    
366    4. Hppa back end
367    
368         Long jumps in span dependence resolution used to depend on the existence
369      of the base pointer.
370    
371         A jump to a long label L was expanded into the following sequence:
372    
373          LDIL %hi(L-8192), %r29
374          LDO  %lo(L-8192)(%r29), %r29
375          ADD  %r29, baseptr, %r29
376          BV,n %r0(%r29)
377    
378         In the presence of change (3) above, this will not work.  I've changed
379       it so that the following sequence of instructions are generated, which
380       doesn't mention the base pointer at all:
381    
382             BL,n  L', %r29           /* branch and link, L' + 4 -> %r29 */
383        L':  ADDIL L-(L'+4), %r29     /* Compute address of L */
384             BV,n  %r0(%r29)          /* Jump */
385    
386    5. Alpha back end
387    
388          New alpha instructions LDB/LDW have been added, as per Fermin's
389       suggestions.   This is unrelated to all other changes.
390    
391    6. X86 back end
392    
393         I've changed andl to testl in the floating point test sequence
394         whenever appropriate.  The Intel optimization guide states that
395         testl is perferable to andl.
396    
397    7. RA (x86 only)
398    
399         I've improved the spill propagation algorithm, using an approximation
400       of maximal weighted independent sets.   This seems to be necessary to
401       alleviate the negative effect in light of the slow down in (1).
402    
403         I'll write down the algorithm one of these days.
404    
405    8. MLRiscGen: frequencies
406    
407         I've added an annotation that states that all call gc blocks have zero
408       execution frequencies.  This improves register allocation on the x86.
409    
410    BENCHMARKS
411    ==========
412    
413       I've only perform the comparison on 110.25.
414    
415       The platforms are:
416    
417        HPPA  A four processor HP machine (E9000) with 5G of memory.
418        X86   A 300Hhz Pentium II with 128M of memory, and
419        SPARC An Ultra sparc 2 with 512M of memory.
420    
421       I used the following parameters for the SML benchmarks:
422    
423                 @SMLalloc
424         HPPA    256k
425         SPARC   512k
426         X86     256k
427    
428    COMPILATION TIME
429    ----------------
430       Here are the numbers comparing the compilation times of the compilers.
431       I've only compared 110.25 compiling the new sources versus
432       a fixpoint version of the new compiler compiling the same.
433    
434                     110.25                                  New
435               Total  Time in RA  Spill+Reload   Total  Time In RA Spill+Reload
436         HPPA   627s    116s        2684+3584     599s    95s       1003+1879
437         SPARC  892s    173s        2891+3870     708s    116s      1004+1880
438         X86    999s    315s       94006+130691   987s    296s    108877+141957
439    
440                   110.25         New
441                Code Size      Code Size
442         HPPA   8596736         8561421
443         SPARC  8974299         8785143
444         X86    9029180         8716783
445    
446       So in summary, things are at least as good as before.   Dramatic
447       reduction in compilation is obtained on the Sparc; I can't explain it,
448       but it is reproducible.  Perhaps someone should try to reproduce this
449       on their own machines.
450    
451    SML BENCHMARKS
452    --------------
453    
454        On the average, all benchmarks perform at least as well as before.
455    
456          HPPA         Compilation Time     Spill+Reload      Run Time
457                     110.25  New            110.25    New   110.25  New
458    
459          barnesHut  3.158  3.015  4.75%    1+1       0+0   2.980  2.922   2.00%
460              boyer  6.152  5.708  7.77%    0+0       0+0   0.218  0.213   2.34%
461       count-graphs  1.168  1.120  4.32%    0+0       0+0  22.705 23.073  -1.60%
462                fft  0.877  0.792 10.74%    1+3       1+3   0.602  0.587   2.56%
463        knuthBendix  3.180  2.857 11.32%    0+0       0+0   0.675  0.662   2.02%
464             lexgen  6.190  5.290 17.01%    0+0       0+0   0.913  0.788  15.86%
465               life  0.803  0.703 14.22%   25+25      0+0   0.153  0.140   9.52%
466              logic  2.048  2.007  2.08%    6+6       1+1   4.133  4.008   3.12%
467         mandelbrot  0.077  0.080 -4.17%    0+0       0+0   0.765  0.712   7.49%
468             mlyacc 22.932 20.937  9.53%  154+181    32+57  0.468  0.430   8.91%
469            nucleic  5.183  5.060  2.44%    2+2       0+0   0.125  0.120   4.17%
470      ratio-regions  3.357  3.142  6.84%    0+0       0+0  116.225 113.173 2.70%
471                ray  1.283  1.290 -0.52%    0+0       0+0   2.887  2.855   1.11%
472             simple  6.307  6.032  4.56%   28+30      5+7   3.705  3.658   1.28%
473                tsp  0.888  0.862  3.09%    0+0       0+0   7.040  6.893   2.13%
474               vliw 24.378 23.455  3.94%  106+127    25+45  2.758  2.707   1.91%
475      --------------------------------------------------------------------------
476       Average                     6.12%                                   4.09%
477    
478          SPARC        Compilation Time     Spill+Reload      Run Time
479                     110.25  New            110.25    New   110.25  New
480    
481          barnesHut  3.778  3.592  5.20%    2+2       0+0   3.648  3.453    5.65%
482              boyer  6.632  6.110  8.54%    0+0       0+0   0.258  0.242    6.90%
483       count-graphs  1.435  1.325  8.30%    0+0       0+0  33.672 34.737   -3.07%
484                fft  0.980  0.940  4.26%    3+9       2+6   0.838  0.827    1.41%
485        knuthBendix  3.590  3.138 14.39%    0+0       0+0   0.962  0.967   -0.52%
486             lexgen  6.593  6.072  8.59%    1+1       0+0   1.077  1.078   -0.15%
487               life  0.972  0.868 11.90%   26+26      0+0   0.143  0.140    2.38%
488              logic  2.525  2.387  5.80%    7+7       1+1   5.625  5.158    9.05%
489         mandelbrot  0.090  0.093 -3.57%    0+0       0+0   0.855  0.728   17.39%
490             mlyacc 26.732 23.827 12.19%  162+189    32+57  0.550  0.560   -1.79%
491            nucleic  6.233  6.197  0.59%    3+3       0+0   0.163  0.173   -5.77%
492      ratio-regions  3.780  3.507  7.79%    0+0       0+0 133.993 131.035   2.26%
493                ray  1.595  1.550  2.90%    1+1       0+0   3.440  3.418    0.63%
494             simple  6.972  6.487  7.48%   29+32      5+7   3.523  3.525   -0.05%
495                tsp  1.115  1.063  4.86%    0+0       0+0   7.393  7.265    1.77%
496               vliw 27.765 24.818 11.87%  110+135    25+45  2.265  2.135    6.09%
497      ----------------------------------------------------------------------------
498       Average                     6.94%                                    2.64%
499    
500          X86          Compilation Time     Spill+Reload      Run Time
501                     110.25  New            110.25    New   110.25  New
502    
503          barnesHut  5.530  5.420  2.03%  593+893   597+915   3.532  3.440   2.66%
504              boyer  8.768  7.747 13.19%  493+199   301+289   0.327  0.297  10.11%
505       count-graphs  2.040  2.010  1.49%  298+394   315+457  26.578 28.660  -7.26%
506                fft  1.327  1.302  1.92%  112+209   115+210   1.055  0.962   9.71%
507        knuthBendix  5.218  5.475 -4.69%  451+598   510+650   0.928  0.932  -0.36%
508             lexgen  9.970  9.623  3.60% 1014+841  1157+885   0.947  0.928   1.97%
509               life  1.183  1.183  0.00%  162+182   145+148   0.127  0.103  22.58%
510              logic  3.285  3.512 -6.45%  514+684   591+836   5.682  5.577   1.88%
511         mandelbrot  0.147  0.143  2.33%   38+41     33+54    0.703  0.690   1.93%
512             mlyacc 35.457 32.763  8.22% 3496+4564 3611+4860  0.552  0.550   0.30%
513            nucleic  7.100  6.888  3.07%  239+168   201+158   0.175  0.173   0.96%
514      ratio-regions  6.388  6.843 -6.65% 1182+257   981+300  120.142 120.345 -0.17%
515                ray  2.332  2.338 -0.29%  346+398   402+494   3.593  3.540   1.51%
516             simple  9.912  9.903  0.08% 1475+941  1579+1168  3.057  3.178  -3.83%
517                tsp  1.623  1.532  5.98%  266+200   250+211   8.045  7.878   2.12%
518               vliw 33.947 35.470 -4.29% 2629+2774 2877+3171  2.072  1.890   9.61%
519      ----------------------------------------------------------------------------
520       Average                     1.22%                                     3.36%
521    
522    ----------------------------------------------------------------------
523    Name: Allen Leung
524    Date: 2000/03/23 16:25:00
525    Tag: leunga-20000323-fix_x86_alpha
526    Description:
527    
528    1. X86 fixes/changes
529    
530       a.  The old code generated for SETcc was completely wrong.
531           The Intel optimization guide is VERY misleading.
532    
533    2. ALPHA fixes/changes
534    
535       a.  Added the instructions LDBU, LDWU, STB, STW as per Fermin's suggestion.
536       b.  Added a new mode byteWordLoadStores to the functor parameter to Alpha()
537       c.  Added reassociation code for address computation.
538    
539    ----------------------------------------------------------------------
540    Name: Allen Leung
541    Date: 2000/03/22 01:23:00
542    Tag: leunga-20000322-fix_x86_hppa_ra
543    Description:
544    
545    1. X86 fixes/changes
546    
547       a.  x86Rewrite bug with MUL3 (found by Lal)
548       b.  Added the instructions FSTS, FSTL
549    
550    2. PA-RISC fixes/changes
551    
552       a.  B label should not be a delay slot candidate!  Why did this work?
553       b.  ADDT(32, REG(32, r), LI n) now generates one instruction instead of two,
554           as it should be.
555       c.  The assembly syntax for fstds and fstdd was wrong.
556       d.  Added the composite instruction COMICLR/LDO, which is the immediate
557           operand variant of COMCLR/LDO.
558    
559    3. Generic MLRISC
560    
561       a.  shuffle.sml rewritten to be slightly more efficient
562       b.  DIV bug in mltree-simplify fixed (found by Fermin)
563    
564    4. Register Allocator
565    
566       a.  I now release the interference graph earlier during spilling.
567           May improve memory usage.
568    
569    ----------------------------------------------------------------------
570    Name: Matthias Blume
571    Date: 2000/03/14 14:15:32
572    Tag: blume_main_v110p26p1_2
573    Description:
574    
575    1. Tools.registerStdShellCmdTool (from smlnj/cm/tool.cm) takes an
576    additional argument called "template" which is an optional string that
577    specifiel the layout of the tool command line.  See the CM manual for
578    explanation.
579    
580    2. A special-purpose tool can be "regisitered" by simply dropping the
581    corresponding <...>-tool.cm (and/or <...>-ext.cm) into the same
582    directory where the .cm file lives that uses this tool.  (The
583    behavior/misfeature until now was to look for the tool description
584    files in the current working directory.)  As before, tool description
585    files could also be anchored -- in which case they can live anywhere
586    they like.  Following the recent e-mail discussion, this change should
587    make it easier to have special-purpose tools that are shipped together
588    with the sources of the program that uses them.
589    
590    ----------------------------------------------------------------------
591    Name: Matthias Blume
592    Date: 2000/03/10 07:48:34
593    Tag: blume_main_v110p26p1_1
594    Description:
595    
596    I added a re-written version of Dave's fixpt script to src/system.
597    Changes relative to the original version:
598      - sh-ified (not everybody has ksh)
599      - automatically figures out which architecture it runs on
600      - uses ./makeml a bit more cleverly
601      - never invokes ./installml (and, thus, does not clobber your
602        good and working installation of sml in case something goes wrong)
603      - accepts max iteration count using option "-iter <n>"
604      - accepts a "base" name using option "-base <base>"
605    
606    It does not build any extraneous heap images but directly rebuilds
607    bin- and boot-hierarchies using makeml's "-rebuild" switch. Finally,
608    it can incorporate existing bin- and boot- hierarchies.  For example,
609    suppose the base is set to "sml" (which is the default).  Then it
610    successively builds
611    
612            sml.bin.<arch>-unix and sml.boot.<arch>-unix
613    then    sml1.bin.<arch>-unix and sml1.boot.<arch>-unix
614    then    sml2.bin.<arch>-unix and sml2.boot.<arch>-unix
615    ...
616    then    sml<n>.bin.<arch>-unix and sml<n>.boot.<arch>-unix
617    
618    and so on.  If any of these already exist, it will just use what's
619    there.  In particular, many people will have the initial set of bin
620    and boot files around, so this saves time for at least one full
621    rebuild.  Having sets of the form <base><k>.{bin,boot}.<arch>-unix for
622    <k>=1,2,... is normally not a good idea when invoking fixpt.  However,
623    they might be the result of an earlier partial run of fixpt (which
624    perhaps got accidentially killed).  In this case, fixpt will quickly
625    move through what exists before continuing where it left off earlier,
626    and, thus, saves a lot of time.
627    
628    ----------------------------------------------------------------------
629  Name: Allen Leung  Name: Allen Leung
630  Date: 00/03/10 02:20:00  Date: 00/03/10 02:20:00
631  Tag: leunga-20000310-fix_x86_asm_ra  Tag: leunga-20000310-fix_x86_asm_ra

Legend:
Removed from v.576  
changed lines
  Added in v.605

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