Diff of /sml/trunk/HISTORY

Parent Directory | Revision Log | Patch

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

---

Colored Diff Long Colored Diff Unidiff Context Diff Side by Side

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

---

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