12 |
Tag: <post-commit CVS tag> |
Tag: <post-commit CVS tag> |
13 |
Description: |
Description: |
14 |
---------------------------------------------------------------------- |
---------------------------------------------------------------------- |
15 |
|
Name: Matthias Blume |
16 |
|
Date: 2000/06/27 16:51:00 JST |
17 |
|
Tag: blume-20000627-noweb |
18 |
|
Description: |
19 |
|
|
20 |
|
Changes: |
21 |
|
|
22 |
|
1. Implemented "subdir" and "witness" options for noweb tool. |
23 |
|
This caused some slight internal changes in CM's tool implementation. |
24 |
|
2. Fixed bug in "tool plugin" mechanism. This is essentially cleaning |
25 |
|
some remaining issues from earlier path anchor changes. |
26 |
|
3. Updated CM manual accordingly. |
27 |
|
|
28 |
|
4. Changed implementation of back-tracing so that I now consider it |
29 |
|
ready for prime-time. |
30 |
|
|
31 |
|
In particular, you don't have to explicitly trigger the back-trace |
32 |
|
anymore. Instead, if you are running BTrace-instrumented code and |
33 |
|
there is an uncaught exception (regardless of whether or not it was |
34 |
|
raised in instrumented code), the top-level evalloop will print |
35 |
|
the back-trace. |
36 |
|
|
37 |
|
Features: |
38 |
|
|
39 |
|
- Instrumented and uninstrumented code work together seemlessly. |
40 |
|
(Of course, uninstrumented code is never mentioned in actual |
41 |
|
back-traces.) |
42 |
|
|
43 |
|
- Asymptotic time- and space-complexity of instrumented code is |
44 |
|
equal to that of uninstrumented code. (This means that |
45 |
|
tail-recursion is preserved by the instrumentation phase.) |
46 |
|
|
47 |
|
- Modules whose code has been instrumented in different sessions |
48 |
|
work together without problem. |
49 |
|
|
50 |
|
- There is no penalty whatsoever on uninstrumented code. |
51 |
|
|
52 |
|
- There is no penalty on "raise" expressions, even in |
53 |
|
instrumented code. |
54 |
|
|
55 |
|
A potential bug (or perhaps it is a feature, too): |
56 |
|
|
57 |
|
A back-trace reaches no further than the outermost instrumented |
58 |
|
non-trivial "raise". Here, a "trivial" raise is one that is the |
59 |
|
sole RHS of a "handle" rule. Thus, back-traces reach trough |
60 |
|
|
61 |
|
<exp> handle e => raise e |
62 |
|
|
63 |
|
and even |
64 |
|
|
65 |
|
<exp> handle Foo => raise Bar |
66 |
|
|
67 |
|
and, of course, through |
68 |
|
|
69 |
|
<exp> handle Foo => ... |
70 |
|
|
71 |
|
if the exception was not Foo. |
72 |
|
|
73 |
|
Back-traces always reach right through any un-instrumented code |
74 |
|
including any of its "handle" expressions, trivial or not. |
75 |
|
|
76 |
|
To try this out, do the following: |
77 |
|
|
78 |
|
- Erase all existing binfiles for your program. |
79 |
|
(You may keep binfiles for those modules where you think you |
80 |
|
definitely don't need back-tracing.) |
81 |
|
- Turn on back-trace instrumentation: |
82 |
|
SMLofNJ.Internals.BTrace.mode (SOME true); |
83 |
|
- Recompile your program. (I.e., run "CM.make" or "use".) |
84 |
|
- You may now turn instrumentation off again (if you want): |
85 |
|
SMLofNJ.Internals.BTrace.mode (SOME false); |
86 |
|
- Run your program as usual. If it raises an exception that |
87 |
|
reaches the interactive toplevel, then a back-trace will |
88 |
|
automatically be printed. After that, the toplevel loop |
89 |
|
will print the exception history as usual. |
90 |
|
|
91 |
|
---------------------------------------------------------------------- |
92 |
|
Name: Matthias Blume |
93 |
|
Date: 2000/06/26 09:56:46 JST |
94 |
|
Tag: blume-20000626-setup |
95 |
|
Description: |
96 |
|
|
97 |
|
CM: - setup-parameter to "sml" added; this can be used to run arbitrary |
98 |
|
ML code before and after compiling a file (e.g., to set compiler |
99 |
|
flags) |
100 |
|
|
101 |
|
Compiler: - improved btrace API (in core.sml, internals.{sig,sml}) |
102 |
|
- associated changes to btrace.sml (BTrace instrumentation pass) |
103 |
|
- cleaner implementation of btimp.sml (BTrace tracing and report |
104 |
|
module) |
105 |
|
|
106 |
|
CM manual: * new path encoding documented |
107 |
|
* description of setup-parameter to "sml" added |
108 |
|
|
109 |
|
The biggest user-visible change to back-tracing is that it is no |
110 |
|
longer necessary to compile all traced modules within the same |
111 |
|
session. (This was a real limitation.) |
112 |
|
|
113 |
|
---------------------------------------------------------------------- |
114 |
|
Name: Matthias Blume |
115 |
|
Date: 2000/06/24 12:40:00 JST |
116 |
|
Tag: blume-20000624-startup |
117 |
|
Description: |
118 |
|
|
119 |
|
Fixes startup slowdown problem. (I was calling SrcPath.sync a _tad_ |
120 |
|
bit too often -- to put it mildly. :) |
121 |
|
|
122 |
|
---------------------------------------------------------------------- |
123 |
|
Name: Matthias Blume |
124 |
|
Date: 2000/06/23 18:20:00 JST |
125 |
|
Tag: blume-20000623-btrace |
126 |
|
Description: |
127 |
|
|
128 |
|
This updates adds a backtrace facility to aid programmers in debugging |
129 |
|
their programs. This involves the following changes: |
130 |
|
|
131 |
|
1. Module system/smlnj/init/core.sml (structure _Core) now has hooks for |
132 |
|
keeping track of the current call stack. When programs are compiled |
133 |
|
in a special mode, the compiler will insert calls to these hooks |
134 |
|
into the user program. |
135 |
|
"Hook" means that it is possible for different implementations of |
136 |
|
back-tracing to register themselves (at different times). |
137 |
|
|
138 |
|
2. compiler/MiscUtil/profile/btrace.sml implements the annotation phase |
139 |
|
as an Absyn.dec->Absyn.dec rewrite. Normally this phase is turned off. |
140 |
|
It can be turned on using this call: |
141 |
|
SMLofNJ.Internals.BTrace.mode (SOME true); |
142 |
|
Turning it off again: |
143 |
|
SMLofNJ.Internals.BTrace.mode (SOME false); |
144 |
|
Querying the current status: |
145 |
|
SMLofNJ.Internals.BTrace.mode NONE; |
146 |
|
Annotated programs are about twice as big as normal ones, and they |
147 |
|
run a factor of 2 to 4 slower with a dummy back-trace plugin (one |
148 |
|
where all hooks do nothing). The slowdown with a plugin that is |
149 |
|
actually useful (such as the one supplied by default) is even greater, |
150 |
|
but in the case of the default plugin it is still only an constant |
151 |
|
factor (amortized). |
152 |
|
|
153 |
|
3. system/Basis/Implementation/NJ/internals.{sig,sml} have been augmented |
154 |
|
with a sub-structure BTrace for controlling back-tracing. In particular, |
155 |
|
the above-mentioned function "mode" controls whether the annotation |
156 |
|
phase is invoked by the compiler. Another important function is |
157 |
|
"trigger": when called it aborts the current execution and causes |
158 |
|
the top-level loop to print a full back-trace. |
159 |
|
|
160 |
|
4. compiler/MiscUtil/profile/btimp.sml is the current default plugin |
161 |
|
for back-tracing. It keeps track of the dynamic call stack and in |
162 |
|
addition to that it keeps a partial history at each "level" of that |
163 |
|
stack. For example, if a tail-calls b, b tail-calls c, and c tail-calls |
164 |
|
d and b (at separate times, dynamically), then the report will show: |
165 |
|
|
166 |
|
GOTO d |
167 |
|
/c |
168 |
|
GOTO \b |
169 |
|
CALL a |
170 |
|
|
171 |
|
This shows that there was an initial non-tail call of a, then a |
172 |
|
tail-call to b or c, looping behavior in a cluster of functions that |
173 |
|
consist of b and c, and then a goto from that cluster (i.e., either from |
174 |
|
b or from c) to d. |
175 |
|
|
176 |
|
Note that (depending on the user program) the amount of information |
177 |
|
that the back-trace module has to keep track of at each level is bounded |
178 |
|
by a constant. Thus, the whole implementation has the same asymptotical |
179 |
|
complexity as the original program (both in space and in time). |
180 |
|
|
181 |
|
5. compiler/TopLevel/interact/evalloop.sml has been modified to |
182 |
|
handle the special exception SMLofNJ.Internals.BTrace.BTrace |
183 |
|
which is raised by the "trigger" function mentioned above. |
184 |
|
|
185 |
|
Notes on usage: |
186 |
|
|
187 |
|
- Annotated code works well together with unannotated code: |
188 |
|
Unannotated calls simply do not show up at all in the backtrace. |
189 |
|
|
190 |
|
- It is not a good idea to let modules that were annotated during |
191 |
|
different sessions run at the same time. This is because the compiler |
192 |
|
chooses small integers to identify individual functions, and there |
193 |
|
will be clashes if different modules were compiled in separate sessions. |
194 |
|
(Nothing will crash, and you will even be told about the clashes, but |
195 |
|
back-trace information will in general not be useful.) |
196 |
|
|
197 |
|
- Back-tracing can be confused by callcc and capture. |
198 |
|
|
199 |
|
- The only way of getting a back-trace right now is to explicitly |
200 |
|
invoke the "trigger" function from your user program. Eventually, we |
201 |
|
should make every exception carry back-trace information (if |
202 |
|
available). But since this creates more overhead at "raise"-time |
203 |
|
(similar to the current exnHistory overhead), I have not yet |
204 |
|
implemented this. (The implementation will be rather easy.) With |
205 |
|
exceptions carrying back-trace information, this facility will be even |
206 |
|
more useful because users don't need to modify their programs... |
207 |
|
|
208 |
|
- While it is possible to compile the compiler with back-trace |
209 |
|
annotations turned on (I did it to get some confidence in |
210 |
|
correctness), you must make absolutely sure that core.sml and |
211 |
|
btimp.sml are compiled WITHOUT annotation! (core.sml cannot actually |
212 |
|
be compiled with annotation because there is no core access yet, but |
213 |
|
if you compile btimp.sml with annotation, then the system will go into |
214 |
|
an infinite recursion and crash.) |
215 |
|
Since CM currently does not know about BTrace, the only way to turn |
216 |
|
annotations on and off for different modules of the compiler is to |
217 |
|
interrupt CMB.make, change the settings, and re-invoke it. Of course, |
218 |
|
this is awkward and clumsy. |
219 |
|
|
220 |
|
Sample sessions: |
221 |
|
|
222 |
|
Standard ML of New Jersey v110.28.1 [FLINT v1.5], June 5, 2000 |
223 |
|
- SMLofNJ.Internals.BTrace.mode (SOME true); |
224 |
|
[autoloading] |
225 |
|
[autoloading done] |
226 |
|
val it = false : bool |
227 |
|
- structure X = struct |
228 |
|
- fun main n = let |
229 |
|
- fun a (x, 0) = d x |
230 |
|
- | a (x, n) = b (x, n - 1) |
231 |
|
- and b (x, n) = c (x, n) |
232 |
|
- and c (x, n) = a (x, n) |
233 |
|
- and d x = e (x, 3) |
234 |
|
- and e (x, 0) = f x |
235 |
|
- | e (x, n) = e (x, n - 1) |
236 |
|
- and f 0 = SMLofNJ.Internals.BTrace.trigger () |
237 |
|
- | f n = n * g (n - 1) |
238 |
|
- and g n = a (n, 3) |
239 |
|
- in |
240 |
|
- f n |
241 |
|
- end |
242 |
|
- end; |
243 |
|
structure X : sig val main : int -> int end |
244 |
|
- X.main 3; |
245 |
|
*** BACK-TRACE *** |
246 |
|
GOTO stdIn:4.2-13.20: X.main[2].f |
247 |
|
GOTO-( stdIn:4.2-13.20: X.main[2].e |
248 |
|
GOTO stdIn:4.2-13.20: X.main[2].d |
249 |
|
/ stdIn:4.2-13.20: X.main[2].a |
250 |
|
| stdIn:4.2-13.20: X.main[2].b |
251 |
|
GOTO-\ stdIn:4.2-13.20: X.main[2].c |
252 |
|
CALL stdIn:4.2-13.20: X.main[2].g |
253 |
|
GOTO stdIn:4.2-13.20: X.main[2].f |
254 |
|
GOTO-( stdIn:4.2-13.20: X.main[2].e |
255 |
|
GOTO stdIn:4.2-13.20: X.main[2].d |
256 |
|
/ stdIn:4.2-13.20: X.main[2].a |
257 |
|
| stdIn:4.2-13.20: X.main[2].b |
258 |
|
GOTO-\ stdIn:4.2-13.20: X.main[2].c |
259 |
|
CALL stdIn:4.2-13.20: X.main[2].g |
260 |
|
GOTO stdIn:4.2-13.20: X.main[2].f |
261 |
|
GOTO-( stdIn:4.2-13.20: X.main[2].e |
262 |
|
GOTO stdIn:4.2-13.20: X.main[2].d |
263 |
|
/ stdIn:4.2-13.20: X.main[2].a |
264 |
|
| stdIn:4.2-13.20: X.main[2].b |
265 |
|
GOTO-\ stdIn:4.2-13.20: X.main[2].c |
266 |
|
CALL stdIn:4.2-13.20: X.main[2].g |
267 |
|
GOTO stdIn:4.2-13.20: X.main[2].f |
268 |
|
CALL stdIn:2.15-17.4: X.main[2] |
269 |
|
- |
270 |
|
|
271 |
|
(Note that because of a FLINt bug the above code currently does not |
272 |
|
compile without BTrace turned on.) |
273 |
|
|
274 |
|
Here is another example, using my modified Tiger compiler: |
275 |
|
|
276 |
|
Standard ML of New Jersey v110.28.1 [FLINT v1.5], June 5, 2000 |
277 |
|
- SMLofNJ.Internals.BTrace.mode (SOME true); |
278 |
|
[autoloading] |
279 |
|
[autoloading done] |
280 |
|
val it = false : bool |
281 |
|
- CM.make "sources.cm"; |
282 |
|
[autoloading] |
283 |
|
... |
284 |
|
[autoloading done] |
285 |
|
[scanning sources.cm] |
286 |
|
[parsing (sources.cm):parse.sml] |
287 |
|
[creating directory CM/SKEL ...] |
288 |
|
[parsing (sources.cm):tiger.lex.sml] |
289 |
|
... |
290 |
|
[wrote CM/sparc-unix/semant.sml] |
291 |
|
[compiling (sources.cm):main.sml] |
292 |
|
[wrote CM/sparc-unix/main.sml] |
293 |
|
[New bindings added.] |
294 |
|
val it = true : bool |
295 |
|
- Main.compile ("../testcases/merge.tig", "foo.out"); |
296 |
|
*** BACK-TRACE *** |
297 |
|
CALL lib/semant.sml:99.2-396.21: SemantFun[2].transExp.trvar |
298 |
|
CALL lib/semant.sml:99.2-396.21: SemantFun[2].transExp.trexp |
299 |
|
CALL lib/semant.sml:289.3-295.22: SemantFun[2].transExp.trexp.check[2] |
300 |
|
GOTO lib/semant.sml:289.3-295.22: SemantFun[2].transExp.trexp.check[2] |
301 |
|
CALL lib/semant.sml:99.2-396.21: SemantFun[2].transExp.trexp |
302 |
|
CALL lib/semant.sml:99.2-396.21: SemantFun[2].transExp.trexp |
303 |
|
CALL lib/semant.sml:488.3-505.6: SemantFun[2].transDec.trdec[2].transBody[2] |
304 |
|
/ lib/semant.sml:411.65-543.8: SemantFun[2].transDec |
305 |
|
CALL-\ lib/semant.sml:413.2-540.9: SemantFun[2].transDec.trdec[2] |
306 |
|
CALL lib/semant.sml:99.2-396.21: SemantFun[2].transExp.trexp |
307 |
|
CALL lib/semant.sml:8.52-558.4: SemantFun[2].transProg[2] |
308 |
|
CALL main.sml:1.18-118.4: Main.compile[2] |
309 |
|
- |
310 |
|
|
311 |
|
---------------------------------------------------------------------- |
312 |
|
Name: Matthias Blumen |
313 |
|
Date: 2000/06/21 18:00:00 JST |
314 |
|
Tag: blume-20000621-manual |
315 |
|
Description: |
316 |
|
|
317 |
|
CM manual update: Path environments documented. |
318 |
|
|
319 |
|
---------------------------------------------------------------------- |
320 |
|
Name: Matthias Blume |
321 |
|
Date: 2000/06/19 13:40:00 |
322 |
|
Tag: blume-20000619-manual |
323 |
|
Description: |
324 |
|
|
325 |
|
CM manual and system/README update. This only covers the fact that |
326 |
|
there are no more implicit anchors. (Path environments and the "bind" |
327 |
|
option to "cm" have yet to be documented.) |
328 |
|
|
329 |
|
---------------------------------------------------------------------- |
330 |
|
Name: Matthias Blume |
331 |
|
Date: 2000/06/19 11:05:00 JST |
332 |
|
Tag: blume-20000619-chdir-bugfix |
333 |
|
Description: |
334 |
|
|
335 |
|
Fixed a bug in new SrcPath module that sometimes led to a bad chDir call. |
336 |
|
|
337 |
|
---------------------------------------------------------------------- |
338 |
|
Name: Matthias Blume |
339 |
|
Date: 2000/06/18 22:00:10 JST |
340 |
|
Tag: blume-20000618-implicit-anchors-really-gone |
341 |
|
Description: |
342 |
|
|
343 |
|
I updates the previous HISTORY entry where I forgot to mention that |
344 |
|
implicit anchors are no longer with us. |
345 |
|
|
346 |
|
The current update also gets rid of the (now useless) controller |
347 |
|
CM.Control.implicit_anchors. |
348 |
|
|
349 |
|
---------------------------------------------------------------------- |
350 |
|
Name: Matthias Blume |
351 |
|
Date: 2000/06/16 17:30:00 JST |
352 |
|
Tag: blume-20000616-anchorenv |
353 |
|
Description: |
354 |
|
|
355 |
|
This patch implements the long anticipated (just kidding :) "anchor |
356 |
|
environment" mechanism. In the course of doing this, I also |
357 |
|
re-implemented CM's internal "SrcPath" module from scratch. The new |
358 |
|
one should be more robust in certain boundary cases. In any case, it |
359 |
|
is a lot cleaner than its predecessor (IMHO). |
360 |
|
|
361 |
|
This time, although there is yet another boot file format change, I |
362 |
|
kept the unpickler backward-compatible. As a result, no new bootfiles |
363 |
|
are necessary and bootstrapping is straightforward. (You cannot read |
364 |
|
new bootfiles into an old system, but the other way around is no |
365 |
|
problem.) |
366 |
|
|
367 |
|
Visible changes: |
368 |
|
|
369 |
|
** 0. Implicit path anchors (without the leading $-symbol) are no |
370 |
|
longer recognized at all. This means that such path names are not |
371 |
|
illegal either. For example, the name basis.cm simply refers to a |
372 |
|
local file called "basis.cm" (i.e, the name is an ordinary path |
373 |
|
relative to .cm-files directory). Or, to put it differently, only |
374 |
|
names that start with $ are anchored paths. |
375 |
|
|
376 |
|
** 1. The $<singlearc> abbreviation for $/<singlearc> has finally |
377 |
|
vanished. |
378 |
|
|
379 |
|
John (Reppy) had critizised this as soon as I originally proposed and |
380 |
|
implemented it, but at that time I did not really deeply believe |
381 |
|
him. :) Now I came full-circle because I need the $<singlearc> syntax |
382 |
|
in another place where it cannot be seen as an abbreviation for |
383 |
|
$/<singlearc>. To avoid the confusion, $<singlearc> now means what it |
384 |
|
seems to mean (i.e., it "expands" into the corresponding anchor |
385 |
|
value). |
386 |
|
|
387 |
|
However, when paths are used as members in CM description files, it |
388 |
|
continues to be true that there must be at least another arc after the |
389 |
|
anchor. This is now enforced separately during semantic analysis |
390 |
|
(i.e., from a lexical/syntactical point of view, the notation is ok.) |
391 |
|
|
392 |
|
** 2. The "cm" class now accepts an option "bind". The option's value |
393 |
|
is a sub-option list of precisely two items -- one labeled "anchor" |
394 |
|
and the other one labeled "value". As you might expect, "anchor" is |
395 |
|
used to specify an anchor name to be bound, and "value" specifies what |
396 |
|
the anchor is being bound to. |
397 |
|
|
398 |
|
The value must be a directory name and can be given in either standard |
399 |
|
syntax (including the possibility that it is itself an anchored path) |
400 |
|
or native syntax. |
401 |
|
|
402 |
|
Examples: |
403 |
|
|
404 |
|
foo.cm (bind:(anchor:bar value:$mystuff/bar)) |
405 |
|
lib.cm (bind:(anchor:a value:"H:\\x\\y\\z")) (* only works under windows *) |
406 |
|
|
407 |
|
and so on. |
408 |
|
|
409 |
|
The meaning of this is that the .cm-file will be processed with an |
410 |
|
augmented anchor environment where the given anchor(s) is/are bound to |
411 |
|
the given values(s). |
412 |
|
|
413 |
|
The rationale for having this feature is this: Suppose you are trying |
414 |
|
to use two different (already stable) libraries a.cm and b.cm (that |
415 |
|
you perhaps didn't write yourself). Further, suppose each of these |
416 |
|
two libraries internally uses its own auxiliary library $aux/lib.cm. |
417 |
|
Normally you would now have a problem because the anchor "lib" can not |
418 |
|
be bound to more than one value globally. Therefore, the project that |
419 |
|
uses both a.cm and b.cm must locally redirect the anchor to some other |
420 |
|
place: |
421 |
|
|
422 |
|
a.cm (bind:(anchor:lib value:/usr/lib/smlnj/a-stuff)) |
423 |
|
b.cm (bind:(anchor:lib value:/usr/lib/smlnj/b-stuff)) |
424 |
|
|
425 |
|
This hard-wires $lib/aux.cm to /usr/lib/smlnj/a-stuff/aux.cm or |
426 |
|
/usr/lib/smlnj/b-stuff/aux.cm, respectively. |
427 |
|
|
428 |
|
Hard-wiring path names is a bit inflexible (and CM will verbosely warn |
429 |
|
you when you do so at the time of CM.stabilize). Therefore, you can |
430 |
|
also use an anchored path as the value: |
431 |
|
|
432 |
|
a.cm (bind:(anchor:lib value:$a-lib)) |
433 |
|
b.cm (bind:(anchor:lib value:$b-lib)) |
434 |
|
|
435 |
|
Now you can globally configure (using the usual CM.Anchor.anchor or |
436 |
|
pathconfig machinery) bindings for "a-lib" and "b-lib". Since "lib" |
437 |
|
itself is always locally bound, setting it globally is no longer |
438 |
|
meaningful or necessary (but it does not hurt either). In fact, "lib" |
439 |
|
can still be used as a global anchor for separate purposes. As a |
440 |
|
matter of fact, one can locally define "lib" in terms of a global |
441 |
|
"lib": |
442 |
|
|
443 |
|
a.cm (bind:(anchor:lib value:$lib/a)) |
444 |
|
b.cm (bind:(anchor:lib value:$lib/b)) |
445 |
|
|
446 |
|
** 3: The encoding of path names has changed. This affects the way |
447 |
|
path names are shown in CM's progress report and also the internal |
448 |
|
protocol encoding used for parallel make. |
449 |
|
|
450 |
|
The encoding now uses one or more ':'-separated segments. Each |
451 |
|
segments corresponds to a file that has been specified relative to the |
452 |
|
file given by its preceding segment. The first segment is either |
453 |
|
relative to the CWD, absolute, or anchored. Each segment itself is |
454 |
|
basically a Unix pathname; all segments but the first are relative. |
455 |
|
|
456 |
|
Example: |
457 |
|
|
458 |
|
$foo/bar/baz.cm:a/b/c.sml |
459 |
|
|
460 |
|
This path denotes the file bar/a/b/c.sml relative to the directory |
461 |
|
denoted by anchor "foo". Notice that the encoding also includes |
462 |
|
baz.cm which is the .cm-file that listed a/b/c.sml. As usual, such |
463 |
|
paths are resolved relative to the .cm-files directory, so baz.cm must |
464 |
|
be ignored to get the "real" pathname. |
465 |
|
|
466 |
|
To make this fact more obvious, CM puts the names of such "virtual |
467 |
|
arcs" into parentheses when they appear in progress reports. (No |
468 |
|
parentheses will appear in the internal protocol encoding.) Thus, |
469 |
|
what you really see is: |
470 |
|
|
471 |
|
$foo/bar/(baz.cm):a/b/c.sml |
472 |
|
|
473 |
|
I find this notation to be much more informative than before. |
474 |
|
|
475 |
|
Another new feature of the encoding is that special characters |
476 |
|
including parentheses, colons, (back)slashes, and white space are |
477 |
|
written as \ddd (where ddd is the decimal encoding of the character). |
478 |
|
|
479 |
|
*** The CM manual still needs to be updated. |
480 |
|
|
481 |
|
---------------------------------------------------------------------- |
482 |
|
Name: Allen Leung |
483 |
|
Date: 2000/06/15 00:38:00 |
484 |
|
Tag: leunga-20000615-x86-peephole |
485 |
|
|
486 |
|
x86 Peephole fix by Fermin. Affects c-- and moby only. |
487 |
|
|
488 |
|
---------------------------------------------------------------------- |
489 |
|
Name: Matthias Blume |
490 |
|
Date: 2000/06/12 11:40:00 |
491 |
|
Tag: blume-20000612-parmakefix |
492 |
|
Description: |
493 |
|
|
494 |
|
More cleanup after changing the file naming scheme: This time I |
495 |
|
repaired the parallel make mechanism for CMB.make which I broke earlier. |
496 |
|
|
497 |
|
---------------------------------------------------------------------- |
498 |
|
Name: Allen Leung |
499 |
|
Date: 2000/06/09 01:25:00 |
500 |
|
Tag: leunga-20000609-various |
501 |
|
|
502 |
|
None of these things should affect normal SML/NJ operations |
503 |
|
|
504 |
|
1. Peephole improvements provided by Fermin (c--) |
505 |
|
2. New annotation DEFUSE for adding extra dependence (moby) |
506 |
|
3. New X86 LOCK instructions (moby) |
507 |
|
4. New machine description language for reservation tables (scheduling) |
508 |
|
5. Fixes to various optimization/analysis modules (branch chaining, dominator |
509 |
|
trees etc.) |
510 |
|
6. I've changed the CM files so that they can work with versions |
511 |
|
110.0.6, 110.25 and 110.28 |
512 |
|
|
513 |
|
---------------------------------------------------------------------- |
514 |
|
Name: Matthias Blume |
515 |
|
Date: 2000/06/09 12:40:00 |
516 |
|
Tag: blume-20000609-log |
517 |
|
Description: |
518 |
|
|
519 |
|
- Removed all(?) remaining RCS Log entries from sources. |
520 |
|
|
521 |
|
- Fixed bug in ml-yacc and ml-lex sources (use explicit anchors for |
522 |
|
anchored paths). |
523 |
|
|
524 |
|
---------------------------------------------------------------------- |
525 |
|
Name: Matthias Blume |
526 |
|
Date: 2000/06/07 17:00:00 JST |
527 |
|
Tag: blume-20000607-no-implicit-anchors |
528 |
|
Description: |
529 |
|
|
530 |
|
1. This update changes the default setting for |
531 |
|
CM.Control.implicit_anchors from true to false. This means that |
532 |
|
implicit anchors are no longer permitted by default. I also tried to |
533 |
|
make sure that nothing else still relies on implicit anchors. |
534 |
|
(This is the next step on the schedule towards a CM that does not even |
535 |
|
have the notion of implicit anchors anymore.) |
536 |
|
|
537 |
|
2. More CM manual updates. |
538 |
|
|
539 |
|
3. I managed to track down and fix the pickling bug I mentioned last |
540 |
|
time. Because of the previously existing workaround, this entails no |
541 |
|
immediate practical changes. |
542 |
|
|
543 |
|
---------------------------------------------------------------------- |
544 |
|
Name: Matthias Blume |
545 |
|
Date: 2000/06/06 11:15:00 JST |
546 |
|
Tag: blume-20000606-lazierpickle |
547 |
|
Description: |
548 |
|
|
549 |
|
!!!! NEW BOOT FILES !!!! |
550 |
|
|
551 |
|
* The main purpose of this update is to make library pickles lazier in |
552 |
|
order to reduce the initial space penalty for autoloading a library. |
553 |
|
As a result, it is now possible to have $smlnj/compiler.cm |
554 |
|
pre-registered. This should take care of the many complaints or |
555 |
|
inquiries about missing structure Compiler. This required changes to |
556 |
|
CM's internal data structures and small tweaks to some algorithms. |
557 |
|
|
558 |
|
As a neat additional effect, it is no longer necessary (for the sake |
559 |
|
of lean heap image files) to distinguish between a "minimal" CM and a |
560 |
|
"full" CM. Now, there is only one CM (i.e., the "full" version: |
561 |
|
$smlnj/cm.cm aka $smlnj/cm/full.cm), and it is always available at the |
562 |
|
interactive top level. ($smlnj/cm/minimal.cm is gone.) |
563 |
|
|
564 |
|
To make the life of compiler-hackers easier, "makeml" now also |
565 |
|
pre-registers $smlnj/cmb.cm (aka $smlnj/cmb/current.cm). In other |
566 |
|
words, after you bootstrap a new sml for the first time, you will not |
567 |
|
have to autoload $smlnj/cmb.cm again afterwards. (The first time |
568 |
|
around you will still have to do it, though.) |
569 |
|
|
570 |
|
* A second change consists of major updates to the CM manual. There |
571 |
|
are now several appendices with summary information and also a full |
572 |
|
specification of the CM description file syntax. |
573 |
|
|
574 |
|
* In directory src/system I added the script "allcross". This script |
575 |
|
invokes sml and cross-compiles the compiler for all supported |
576 |
|
architectures. (Useful when providing a new set of boot files.) |
577 |
|
|
578 |
|
* There seems to be a latent bug in my "lazy pickles" mechanism. I |
579 |
|
added a small tweak to pickle-util.sml to work around this problem, |
580 |
|
but it is not a proper fix yet. I will investigate further. (The |
581 |
|
effect of the bug was an inflation of library pickle size.) |
582 |
|
|
583 |
|
* Version number increased to 110.28.1 (to avoid compatibility problems). |
584 |
|
|
585 |
|
---------------------------------------------------------------------- |
586 |
|
Name: Allen Leung |
587 |
|
Date: 2000/05/25 17:28 EDT |
588 |
|
Tag: leunga-20000525-ra |
589 |
|
Description: |
590 |
|
|
591 |
|
Fixed a bug in freezing phase of the register allocator. |
592 |
|
|
593 |
|
---------------------------------------------------------------------- |
594 |
|
Name: Allen Leung |
595 |
|
Date: 2000/05/15 22:53 EDT |
596 |
|
Tag: leunga-20000515-alpha-x86-ra |
597 |
|
Description: |
598 |
|
|
599 |
|
1. Alpha |
600 |
|
|
601 |
|
Slight cleanup. Removed the instruction SGNXL |
602 |
|
|
603 |
|
2. X86 |
604 |
|
|
605 |
|
Added the following instructions to the instruction set: |
606 |
|
|
607 |
|
ROLx, RORx, |
608 |
|
BTx, BTSx, BTLx, BTRx, |
609 |
|
XCHGx, and variants with the LOCK prefix |
610 |
|
|
611 |
|
3. Register Allocation |
612 |
|
|
613 |
|
The module ra-rewrite-with-renaming has been improved. |
614 |
|
|
615 |
|
These have no effect on SML/NJ. |
616 |
|
|
617 |
|
---------------------------------------------------------------------- |
618 |
|
Name: Matthias Blume |
619 |
|
Date: 2000/05/15 16:20:00 JST |
620 |
|
Tag: blume-20000515-lightrebuild |
621 |
|
Description: |
622 |
|
|
623 |
|
1. I added an alternative to "-rebuild" to "makeml". The difference is |
624 |
|
that prior to calling CMB.make' the CM-variable "LIGHT" will be |
625 |
|
defined. In effect, the command will not build any cross-compiler |
626 |
|
backends and therefore finish more quickly. |
627 |
|
|
628 |
|
The "fixpt" script also takes a "-light" switch to be able to use |
629 |
|
this new facility while compiling for a fixpoint. |
630 |
|
|
631 |
|
2. I replaced all mentions of anchored paths in group owner specifications |
632 |
|
with simple relative paths (usually starting with ".."). |
633 |
|
The rationale is that a library's internal workings should not be |
634 |
|
compromised by the lack of some anchor. (An anchor is necessary |
635 |
|
for someone who wants to refer to the library by an anchored path, |
636 |
|
but it should not be necessary to build the same library in the first |
637 |
|
place.) |
638 |
|
|
639 |
|
3. I changed the way CM's tool mechanism determines the shell command |
640 |
|
string used for things like ml-yacc etc. so that it does not break |
641 |
|
when CM.Control.implicit_anchors is turned off. |
642 |
|
|
643 |
|
---------------------------------------------------------------------- |
644 |
|
Name: Matthias Blume |
645 |
|
Date: 2000/05/12 18:20:00 JST |
646 |
|
Tag: blume-20000512-ml-build |
647 |
|
Description: |
648 |
|
|
649 |
|
Fixed a bug in config/_ml-build that prevented ml-yacc and ml-lex from |
650 |
|
getting installed properly (by config/install.sh). |
651 |
|
|
652 |
|
---------------------------------------------------------------------- |
653 |
|
Name: Matthias Blume |
654 |
|
Date: 2000/05/12 17:30:00 JST |
655 |
|
Tag: blume-20000512-anchors |
656 |
|
Description: |
657 |
|
|
658 |
|
!!! NEW BOOT FILES !!! |
659 |
|
|
660 |
|
This change is in preparation of fading out support for "implicitly |
661 |
|
anchored path names". I went through all sources and used the |
662 |
|
explicit (and relatively new) $-notation. See system/README and the |
663 |
|
CM manual for more info on this. |
664 |
|
|
665 |
|
I also modified the anchoring scheme for some things such as "smlnj", |
666 |
|
"MLRISC", "cm", etc. to take advantage of the fact that explicit |
667 |
|
anchors are more expressive: anchor name and first arc do not have to |
668 |
|
coincide. This entails the following user-visible change: |
669 |
|
|
670 |
|
You have to write $smlnj/foo/bar instead of smlnj/foo/bar. In |
671 |
|
particular, when you fire up sml with a command-line argument, say, |
672 |
|
e.g.: |
673 |
|
|
674 |
|
sml '$smlnj/cmb.cm' |
675 |
|
|
676 |
|
At the ML toplevel prompt: |
677 |
|
|
678 |
|
CM.autoload "$smlnj/cmb.cm"; |
679 |
|
|
680 |
|
There is also a new controller in CM.Control that can be used to turn |
681 |
|
off all remaining support for implicit anchors by saying: |
682 |
|
|
683 |
|
CM.autoload "$smlnj/ |
684 |
|
#set CM.Control.implicit_anchors false; |
685 |
|
|
686 |
|
This causes CM to reject implicitly anchored paths. This is (for the |
687 |
|
time being) less permissive than the "final" version where there will |
688 |
|
be no more such implicit anchors and relative paths will be just that: |
689 |
|
relative. |
690 |
|
|
691 |
|
The next step (version after next version?) will be to make the |
692 |
|
default for CM.Control.implicit_anchors false. After the dust has |
693 |
|
settled, I can then produce the "final" version of this... |
694 |
|
|
695 |
|
Note: Since bootstrapping is a bit tricky, I provided new boot files. |
696 |
|
|
697 |
|
---------------------------------------------------------------------- |
698 |
|
Name: Matthias Blume |
699 |
|
Date: 2000/05/11 16:30:00 JST |
700 |
|
Tag: blume-20000511-sources |
701 |
|
Description: |
702 |
|
|
703 |
|
The main change is that I added function CM.sources as a generalized |
704 |
|
version of the earlier CM.makedepend. This entails the following |
705 |
|
additional changes: |
706 |
|
|
707 |
|
- CM.makedepend has been dropped. |
708 |
|
|
709 |
|
- CM manual has been updated. |
710 |
|
|
711 |
|
- TOOLS signature and API have been changed. |
712 |
|
|
713 |
|
---------------------------------------------------------------------- |
714 |
|
Name: Allen Leung |
715 |
|
Date: 2000/05/10 21:17 EDT |
716 |
|
Tag: leunga-20000510-moby-c--ssa |
717 |
|
Description: |
718 |
|
|
719 |
|
Various bug fixes and new features for C--, Moby and MLRISC optimizations. |
720 |
|
None of these affect SML/NJ. |
721 |
|
|
722 |
|
1. Register Allocation |
723 |
|
|
724 |
|
a. A new ra spilling module (ra/ra-spill-with-renaming) is implemented. |
725 |
|
This module tries to remove local (i.e. basic block level) redundancies |
726 |
|
during spilling. |
727 |
|
|
728 |
|
b. A new framework for performing region based register allocation. |
729 |
|
Not yet entirely functional. |
730 |
|
|
731 |
|
2. X86 |
732 |
|
|
733 |
|
a. DefUse for POP was missing the stack pointer [found by Lal] |
734 |
|
b. Reload for CALL was incorrect in X86Spill [found by John] |
735 |
|
c. Various fixes in X86Spill so that it can be used correctly for |
736 |
|
the new spilling module. |
737 |
|
|
738 |
|
3. SSA/IR |
739 |
|
|
740 |
|
a. New module ir/dj-dataflow.sml implements elimination based |
741 |
|
data flow analysis. |
742 |
|
|
743 |
|
4. MLRiscGen |
744 |
|
|
745 |
|
a. Fix for gc type annotation |
746 |
|
|
747 |
|
5. MDGen |
748 |
|
|
749 |
|
Various fixes for machine description -> ml code translation. For ssa |
750 |
|
only. |
751 |
|
|
752 |
|
---------------------------------------------------------------------- |
753 |
|
Name: Allen Leung |
754 |
|
Date: 2000/05/08 22:17 EDT |
755 |
|
Tag: leunga-20000508-labexp |
756 |
|
Description: |
757 |
|
|
758 |
|
Fermin has found a few assembly problems with constant expressions |
759 |
|
generated in LabelExp. Mostly, the problems involve extra parentheses, |
760 |
|
which choke on dumb assemblers. This is his fix. |
761 |
|
|
762 |
|
---------------------------------------------------------------------- |
763 |
|
Name: Dave MacQueen |
764 |
|
Date: 2000/04/09 14:00 EDT |
765 |
|
Tag: dbm-20000502-Version_110_28 |
766 |
|
Description: |
767 |
|
|
768 |
|
1. Updated src/compiler/TopLevel/main/version.sml to version 110.28 |
769 |
|
|
770 |
|
2. Updated config/version to 110.28 |
771 |
|
|
772 |
|
3. Updated config/srcarchiveurl |
773 |
|
|
774 |
|
3. New boot files! |
775 |
|
ftp://ftp.research.bell-labs.com/dist/smlnj/working/110.28/ |
776 |
|
|
777 |
|
---------------------------------------------------------------------- |
778 |
|
Name: Matthias Blume |
779 |
|
Date: 2000/05/01 19:05:00 JST |
780 |
|
Tag: blume-20000501-noweb |
781 |
|
Description: |
782 |
|
|
783 |
|
A new noweb tool has been added. The existing system is entirely |
784 |
|
unaffected by this, but some CM users have asked for renewed noweb |
785 |
|
support. Everything is documented in the CM manual. |
786 |
|
|
787 |
|
New (plugin) libraries: |
788 |
|
|
789 |
|
noweb-tool.cm |
790 |
|
nw-ext.cm |
791 |
|
|
792 |
|
---------------------------------------------------------------------- |
793 |
Name: Dave MacQueen |
Name: Dave MacQueen |
794 |
Date: 2000/04/30 12:40PM EDT |
Date: 2000/04/30 12:40PM EDT |
795 |
Tag: dbm-20000430-bug_fixes |
Tag: dbm-20000430-bug_fixes |
1073 |
|
|
1074 |
3. Assembly |
3. Assembly |
1075 |
|
|
1076 |
When generating assemby, resolve the value of client defined constants, |
When generating assembly, resolve the value of client defined constants, |
1077 |
instead of generating symbolic values. This is controlled by the |
instead of generating symbolic values. This is controlled by the |
1078 |
new flag "asm-resolve-constants", which is default to true. |
new flag "asm-resolve-constants", which is default to true. |
1079 |
|
|
1096 |
|
|
1097 |
To this end, I arranged that instead of "structure Core" as "structure |
To this end, I arranged that instead of "structure Core" as "structure |
1098 |
_Core" is bound in the pervasive environment. Core access is done via |
_Core" is bound in the pervasive environment. Core access is done via |
1099 |
_Core (which can never be accidentially rebound because _Core is not a |
_Core (which can never be accidentally rebound because _Core is not a |
1100 |
legal surface-syntax symbol). |
legal surface-syntax symbol). |
1101 |
|
|
1102 |
The current solution is much cleaner because the core environment is |
The current solution is much cleaner because the core environment is |
1106 |
with dynamic and symbolic parts of the core environment. |
with dynamic and symbolic parts of the core environment. |
1107 |
|
|
1108 |
Remaining hackery (to bind the "magic" symbol _Core) is localized in the |
Remaining hackery (to bind the "magic" symbol _Core) is localized in the |
1109 |
compilation mananger's bootstrap compiler (actually: in the "init group" |
compilation manager's bootstrap compiler (actually: in the "init group" |
1110 |
handling). See the comments in src/system/smlnj/init/init.cmi for |
handling). See the comments in src/system/smlnj/init/init.cmi for |
1111 |
more details. |
more details. |
1112 |
|
|
1221 |
(specified in the .cm file at each instance where the tool's class is |
(specified in the .cm file at each instance where the tool's class is |
1222 |
used). |
used). |
1223 |
|
|
1224 |
This was done to accomodate the new "make" and "shell" tools which |
This was done to accommodate the new "make" and "shell" tools which |
1225 |
facilitate fairly seemless hookup to portions of code managed using |
facilitate fairly seamless hookup to portions of code managed using |
1226 |
Makefiles or Shell scripts. |
Makefiles or Shell scripts. |
1227 |
|
|
1228 |
There are no classes "shared" or "private" anymore. Instead, the |
There are no classes "shared" or "private" anymore. Instead, the |
1234 |
|
|
1235 |
All existing tools are described in the CM manual. |
All existing tools are described in the CM manual. |
1236 |
|
|
1237 |
- Slightly better error handling. (CM now surpresses many followup |
- Slightly better error handling. (CM now suppresses many followup |
1238 |
error messages that tended to be more annoying than helpful.) |
error messages that tended to be more annoying than helpful.) |
1239 |
|
|
1240 |
2. Major changes to the compiler's static environment data structures. |
2. Major changes to the compiler's static environment data structures. |
1368 |
|
|
1369 |
I've changed andl to testl in the floating point test sequence |
I've changed andl to testl in the floating point test sequence |
1370 |
whenever appropriate. The Intel optimization guide states that |
whenever appropriate. The Intel optimization guide states that |
1371 |
testl is perferable to andl. |
testl is preferable to andl. |
1372 |
|
|
1373 |
7. RA (x86 only) |
7. RA (x86 only) |
1374 |
|
|
1550 |
|
|
1551 |
1. Tools.registerStdShellCmdTool (from smlnj/cm/tool.cm) takes an |
1. Tools.registerStdShellCmdTool (from smlnj/cm/tool.cm) takes an |
1552 |
additional argument called "template" which is an optional string that |
additional argument called "template" which is an optional string that |
1553 |
specifiel the layout of the tool command line. See the CM manual for |
specifies the layout of the tool command line. See the CM manual for |
1554 |
explanation. |
explanation. |
1555 |
|
|
1556 |
2. A special-purpose tool can be "regisitered" by simply dropping the |
2. A special-purpose tool can be "registered" by simply dropping the |
1557 |
corresponding <...>-tool.cm (and/or <...>-ext.cm) into the same |
corresponding <...>-tool.cm (and/or <...>-ext.cm) into the same |
1558 |
directory where the .cm file lives that uses this tool. (The |
directory where the .cm file lives that uses this tool. (The |
1559 |
behavior/misfeature until now was to look for the tool description |
behavior/misfeature until now was to look for the tool description |
1597 |
rebuild. Having sets of the form <base><k>.{bin,boot}.<arch>-unix for |
rebuild. Having sets of the form <base><k>.{bin,boot}.<arch>-unix for |
1598 |
<k>=1,2,... is normally not a good idea when invoking fixpt. However, |
<k>=1,2,... is normally not a good idea when invoking fixpt. However, |
1599 |
they might be the result of an earlier partial run of fixpt (which |
they might be the result of an earlier partial run of fixpt (which |
1600 |
perhaps got accidentially killed). In this case, fixpt will quickly |
perhaps got accidentally killed). In this case, fixpt will quickly |
1601 |
move through what exists before continuing where it left off earlier, |
move through what exists before continuing where it left off earlier, |
1602 |
and, thus, saves a lot of time. |
and, thus, saves a lot of time. |
1603 |
|
|
1647 |
it from that remote directory. |
it from that remote directory. |
1648 |
This should simplify installation further: For machines that have |
This should simplify installation further: For machines that have |
1649 |
access to the internet, just fetch <version>-config.tgz, unpack it, |
access to the internet, just fetch <version>-config.tgz, unpack it, |
1650 |
edit config/targets, and go (run config/install.sh). The scipt will |
edit config/targets, and go (run config/install.sh). The script will |
1651 |
fetch everything else that it might need all by itself. |
fetch everything else that it might need all by itself. |
1652 |
|
|
1653 |
For CVS users, this mechanism is not relevant for source archives, but |
For CVS users, this mechanism is not relevant for source archives, but |