Diff of /sml/trunk/HISTORY

Parent Directory | Revision Log | Patch

	revision 874, Mon Jul 9 20:01:40 2001 UTC	revision 958, Fri Oct 12 03:54:43 2001 UTC
#	Line 13	Line 13
13	Description:	Description:
14
15	----------------------------------------------------------------------	----------------------------------------------------------------------
16		Name: Lal George
17		Date: 2001/10/11 23:51:34 EDT
18		Tag: george-20011011-too-many-instrs
19		Description:
20
21		The representation of a program point never expected to see more
22		than 65536 instructions in a basic block!
23
24		----------------------------------------------------------------------
25		Name: Lal George
26		Date: 2001/10/09 09:41:37 EDT
27		Tag: george-20011008-mlrisc-labels
28		Description:
29
30		Changed the machine description files to support printing of
31		local and global labels in assembly code, based on host assembler
32		conventions.
33
34		----------------------------------------------------------------------
35		Name: Matthias Blume
36		Date: 2001/09/25 15:25:00 EDT
37		Tag: blume-20010925-exninfo
38		Description:
39
40		I provided a non-hook implementation of exnName (at the toplevel) and
41		made the "dummy" implementation of exnMessage (at the toplevel) more
42		useful: if nothing gets "hooked in", then at least you are going to
43		see the exception name and a message indicating why you don't see more.
44
45		[For the time being, programs that need exnMessage and want to use
46		ml-build should either use General.exnMessage (strongly recommended) or
47		refer to structure General at some other point so that CM sees a
48		static dependency.]
49
50		[Similar remarks go for "print" and "use":  If you want to use their
51		functionality in stand-alone programs generated by ml-build, then use
52		TextIO.output and Backend.Interact.useFile (from $smlnj/compiler.cm).]
53
54		----------------------------------------------------------------------
55		Name: Matthias Blume
56		Date: 2001/09/20 17:28:00 EDT
57		Tag: blume-20010920-slowfp
58		Description:
59
60		Allen says that x86-fast-fp is not safe yet, so I turned it off again...
61
62		----------------------------------------------------------------------
63		Name: Matthias Blume
64		Date: 2001/09/20 17:20:00 EDT
65		Tag: blume-20010920-canonicalpaths
66		Description:
67
68		0. Updated the BOOT file (something that I forgot to do earlier).
69
70		1. Small internal change to CM so that it avoids "/../" in filenames
71		as much as possible (but only where it is safe).
72
73		2. Changed config/_run-sml (resulting in a changed bin/.run-sml) so
74		that arguments that contain delimiters are passed through correctly.
75		This change also means that all "special" arguments of the form
76		@SMLxxx... must come first.
77
78		3. Changed install script to put relative anchor names for tool commands
79		into pathconfig.
80
81		----------------------------------------------------------------------
82		Name: Matthias Blume
83		>>>>>>> 1.169
84		Date: 2001/09/18 15:35:00 EDT
85		Tag: blume-20010918-readme11036
86		Description:
87
88		Added README files.
89
90		----------------------------------------------------------------------
91		Name: Matthias Blume
92		Date: 2001/09/18 11:45:00 EDT
93		Tag: Release_110_36 (retag)
94		Description:
95
96		Fixed mistake in config/preloads. Retagged as 110.36.
97
98		----------------------------------------------------------------------
99		Name: Matthias Blume
100		Date: 2001/09/18 09:40:00 EDT
101		Tag: Release_110_36_orig (tag changed)
102		Description:
103
104		New version (110.36).  New bootfiles.
105
106		----------------------------------------------------------------------
107		Name: Matthias Blume
108		Date: 2001/09/14 16:15:00 EDT
109		Tag: blume-20010914-x86fastfp
110		Description:
111
112		John committed some changes that Allen made, in particular a (hopefully)
113		correctly working version of the x86-fp module.
114
115		I changed the default setting of the Control.MLRISC.getFlag "x86-fast-fp"
116		flag to "true".  Everything seems to compile to a fixpoint ok, and
117		"mandelbrot" speeds up by about 15%.
118
119		----------------------------------------------------------------------
120		Name: Matthias Blume
121		Date: 2001/09/13 11:20:00 EDT
122		Tag: blume-20010913-minimal
123		Description:
124
125		1. Stefan Monnier's patch to fix a miscompilation problem that
126		was brought to light by John Reppy's work on Moby.
127
128		2. Implemented a minimal "structure Compiler" that contains just
129		"version" and "architecture".  The minimal version will be
130		available when the full version is not.  This is for backward-
131		compatibility with code that wants to test Compiler.version.
132
133		----------------------------------------------------------------------
134		Name: Matthias Blume
135		Date: 2001/08/28 14:03:00 EDT
136		Tag: blume-20010828-ml-lex
137		Description:
138
139		Fix for bug 1581, received from Neophytos Michael.
140
141		----------------------------------------------------------------------
142		Name: Matthias Blume
143		Date: 2001/08/27 11:20:00 EDT
144		Tag: blume-20010827-readme11035
145		Description:
146
147		Fleshed out the README file for 110.35.
148
149		----------------------------------------------------------------------
150		Name: Matthias Blume
151		Date: 2001/08/24 17:10:00 EDT
152		Tag: Release_110_35
153		Description:
154
155		New version number (110.35).  New bootfiles.
156
157		----------------------------------------------------------------------
158		Name: Lal George
159		Date: 2001/08/24 13:47:18 EDT 2001
160		Tag: george-20010824-MLRISC-graphs
161		Description:
162
163		removed clusters from MLRISC completely and replaced with graphs.
164
165		----------------------------------------------------------------------
166		Name: Matthias Blume
167		Date: 2001/08/23 17:50:00 EDT
168		Tag: blume-20010823-toplevel
169		Description:
170
171		- some reorganization of the code that implements various kinds of
172		environments in the compiler (static, dynamic, symbolic, combined)
173		- re-implemented the EnvRef module so that evalStream works properly
174		(if the stream contains references to "use", "CM.make", etc.)
175		- cleaned up evalloop.sml and interact.sml (but they need more cleaning)
176
177		----------------------------------------------------------------------
178		Name: Matthias Blume
179		Date: 2001/08/20 15:50 EDT
180		Tag: blume20010820-slipup
181		Description:
182
183		I forgot to commit a few files.  Here they are...
184
185		----------------------------------------------------------------------
186		Name: Matthias Blume
187		Date: 2001/08/20 15:35:00 EDT
188		Tag: blume-20010820-debugprof
189		Description:
190
191		!!!! NEW BOOTFILES !!!!
192
193		This is another round of reorganizing the compiler sources.  This
194		time the main goal was to factor out all the "instrumentation"
195		passes (for profiling and backtracing) into their own library.
196		The difficulty was to do it in such a way that it does not depend
197		on elaborate.cm but only on elabdata.cm.
198
199		Therefore there have been further changes to both elaborate.cm and
200		elabdata.cm -- more "generic" things have been moved from the former
201		to the latter.  As a result, I was forced to split the assignment
202		of numbers indicating "primtyc"s into two portions: SML-generic and
203		SML/NJ-specific.  Since it would have been awkward to maintain,
204		I bit the bullet and actually _changed_ the mapping between these
205		numbers and primtycs.  The bottom line of this is that you need
206		a new set of bin- and bootfiles.
207
208		I have built new bootfiles for all architectures, so doing a fresh
209		checkout and config/install.sh should be all you need.
210
211		The newly created library's name is
212
213		$smlnj/viscomp/debugprof.cm
214
215		and its sources live under
216
217		src/compiler/DebugProf
218
219		----------------------------------------------------------------------
220		Name: Matthias Blume
221		Date: 2001/08/15 17:15:00 EDT
222		Tag: blume-20010815-compreorg
223		Description:
224
225		This is a first cut at reorganizing the CM libraries that make up the
226		core of the compiler.  The idea is to separate out pieces that could
227		be used independently by tools, e.g., the parser, the typechecker, etc.
228
229		The current status is a step in this direction, but it is not quite
230		satisfactory yet.  Expect more changes in the future.
231
232		Here is the current (new) organization...
233
234		What used to be $smlnj/viscomp/core.cm is now divided into
235		six CM libraries:
236
237		$smlnj/viscomp/basics.cm
238		/parser.cm
239		/elabdata.cm
240		/elaborate.cm
241		/execute.cm
242		/core.cm
243
244		The CM files for these libraries live under src/system/smlnj/viscomp.
245		All these libraries are proxy libraries that contain precisely
246		one CM library component.  Here are the locations of the components
247		(all within the src/compiler tree):
248
249		Basics/basics.cm
250		Parse/parser.cm
251		ElabData/elabdata.cm
252		Elaborator/elaborate.cm
253		Execution/execute.cm
254		core.cm
255
256		[This organization is the same that has been used already
257		for a while for the architecture-specific parts of the visible
258		compiler and for the old version of core.cm.]
259
260		As you will notice, many source files have been moved from their
261		respective original locations to a new home in one of the above
262		subtrees.
263
264		The division of labor between the new libraries is the following:
265
266		basics.cm:
267		- Simple, basic definitions that pertain to many (or all) of
268		the other libraries.
269		parser.cm:
270		- The SML parser, producing output of type Ast.dec.
271		- The type family for Ast is also defined and exported here.
272		elabdata.cm:
273		- The datatypes that describe input and output of the elaborator.
274		This includes types, absyn, and static environments.
275		elaborator.cm:
276		- The SML/NJ type checker and elaborator.
277		This maps an Ast.dec (with a given static environment) to
278		an Absyn.dec (with a new static environment).
279		- This libraries implements certain modules that used to be
280		structures as functors (to remove dependencies on FLINT).
281		execute.cm:
282		- Everything having to do with executing binary code objects.
283		- Dynamic environments.
284		core.cm:
285		- SML/NJ-specific instantiations of the elaborator and MLRISC.
286		- Top-level modules.
287		- FLINT (this should eventually become its own library)
288
289		Notes:
290
291		I am not 100% happy with the way I separated the elaborator (and its
292		data structures) from FLINT.  Two instances of the same problem:
293
294		1. Data structures contain certain fields that carry FLINT-specific
295		information.  I hacked around this using exn and the property list
296		module from smlnj-lib.  But the fact that there are middle-end
297		specific fields around at all is a bit annoying.
298
299		2. The elaborator calculates certain FLINT-related information.  I tried
300		to make this as abstract as I could using functorization, but, again,
301		the fact that the elaborator has to perform calculations on behalf
302		of the middle-end at all is not nice.
303
304		3. Having to used exn and property lists is unfortunate because it
305		weakens type checking.  The other alternative (parameterizing
306		nearly *everything*) is not appealing, though.
307
308		I removed the "rebinding =" warning hack because due to the new organization
309		it was awkward to maintain it.  As a result, the compiler now issues some of
310		these warnings when compiling init.cmi during bootstrap compilation. On
311		the plus side, you also get a warning when you do, for example:
312		val op = = Int32.+
313		which was not the case up to now.
314
315		I placed "assign" and "deref" into the _Core structure so that the
316		code that deals with the "lazy" keyword can find them there.  This
317		removes the need for having access to the primitive environment
318		during elaboration.
319
320		----------------------------------------------------------------------
321		Name: Matthias Blume
322		Date: 2001/08/13
323		Tag: blume-20010813-closures
324		Description:
325
326		This fix was sent to us by Zhong Shao.  It is supposed to improve the
327		performance of certain loops by avoiding needless closure allocation.
328
329		----------------------------------------------------------------------
330		Name: Lal George
331		Date: 2001/07/31 10:03:23 EDT 2001
332		Tag: george-20010731-x86-fmalloc
333		Description: Fixed bug in x86 calls
334
335		There was a bug where call instructions would mysteriously
336		vanish. The call instruction had to be one that returned
337		a floating point value.
338
339		----------------------------------------------------------------------
340		Name: Lal George
341		Date: 2001/07/19 16:36:29 EDT 2001
342		Tag: george-20010719-simple-cells
343		Description:
344
345		I have dramatically simplified the interface for CELLS in MLRISC.
346
347		In summary, the cells interface is broken up into three parts:
348
349		1. CellsBasis : CELLS_BASIS
350
351		CellsBasis is a top level structure and common for all
352		architectures.  it contains the definitions of basic datatypes
353		and utility  functions over these types.
354
355		2. functor Cells() : CELLS
356
357		Cells generates an interface for CELLS that incorporates the
358		specific resources on the target architecture, such as the
359		presence of special register classes, their number and size,
360		and various useful substructures.
361
362		3. <ARCH>CELLS
363
364		e.g. SparcCells: SPARCCELLS
365
366		<ARCH>CELLS usually contains additional bindings for special
367		registers  on the architecture, such as:
368
369		val r0 : cell           (* register zero *)
370		val y : cell            (* Y register *)
371		val psr : cell          (* processor status register *)
372		...
373
374		The structure returned by applying the Cells functor is opened
375		in this interface.
376
377		The main implication of all this is that the datatypes for cells is
378		split between CellsBasis and CELLS -- a fairly simple change for user
379		code.
380
381		In the old scheme the CELLS interface had a definitional binding of
382		the form:
383
384		signature CELLS = sig
385
386		structure CellsBasis = CellsBasis
387
388		...
389
390		end
391
392		With all the sharing constraints that goes on in MLRISC, this old
393		design  quickly leads to errors such as:
394
395		"structure definition spec inside of sharing ... "
396
397
398		and appears to require an unacceptable amount of sharing and where
399		constraint hackery.
400
401		I think this error message (the interaction of definitional specs and
402		sharing) requires more explanation on our web page.
403
404		----------------------------------------------------------------------
405		Name: Matthias Blume
406		Date: 2001/07/19 15:00:00 EDT
407		Tag: blume-20010719-libreorg
408		Description:
409
410		This update puts together a fairly extensive but straightforward change
411		to the way the libraries that implement the interactive system are
412		organized:
413
414		The biggest change is the elimination of structure Compiler.  As a
415		replacement for this structure, there is now a CM library
416		(known as $smlnj/compiler.cm or $smlnj/compiler/current.cm)
417		that exports all the substructures of the original structure Compiler
418		directly.  So instead of saying Compiler.Foo.bar one now simply
419		says Foo.bar.  (The CM libraries actually export a collection of
420		structures that is richer than the collection of substructures of
421		structure Compiler.)
422
423		To make the transition smooth, there is a separate library called
424		$smlnj/compiler/compiler.cm which puts together and exports the
425		original structure Compiler (or at least something very close to it).
426
427		There are five members of the original structure Compiler
428		that are not exported directly but which instead became members
429		of a new structure Backend (described by signature BACKEND).  These are:
430		structure Profile (: PROFILE), structure Compile (: COMPILE), structure
431		Interact (: INTERACT), structure Machine (: MACHINE), and val
432		architecture (: string).
433
434		Structure Compiler.Version has become structure CompilerVersion.
435
436		Cross-compilers for alpha32, hppa, ppc, sparc, and x86 are provided
437		by $smlnj/compiler/<arch>.cm where <arch> is alpha32, hppa, ppc, sparc,
438		or x86, respectively.
439		Each of these exports the same frontend structures that
440		$smlnj/compiler.cm exports.  But they do not have a structure Backend
441		and instead export some structure <Arch>Backend where <Arch> is Alpha32,
442		Hppa, PPC, Sparc, or X86, respectively.
443
444		Library $smlnj/compiler/all.cm exports the union of the exports of
445		$smlnj/compiler/<arch>.cm
446
447		There are no structures <Arch>Compiler anymore, use
448		$smlnj/compiler/<arch>.cm instead.
449
450		Library host-compiler-0.cm is gone.  Instead, the internal library
451		that instantiates CM is now called cm0.cm.  Selection of the host
452		compiler (backend) is no longer done here but. (Responsibility for it
453		now lies with $smlnj/compiler/current.cm.  This seems to be more
454		logical.)
455
456		Many individual files have been moved or renamed.  Some files have
457		been split into multiple files, and some "dead" files have been deleted.
458
459		Aside from these changes to library organization, there are also changes
460		to the way the code itself is organized:
461
462		Structure Binfile has been re-implemented in such a way that it no
463		longer needs any knowledge of the compiler.  It exclusively deals
464		with the details of binfile layout.  It no longer invokes the
465		compiler (for the purpose of creating new prospective binfile
466		content), and it no longer has any knowledge of how to interpret
467		pickles.
468
469		Structure Compile (: COMPILE) has been stripped down to the bare
470		essentials of compilation.  It no longer deals with linking/execution.
471		The interface has been cleaned up considerably.
472
473		Utility routines for dealing with linking and execution have been
474		moved into their own substructures.
475
476		(The ultimate goal of these changes is to provide a light-weight
477		binfile loader/linker (at least for, e.g., stable libraries) that
478		does not require CM or the compiler to be present.)
479
480		CM documentation has been updated to reflect the changes to library
481		organization.
482
483		----------------------------------------------------------------------
484		Name: Matthias Blume
485		Date: 2001/07/10 17:30:00 EDT
486		Tag: Release_110_34
487		Description:
488
489		Minor tweak to 110.34 (re-tagged):
490
491		- README.html file added to CVS repository
492		- runtime compiles properly under FreeBSD 3.X and 4.X
493
494		----------------------------------------------------------------------
495		Name: Matthias Blume
496		Date: 2001/07/10 17:30:00 EDT
497		Tag: Release_110_34
498		Description:
499
500		New version number (110.34). New bootfiles.
501
502		----------------------------------------------------------------------
503	Name: Matthias Blume	Name: Matthias Blume
504	Date: 2001/07/09 16:00:00 EDT	Date: 2001/07/09 16:00:00 EDT
505	Tag: blume-20010709-more-varargs	Tag: blume-20010709-more-varargs
#	Line 2570	Line 3057
3057	elaborator). There were a lot of changes during my "linkpath" trials	elaborator). There were a lot of changes during my "linkpath" trials
3058	that could have been reverted to their original state but weren't.	that could have been reverted to their original state but weren't.
3059	Please, don't be too harsh on me for messing with this code a bit more	Please, don't be too harsh on me for messing with this code a bit more
3060	than what was strictly necessary...  (I _did_ resist the tempation	than what was strictly necessary...  (I _did_ resist the temptation
3061	of doing any "global reformatting" to avoid an untimely death at	of doing any "global reformatting" to avoid an untimely death at
3062	Dave's hands. :)	Dave's hands. :)
3063

---

Colored Diff Long Colored Diff Unidiff Context Diff Side by Side

Legend: Removed from v.874   changed lines   Added in v.958

---

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