Diff of /sml/trunk/HISTORY

Parent Directory | Revision Log | Patch

	revision 873, Mon Jul 9 15:26:20 2001 UTC	revision 921, Tue Sep 11 23:20:45 2001 UTC
#	Line 14	Line 14
14
15	----------------------------------------------------------------------	----------------------------------------------------------------------
16	Name: Matthias Blume	Name: Matthias Blume
17		Date: 2001/08/28 14:03:00 EDT
18		Tag: blume-20010828-ml-lex
19		Description:
20
21		Fix for bug 1581, received from Neophytos Michael.
22
23		----------------------------------------------------------------------
24		Name: Matthias Blume
25		Date: 2001/08/27 11:20:00 EDT
26		Tag: blume-20010827-readme11035
27		Description:
28
29		Fleshed out the README file for 110.35.
30
31		----------------------------------------------------------------------
32		Name: Matthias Blume
33		Date: 2001/08/24 17:10:00 EDT
34		Tag: Release_110_35
35		Description:
36
37		New version number (110.35).  New bootfiles.
38
39		----------------------------------------------------------------------
40		Name: Lal George
41		Date: 2001/08/24 13:47:18 EDT 2001
42		Tag: george-20010824-MLRISC-graphs
43		Description:
44
45		removed clusters from MLRISC completely and replaced with graphs.
46
47		----------------------------------------------------------------------
48		Name: Matthias Blume
49		Date: 2001/08/23 17:50:00 EDT
50		Tag: blume-20010823-toplevel
51		Description:
52
53		- some reorganization of the code that implements various kinds of
54		environments in the compiler (static, dynamic, symbolic, combined)
55		- re-implemented the EnvRef module so that evalStream works properly
56		(if the stream contains references to "use", "CM.make", etc.)
57		- cleaned up evalloop.sml and interact.sml (but they need more cleaning)
58
59		----------------------------------------------------------------------
60		Name: Matthias Blume
61		Date: 2001/08/20 15:50 EDT
62		Tag: blume20010820-slipup
63		Description:
64
65		I forgot to commit a few files.  Here they are...
66
67		----------------------------------------------------------------------
68		Name: Matthias Blume
69		Date: 2001/08/20 15:35:00 EDT
70		Tag: blume-20010820-debugprof
71		Description:
72
73		!!!! NEW BOOTFILES !!!!
74
75		This is another round of reorganizing the compiler sources.  This
76		time the main goal was to factor out all the "instrumentation"
77		passes (for profiling and backtracing) into their own library.
78		The difficulty was to do it in such a way that it does not depend
79		on elaborate.cm but only on elabdata.cm.
80
81		Therefore there have been further changes to both elaborate.cm and
82		elabdata.cm -- more "generic" things have been moved from the former
83		to the latter.  As a result, I was forced to split the assignment
84		of numbers indicating "primtyc"s into two portions: SML-generic and
85		SML/NJ-specific.  Since it would have been awkward to maintain,
86		I bit the bullet and actually _changed_ the mapping between these
87		numbers and primtycs.  The bottom line of this is that you need
88		a new set of bin- and bootfiles.
89
90		I have built new bootfiles for all architectures, so doing a fresh
91		checkout and config/install.sh should be all you need.
92
93		The newly created library's name is
94
95		$smlnj/viscomp/debugprof.cm
96
97		and its sources live under
98
99		src/compiler/DebugProf
100
101		----------------------------------------------------------------------
102		Name: Matthias Blume
103		Date: 2001/08/15 17:15:00 EDT
104		Tag: blume-20010815-compreorg
105		Description:
106
107		This is a first cut at reorganizing the CM libraries that make up the
108		core of the compiler.  The idea is to separate out pieces that could
109		be used independently by tools, e.g., the parser, the typechecker, etc.
110
111		The current status is a step in this direction, but it is not quite
112		satisfactory yet.  Expect more changes in the future.
113
114		Here is the current (new) organization...
115
116		What used to be $smlnj/viscomp/core.cm is now divided into
117		six CM libraries:
118
119		$smlnj/viscomp/basics.cm
120		/parser.cm
121		/elabdata.cm
122		/elaborate.cm
123		/execute.cm
124		/core.cm
125
126		The CM files for these libraries live under src/system/smlnj/viscomp.
127		All these libraries are proxy libraries that contain precisely
128		one CM library component.  Here are the locations of the components
129		(all within the src/compiler tree):
130
131		Basics/basics.cm
132		Parse/parser.cm
133		ElabData/elabdata.cm
134		Elaborator/elaborate.cm
135		Execution/execute.cm
136		core.cm
137
138		[This organization is the same that has been used already
139		for a while for the architecture-specific parts of the visible
140		compiler and for the old version of core.cm.]
141
142		As you will notice, many source files have been moved from their
143		respective original locations to a new home in one of the above
144		subtrees.
145
146		The division of labor between the new libraries is the following:
147
148		basics.cm:
149		- Simple, basic definitions that pertain to many (or all) of
150		the other libraries.
151		parser.cm:
152		- The SML parser, producing output of type Ast.dec.
153		- The type family for Ast is also defined and exported here.
154		elabdata.cm:
155		- The datatypes that describe input and output of the elaborator.
156		This includes types, absyn, and static environments.
157		elaborator.cm:
158		- The SML/NJ type checker and elaborator.
159		This maps an Ast.dec (with a given static environment) to
160		an Absyn.dec (with a new static environment).
161		- This libraries implements certain modules that used to be
162		structures as functors (to remove dependencies on FLINT).
163		execute.cm:
164		- Everything having to do with executing binary code objects.
165		- Dynamic environments.
166		core.cm:
167		- SML/NJ-specific instantiations of the elaborator and MLRISC.
168		- Top-level modules.
169		- FLINT (this should eventually become its own library)
170
171		Notes:
172
173		I am not 100% happy with the way I separated the elaborator (and its
174		data structures) from FLINT.  Two instances of the same problem:
175
176		1. Data structures contain certain fields that carry FLINT-specific
177		information.  I hacked around this using exn and the property list
178		module from smlnj-lib.  But the fact that there are middle-end
179		specific fields around at all is a bit annoying.
180
181		2. The elaborator calculates certain FLINT-related information.  I tried
182		to make this as abstract as I could using functorization, but, again,
183		the fact that the elaborator has to perform calculations on behalf
184		of the middle-end at all is not nice.
185
186		3. Having to used exn and property lists is unfortunate because it
187		weakens type checking.  The other alternative (parameterizing
188		nearly *everything*) is not appealing, though.
189
190		I removed the "rebinding =" warning hack because due to the new organization
191		it was awkward to maintain it.  As a result, the compiler now issues some of
192		these warnings when compiling init.cmi during bootstrap compilation. On
193		the plus side, you also get a warning when you do, for example:
194		val op = = Int32.+
195		which was not the case up to now.
196
197		I placed "assign" and "deref" into the _Core structure so that the
198		code that deals with the "lazy" keyword can find them there.  This
199		removes the need for having access to the primitive environment
200		during elaboration.
201
202		----------------------------------------------------------------------
203		Name: Matthias Blume
204		Date: 2001/08/13
205		Tag: blume-20010813-closures
206		Description:
207
208		This fix was sent to us by Zhong Shao.  It is supposed to improve the
209		performance of certain loops by avoiding needless closure allocation.
210
211		----------------------------------------------------------------------
212		Name: Lal George
213		Date: 2001/07/31 10:03:23 EDT 2001
214		Tag: george-20010731-x86-fmalloc
215		Description: Fixed bug in x86 calls
216
217		There was a bug where call instructions would mysteriously
218		vanish. The call instruction had to be one that returned
219		a floating point value.
220
221		----------------------------------------------------------------------
222		Name: Lal George
223		Date: 2001/07/19 16:36:29 EDT 2001
224		Tag: george-20010719-simple-cells
225		Description:
226
227		I have dramatically simplified the interface for CELLS in MLRISC.
228
229		In summary, the cells interface is broken up into three parts:
230
231		1. CellsBasis : CELLS_BASIS
232
233		CellsBasis is a top level structure and common for all
234		architectures.  it contains the definitions of basic datatypes
235		and utility  functions over these types.
236
237		2. functor Cells() : CELLS
238
239		Cells generates an interface for CELLS that incorporates the
240		specific resources on the target architecture, such as the
241		presence of special register classes, their number and size,
242		and various useful substructures.
243
244		3. <ARCH>CELLS
245
246		e.g. SparcCells: SPARCCELLS
247
248		<ARCH>CELLS usually contains additional bindings for special
249		registers  on the architecture, such as:
250
251		val r0 : cell           (* register zero *)
252		val y : cell            (* Y register *)
253		val psr : cell          (* processor status register *)
254		...
255
256		The structure returned by applying the Cells functor is opened
257		in this interface.
258
259		The main implication of all this is that the datatypes for cells is
260		split between CellsBasis and CELLS -- a fairly simple change for user
261		code.
262
263		In the old scheme the CELLS interface had a definitional binding of
264		the form:
265
266		signature CELLS = sig
267
268		structure CellsBasis = CellsBasis
269
270		...
271
272		end
273
274		With all the sharing constraints that goes on in MLRISC, this old
275		design  quickly leads to errors such as:
276
277		"structure definition spec inside of sharing ... "
278
279
280		and appears to require an unacceptable amount of sharing and where
281		constraint hackery.
282
283		I think this error message (the interaction of definitional specs and
284		sharing) requires more explanation on our web page.
285
286		----------------------------------------------------------------------
287		Name: Matthias Blume
288		Date: 2001/07/19 15:00:00 EDT
289		Tag: blume-20010719-libreorg
290		Description:
291
292		This update puts together a fairly extensive but straightforward change
293		to the way the libraries that implement the interactive system are
294		organized:
295
296		The biggest change is the elimination of structure Compiler.  As a
297		replacement for this structure, there is now a CM library
298		(known as $smlnj/compiler.cm or $smlnj/compiler/current.cm)
299		that exports all the substructures of the original structure Compiler
300		directly.  So instead of saying Compiler.Foo.bar one now simply
301		says Foo.bar.  (The CM libraries actually export a collection of
302		structures that is richer than the collection of substructures of
303		structure Compiler.)
304
305		To make the transition smooth, there is a separate library called
306		$smlnj/compiler/compiler.cm which puts together and exports the
307		original structure Compiler (or at least something very close to it).
308
309		There are five members of the original structure Compiler
310		that are not exported directly but which instead became members
311		of a new structure Backend (described by signature BACKEND).  These are:
312		structure Profile (: PROFILE), structure Compile (: COMPILE), structure
313		Interact (: INTERACT), structure Machine (: MACHINE), and val
314		architecture (: string).
315
316		Structure Compiler.Version has become structure CompilerVersion.
317
318		Cross-compilers for alpha32, hppa, ppc, sparc, and x86 are provided
319		by $smlnj/compiler/<arch>.cm where <arch> is alpha32, hppa, ppc, sparc,
320		or x86, respectively.
321		Each of these exports the same frontend structures that
322		$smlnj/compiler.cm exports.  But they do not have a structure Backend
323		and instead export some structure <Arch>Backend where <Arch> is Alpha32,
324		Hppa, PPC, Sparc, or X86, respectively.
325
326		Library $smlnj/compiler/all.cm exports the union of the exports of
327		$smlnj/compiler/<arch>.cm
328
329		There are no structures <Arch>Compiler anymore, use
330		$smlnj/compiler/<arch>.cm instead.
331
332		Library host-compiler-0.cm is gone.  Instead, the internal library
333		that instantiates CM is now called cm0.cm.  Selection of the host
334		compiler (backend) is no longer done here but. (Responsibility for it
335		now lies with $smlnj/compiler/current.cm.  This seems to be more
336		logical.)
337
338		Many individual files have been moved or renamed.  Some files have
339		been split into multiple files, and some "dead" files have been deleted.
340
341		Aside from these changes to library organization, there are also changes
342		to the way the code itself is organized:
343
344		Structure Binfile has been re-implemented in such a way that it no
345		longer needs any knowledge of the compiler.  It exclusively deals
346		with the details of binfile layout.  It no longer invokes the
347		compiler (for the purpose of creating new prospective binfile
348		content), and it no longer has any knowledge of how to interpret
349		pickles.
350
351		Structure Compile (: COMPILE) has been stripped down to the bare
352		essentials of compilation.  It no longer deals with linking/execution.
353		The interface has been cleaned up considerably.
354
355		Utility routines for dealing with linking and execution have been
356		moved into their own substructures.
357
358		(The ultimate goal of these changes is to provide a light-weight
359		binfile loader/linker (at least for, e.g., stable libraries) that
360		does not require CM or the compiler to be present.)
361
362		CM documentation has been updated to reflect the changes to library
363		organization.
364
365		----------------------------------------------------------------------
366		Name: Matthias Blume
367		Date: 2001/07/10 17:30:00 EDT
368		Tag: Release_110_34
369		Description:
370
371		Minor tweak to 110.34 (re-tagged):
372
373		- README.html file added to CVS repository
374		- runtime compiles properly under FreeBSD 3.X and 4.X
375
376		----------------------------------------------------------------------
377		Name: Matthias Blume
378		Date: 2001/07/10 17:30:00 EDT
379		Tag: Release_110_34
380		Description:
381
382		New version number (110.34). New bootfiles.
383
384		----------------------------------------------------------------------
385		Name: Matthias Blume
386		Date: 2001/07/09 16:00:00 EDT
387		Tag: blume-20010709-more-varargs
388		Description:
389
390		I changed the handling of varargs in ml-nlffigen again:
391		The ellipsis ... will now simply be ignored (with an accompanying warning).
392
393		The immediate effect is that you can actually call a varargs function
394		from ML -- but you can't actually supply any arguments beyond the ones
395		specified explicitly.  (For example, you can call printf with its format
396		string, but you cannot pass additional arguments.)
397
398		This behavior is only marginally more useful than the one before, but
399		it has the advantage that a function or, more importantly, a function
400		type never gets dropped on the floor, thus avoiding follow-up problems with
401		other types that refer to the offending one.
402
403		----------------------------------------------------------------------
404		Name: Matthias Blume
405	Date: 2001/07/09 11:25:00 EDT	Date: 2001/07/09 11:25:00 EDT
406	Tag: blume-20010709-varargs	Tag: blume-20010709-varargs
407	Description:	Description:
#	Line 2551	Line 2939
2939	elaborator). There were a lot of changes during my "linkpath" trials	elaborator). There were a lot of changes during my "linkpath" trials
2940	that could have been reverted to their original state but weren't.	that could have been reverted to their original state but weren't.
2941	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
2942	than what was strictly necessary...  (I _did_ resist the tempation	than what was strictly necessary...  (I _did_ resist the temptation
2943	of doing any "global reformatting" to avoid an untimely death at	of doing any "global reformatting" to avoid an untimely death at
2944	Dave's hands. :)	Dave's hands. :)
2945

---

Colored Diff Long Colored Diff Unidiff Context Diff Side by Side

Legend: Removed from v.873   changed lines   Added in v.921

---

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