Diff of /sml/trunk/HISTORY

Parent Directory | Revision Log | Patch

	revision 842, Tue Jun 19 21:24:35 2001 UTC	revision 905, Thu Aug 23 21:53:02 2001 UTC
#	Line 14	Line 14
14
15	----------------------------------------------------------------------	----------------------------------------------------------------------
16	Name: Matthias Blume	Name: Matthias Blume
17		Date: 2001/08/23 17:50:00 EDT
18		Tag: blume-20010823-toplevel
19		Description:
20
21		- some reorganization of the code that implements various kinds of
22		environments in the compiler (static, dynamic, symbolic, combined)
23		- re-implemented the EnvRef module so that evalStream works properly
24		(if the stream contains references to "use", "CM.make", etc.)
25		- cleaned up evalloop.sml and interact.sml (but they need more cleaning)
26
27		----------------------------------------------------------------------
28		Name: Matthias Blume
29		Date: 2001/08/20 15:50 EDT
30		Tag: blume20010820-slipup
31		Description:
32
33		I forgot to commit a few files.  Here they are...
34
35		----------------------------------------------------------------------
36		Name: Matthias Blume
37		Date: 2001/08/20 15:35:00 EDT
38		Tag: blume-20010820-debugprof
39		Description:
40
41		!!!! NEW BOOTFILES !!!!
42
43		This is another round of reorganizing the compiler sources.  This
44		time the main goal was to factor out all the "instrumentation"
45		passes (for profiling and backtracing) into their own library.
46		The difficulty was to do it in such a way that it does not depend
47		on elaborate.cm but only on elabdata.cm.
48
49		Therefore there have been further changes to both elaborate.cm and
50		elabdata.cm -- more "generic" things have been moved from the former
51		to the latter.  As a result, I was forced to split the assignment
52		of numbers indicating "primtyc"s into two portions: SML-generic and
53		SML/NJ-specific.  Since it would have been awkward to maintain,
54		I bit the bullet and actually _changed_ the mapping between these
55		numbers and primtycs.  The bottom line of this is that you need
56		a new set of bin- and bootfiles.
57
58		I have built new bootfiles for all architectures, so doing a fresh
59		checkout and config/install.sh should be all you need.
60
61		The newly created library's name is
62
63		$smlnj/viscomp/debugprof.cm
64
65		and its sources live under
66
67		src/compiler/DebugProf
68
69		----------------------------------------------------------------------
70		Name: Matthias Blume
71		Date: 2001/08/15 17:15:00 EDT
72		Tag: blume-20010815-compreorg
73		Description:
74
75		This is a first cut at reorganizing the CM libraries that make up the
76		core of the compiler.  The idea is to separate out pieces that could
77		be used independently by tools, e.g., the parser, the typechecker, etc.
78
79		The current status is a step in this direction, but it is not quite
80		satisfactory yet.  Expect more changes in the future.
81
82		Here is the current (new) organization...
83
84		What used to be $smlnj/viscomp/core.cm is now divided into
85		six CM libraries:
86
87		$smlnj/viscomp/basics.cm
88		/parser.cm
89		/elabdata.cm
90		/elaborate.cm
91		/execute.cm
92		/core.cm
93
94		The CM files for these libraries live under src/system/smlnj/viscomp.
95		All these libraries are proxy libraries that contain precisely
96		one CM library component.  Here are the locations of the components
97		(all within the src/compiler tree):
98
99		Basics/basics.cm
100		Parse/parser.cm
101		ElabData/elabdata.cm
102		Elaborator/elaborate.cm
103		Execution/execute.cm
104		core.cm
105
106		[This organization is the same that has been used already
107		for a while for the architecture-specific parts of the visible
108		compiler and for the old version of core.cm.]
109
110		As you will notice, many source files have been moved from their
111		respective original locations to a new home in one of the above
112		subtrees.
113
114		The division of labor between the new libraries is the following:
115
116		basics.cm:
117		- Simple, basic definitions that pertain to many (or all) of
118		the other libraries.
119		parser.cm:
120		- The SML parser, producing output of type Ast.dec.
121		- The type family for Ast is also defined and exported here.
122		elabdata.cm:
123		- The datatypes that describe input and output of the elaborator.
124		This includes types, absyn, and static environments.
125		elaborator.cm:
126		- The SML/NJ type checker and elaborator.
127		This maps an Ast.dec (with a given static environment) to
128		an Absyn.dec (with a new static environment).
129		- This libraries implements certain modules that used to be
130		structures as functors (to remove dependencies on FLINT).
131		execute.cm:
132		- Everything having to do with executing binary code objects.
133		- Dynamic environments.
134		core.cm:
135		- SML/NJ-specific instantiations of the elaborator and MLRISC.
136		- Top-level modules.
137		- FLINT (this should eventually become its own library)
138
139		Notes:
140
141		I am not 100% happy with the way I separated the elaborator (and its
142		data structures) from FLINT.  Two instances of the same problem:
143
144		1. Data structures contain certain fields that carry FLINT-specific
145		information.  I hacked around this using exn and the property list
146		module from smlnj-lib.  But the fact that there are middle-end
147		specific fields around at all is a bit annoying.
148
149		2. The elaborator calculates certain FLINT-related information.  I tried
150		to make this as abstract as I could using functorization, but, again,
151		the fact that the elaborator has to perform calculations on behalf
152		of the middle-end at all is not nice.
153
154		3. Having to used exn and property lists is unfortunate because it
155		weakens type checking.  The other alternative (parameterizing
156		nearly *everything*) is not appealing, though.
157
158		I removed the "rebinding =" warning hack because due to the new organization
159		it was awkward to maintain it.  As a result, the compiler now issues some of
160		these warnings when compiling init.cmi during bootstrap compilation. On
161		the plus side, you also get a warning when you do, for example:
162		val op = = Int32.+
163		which was not the case up to now.
164
165		I placed "assign" and "deref" into the _Core structure so that the
166		code that deals with the "lazy" keyword can find them there.  This
167		removes the need for having access to the primitive environment
168		during elaboration.
169
170		----------------------------------------------------------------------
171		Name: Matthias Blume
172		Date: 2001/08/13
173		Tag: blume-20010813-closures
174		Description:
175
176		This fix was sent to us by Zhong Shao.  It is supposed to improve the
177		performance of certain loops by avoiding needless closure allocation.
178
179		----------------------------------------------------------------------
180		Name: Lal George
181		Date: 2001/07/31 10:03:23 EDT 2001
182		Tag: george-20010731-x86-fmalloc
183		Description: Fixed bug in x86 calls
184
185		There was a bug where call instructions would mysteriously
186		vanish. The call instruction had to be one that returned
187		a floating point value.
188
189		----------------------------------------------------------------------
190		Name: Lal George
191		Date: 2001/07/19 16:36:29 EDT 2001
192		Tag: george-20010719-simple-cells
193		Description:
194
195		I have dramatically simplified the interface for CELLS in MLRISC.
196
197		In summary, the cells interface is broken up into three parts:
198
199		1. CellsBasis : CELLS_BASIS
200
201		CellsBasis is a top level structure and common for all
202		architectures.  it contains the definitions of basic datatypes
203		and utility  functions over these types.
204
205		2. functor Cells() : CELLS
206
207		Cells generates an interface for CELLS that incorporates the
208		specific resources on the target architecture, such as the
209		presence of special register classes, their number and size,
210		and various useful substructures.
211
212		3. <ARCH>CELLS
213
214		e.g. SparcCells: SPARCCELLS
215
216		<ARCH>CELLS usually contains additional bindings for special
217		registers  on the architecture, such as:
218
219		val r0 : cell           (* register zero *)
220		val y : cell            (* Y register *)
221		val psr : cell          (* processor status register *)
222		...
223
224		The structure returned by applying the Cells functor is opened
225		in this interface.
226
227		The main implication of all this is that the datatypes for cells is
228		split between CellsBasis and CELLS -- a fairly simple change for user
229		code.
230
231		In the old scheme the CELLS interface had a definitional binding of
232		the form:
233
234		signature CELLS = sig
235
236		structure CellsBasis = CellsBasis
237
238		...
239
240		end
241
242		With all the sharing constraints that goes on in MLRISC, this old
243		design  quickly leads to errors such as:
244
245		"structure definition spec inside of sharing ... "
246
247
248		and appears to require an unacceptable amount of sharing and where
249		constraint hackery.
250
251		I think this error message (the interaction of definitional specs and
252		sharing) requires more explanation on our web page.
253
254		----------------------------------------------------------------------
255		Name: Matthias Blume
256		Date: 2001/07/19 15:00:00 EDT
257		Tag: blume-20010719-libreorg
258		Description:
259
260		This update puts together a fairly extensive but straightforward change
261		to the way the libraries that implement the interactive system are
262		organized:
263
264		The biggest change is the elimination of structure Compiler.  As a
265		replacement for this structure, there is now a CM library
266		(known as $smlnj/compiler.cm or $smlnj/compiler/current.cm)
267		that exports all the substructures of the original structure Compiler
268		directly.  So instead of saying Compiler.Foo.bar one now simply
269		says Foo.bar.  (The CM libraries actually export a collection of
270		structures that is richer than the collection of substructures of
271		structure Compiler.)
272
273		To make the transition smooth, there is a separate library called
274		$smlnj/compiler/compiler.cm which puts together and exports the
275		original structure Compiler (or at least something very close to it).
276
277		There are five members of the original structure Compiler
278		that are not exported directly but which instead became members
279		of a new structure Backend (described by signature BACKEND).  These are:
280		structure Profile (: PROFILE), structure Compile (: COMPILE), structure
281		Interact (: INTERACT), structure Machine (: MACHINE), and val
282		architecture (: string).
283
284		Structure Compiler.Version has become structure CompilerVersion.
285
286		Cross-compilers for alpha32, hppa, ppc, sparc, and x86 are provided
287		by $smlnj/compiler/<arch>.cm where <arch> is alpha32, hppa, ppc, sparc,
288		or x86, respectively.
289		Each of these exports the same frontend structures that
290		$smlnj/compiler.cm exports.  But they do not have a structure Backend
291		and instead export some structure <Arch>Backend where <Arch> is Alpha32,
292		Hppa, PPC, Sparc, or X86, respectively.
293
294		Library $smlnj/compiler/all.cm exports the union of the exports of
295		$smlnj/compiler/<arch>.cm
296
297		There are no structures <Arch>Compiler anymore, use
298		$smlnj/compiler/<arch>.cm instead.
299
300		Library host-compiler-0.cm is gone.  Instead, the internal library
301		that instantiates CM is now called cm0.cm.  Selection of the host
302		compiler (backend) is no longer done here but. (Responsibility for it
303		now lies with $smlnj/compiler/current.cm.  This seems to be more
304		logical.)
305
306		Many individual files have been moved or renamed.  Some files have
307		been split into multiple files, and some "dead" files have been deleted.
308
309		Aside from these changes to library organization, there are also changes
310		to the way the code itself is organized:
311
312		Structure Binfile has been re-implemented in such a way that it no
313		longer needs any knowledge of the compiler.  It exclusively deals
314		with the details of binfile layout.  It no longer invokes the
315		compiler (for the purpose of creating new prospective binfile
316		content), and it no longer has any knowledge of how to interpret
317		pickles.
318
319		Structure Compile (: COMPILE) has been stripped down to the bare
320		essentials of compilation.  It no longer deals with linking/execution.
321		The interface has been cleaned up considerably.
322
323		Utility routines for dealing with linking and execution have been
324		moved into their own substructures.
325
326		(The ultimate goal of these changes is to provide a light-weight
327		binfile loader/linker (at least for, e.g., stable libraries) that
328		does not require CM or the compiler to be present.)
329
330		CM documentation has been updated to reflect the changes to library
331		organization.
332
333		----------------------------------------------------------------------
334		Name: Matthias Blume
335		Date: 2001/07/10 17:30:00 EDT
336		Tag: Release_110_34
337		Description:
338
339		Minor tweak to 110.34 (re-tagged):
340
341		- README.html file added to CVS repository
342		- runtime compiles properly under FreeBSD 3.X and 4.X
343
344		----------------------------------------------------------------------
345		Name: Matthias Blume
346		Date: 2001/07/10 17:30:00 EDT
347		Tag: Release_110_34
348		Description:
349
350		New version number (110.34). New bootfiles.
351
352		----------------------------------------------------------------------
353		Name: Matthias Blume
354		Date: 2001/07/09 16:00:00 EDT
355		Tag: blume-20010709-more-varargs
356		Description:
357
358		I changed the handling of varargs in ml-nlffigen again:
359		The ellipsis ... will now simply be ignored (with an accompanying warning).
360
361		The immediate effect is that you can actually call a varargs function
362		from ML -- but you can't actually supply any arguments beyond the ones
363		specified explicitly.  (For example, you can call printf with its format
364		string, but you cannot pass additional arguments.)
365
366		This behavior is only marginally more useful than the one before, but
367		it has the advantage that a function or, more importantly, a function
368		type never gets dropped on the floor, thus avoiding follow-up problems with
369		other types that refer to the offending one.
370
371		----------------------------------------------------------------------
372		Name: Matthias Blume
373		Date: 2001/07/09 11:25:00 EDT
374		Tag: blume-20010709-varargs
375		Description:
376
377		1. ckit-lib.cm now exports structure Error
378		2. ml-nlffigen reports occurences of "..." (i.e., varargs function types)
379		with a warning accompanied by a source location.  Moreover, it
380		merely skips the offending function or type and proceeds with the
381		rest of its work.u  As a result, one can safely feed C code containing
382		"..." to ml-nlffigen.
383		3. There are some internal improvements to CM, providing slightly
384		more general string substitutions in the tools subsystem.
385
386		----------------------------------------------------------------------
387		Name: Matthias Blume
388		Date: 2001/06/27 15:10:00 EDT
389		Tag: blume-20010627-concur
390		Description:
391
392		Fixed a small bug in CM's handling of parallel compilation.
393		(You could observe the bug by Control-C-interrupting an ordinary
394		CMB.make or CM.stabilize and then attaching some compile servers.
395		The result was that all of a sudden the previously interrupted
396		compilation would continue on its own.  This was because of
397		an over-optimization: CM did not bother to clean out certain queues
398		when no servers were attached "anyway", resulting in the contents
399		of these queues to grab control when new servers did get attached.)
400
401		There is also another minor update to the CM manual.
402
403		----------------------------------------------------------------------
404		Name: Matthias Blume
405		Date: 2001/06/26 16:15:00 EDT
406		Tag: blume-20010626-cmdoc
407		Description:
408
409		Minor typo fixed in CM manual (syntax diagram for libraries).
410
411		----------------------------------------------------------------------
412		Name: Matthias Blume
413		Date: 2001/06/25 22:55:00 EDT
414		Tag: blume-20010625-x86pc
415		Description:
416
417		Fixed a nasty bug in the X86 assembly code that caused signal
418		handlers to fail (crash) randomly.
419
420		----------------------------------------------------------------------
421		Name: Matthias Blume
422		Date: 2001/06/25 12:05:00 EDT
423		Tag: blume-20010625-nlffigen
424		Description:
425
426		This update fixes a number of minor bugs in ml-nlffigen as reported by
427		Nick Carter <nbc@andrew.cmu.edu>.
428
429		1. Silly but ok typedefs of the form "typedef void myvoid;" are now accepted.
430		2. Default names for generated files are now derived from the name of
431		the C file *without its directory*.  In particular, this causes generated
432		files to be placed locally even if the C file is in some system directory.
433		3. Default names for generated signatures and structures are also derived
434		from the C file name without its directory.  This avoids silly things
435		like "structure GL/GL".
436		(Other silly names are still possible because ml-nlffigen does not do
437		a thorough check of whether generated names are legal ML identifiers.
438		When in doubt, use command line arguments to force particular names.)
439
440		----------------------------------------------------------------------
441		Name: Matthias Blume
442		Date: 2001/06/21 12:25:00 EDT
443		Tag: blume-20010621-eXene
444		Description:
445
446		eXene now compiles and (sort of) works again.
447
448		The library name (for version > 110.33) is $/eXene.cm.
449
450		I also added an new example in src/eXene/examples/nbody.  See the
451		README file there for details.
452
453		----------------------------------------------------------------------
454		Name: Matthias Blume
455		Date: 2001/06/20 16:40:00 EDT
456		Tag: blume-20010620-cml
457		Description:
458
459		CML now compiles and works again.
460
461		Libraries (for version > 110.33):
462
463		$cml/cml.cm            Main CML library.
464		$cml/basis.cm          CML's version of $/basis.cm.
465		$cml/cml-internal.cm   Internal helper library.
466		$cml/core-cml.cm       Internal helper library.
467		$cml-lib/trace-cml.cm  Tracing facility.
468		$cml-lib/smlnj-lib.cm  CML's version of $/smlnj-lib.cm
469
470		The installer (config/install.sh) has been taught how to properly
471		install this stuff.
472
473		----------------------------------------------------------------------
474		Name: Matthias Blume
475		Date: 2001/06/19 17:55:00 EDT
476		Tag: blume-20010619-instantiate
477		Description:
478
479		This un-breaks the fix for bug 1432.
480		(The bug was originally fixed in 110.9 but I broke it again some
481		time after that.)
482
483		----------------------------------------------------------------------
484		Name: Matthias Blume
485	Date: 2001/06/19 17:25:00 EDT	Date: 2001/06/19 17:25:00 EDT
486	Tag: blume-20010619-signals	Tag: blume-20010619-signals
487	Description:	Description:

---

Colored Diff Long Colored Diff Unidiff Context Diff Side by Side

Legend: Removed from v.842   changed lines   Added in v.905

---

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