Diff of /sml/trunk/HISTORY

Parent Directory | Revision Log | Patch

	revision 844, Wed Jun 20 20:39:15 2001 UTC	revision 896, Tue Jul 31 14:09:49 2001 UTC
#	Line 13	Line 13
13	Description:	Description:
14
15	----------------------------------------------------------------------	----------------------------------------------------------------------
16		Name: Lal George
17		Date: 2001/07/31 10:03:23 EDT 2001
18		Tag: george-20010731-x86-fmalloc
19		Description: Fixed bug in x86 calls
20
21		There was a bug where call instructions would mysteriously
22		vanish. The call instruction had to be one that returned
23		a floating point value.
24
25		----------------------------------------------------------------------
26		Name: Lal George
27		Date: 2001/07/19 16:36:29 EDT 2001
28		Tag: george-20010719-simple-cells
29		Description:
30
31		I have dramatically simplified the interface for CELLS in MLRISC.
32
33		In summary, the cells interface is broken up into three parts:
34
35		1. CellsBasis : CELLS_BASIS
36
37		CellsBasis is a top level structure and common for all
38		architectures.  it contains the definitions of basic datatypes
39		and utility  functions over these types.
40
41		2. functor Cells() : CELLS
42
43		Cells generates an interface for CELLS that incorporates the
44		specific resources on the target architecture, such as the
45		presence of special register classes, their number and size,
46		and various useful substructures.
47
48		3. <ARCH>CELLS
49
50		e.g. SparcCells: SPARCCELLS
51
52		<ARCH>CELLS usually contains additional bindings for special
53		registers  on the architecture, such as:
54
55		val r0 : cell           (* register zero *)
56		val y : cell            (* Y register *)
57		val psr : cell          (* processor status register *)
58		...
59
60		The structure returned by applying the Cells functor is opened
61		in this interface.
62
63		The main implication of all this is that the datatypes for cells is
64		split between CellsBasis and CELLS -- a fairly simple change for user
65		code.
66
67		In the old scheme the CELLS interface had a definitional binding of
68		the form:
69
70		signature CELLS = sig
71
72		structure CellsBasis = CellsBasis
73
74		...
75
76		end
77
78		With all the sharing constraints that goes on in MLRISC, this old
79		design  quickly leads to errors such as:
80
81		"structure definition spec inside of sharing ... "
82
83
84		and appears to require an unacceptable amount of sharing and where
85		constraint hackery.
86
87		I think this error message (the interaction of definitional specs and
88		sharing) requires more explanation on our web page.
89
90		----------------------------------------------------------------------
91		Name: Matthias Blume
92		Date: 2001/07/19 15:00:00 EDT
93		Tag: blume-20010719-libreorg
94		Description:
95
96		This update puts together a fairly extensive but straightforward change
97		to the way the libraries that implement the interactive system are
98		organized:
99
100		The biggest change is the elimination of structure Compiler.  As a
101		replacement for this structure, there is now a CM library
102		(known as $smlnj/compiler.cm or $smlnj/compiler/current.cm)
103		that exports all the substructures of the original structure Compiler
104		directly.  So instead of saying Compiler.Foo.bar one now simply
105		says Foo.bar.  (The CM libraries actually export a collection of
106		structures that is richer than the collection of substructures of
107		structure Compiler.)
108
109		To make the transition smooth, there is a separate library called
110		$smlnj/compiler/compiler.cm which puts together and exports the
111		original structure Compiler (or at least something very close to it).
112
113		There are five members of the original structure Compiler
114		that are not exported directly but which instead became members
115		of a new structure Backend (described by signature BACKEND).  These are:
116		structure Profile (: PROFILE), structure Compile (: COMPILE), structure
117		Interact (: INTERACT), structure Machine (: MACHINE), and val
118		architecture (: string).
119
120		Structure Compiler.Version has become structure CompilerVersion.
121
122		Cross-compilers for alpha32, hppa, ppc, sparc, and x86 are provided
123		by $smlnj/compiler/<arch>.cm where <arch> is alpha32, hppa, ppc, sparc,
124		or x86, respectively.
125		Each of these exports the same frontend structures that
126		$smlnj/compiler.cm exports.  But they do not have a structure Backend
127		and instead export some structure <Arch>Backend where <Arch> is Alpha32,
128		Hppa, PPC, Sparc, or X86, respectively.
129
130		Library $smlnj/compiler/all.cm exports the union of the exports of
131		$smlnj/compiler/<arch>.cm
132
133		There are no structures <Arch>Compiler anymore, use
134		$smlnj/compiler/<arch>.cm instead.
135
136		Library host-compiler-0.cm is gone.  Instead, the internal library
137		that instantiates CM is now called cm0.cm.  Selection of the host
138		compiler (backend) is no longer done here but. (Responsibility for it
139		now lies with $smlnj/compiler/current.cm.  This seems to be more
140		logical.)
141
142		Many individual files have been moved or renamed.  Some files have
143		been split into multiple files, and some "dead" files have been deleted.
144
145		Aside from these changes to library organization, there are also changes
146		to the way the code itself is organized:
147
148		Structure Binfile has been re-implemented in such a way that it no
149		longer needs any knowledge of the compiler.  It exclusively deals
150		with the details of binfile layout.  It no longer invokes the
151		compiler (for the purpose of creating new prospective binfile
152		content), and it no longer has any knowledge of how to interpret
153		pickles.
154
155		Structure Compile (: COMPILE) has been stripped down to the bare
156		essentials of compilation.  It no longer deals with linking/execution.
157		The interface has been cleaned up considerably.
158
159		Utility routines for dealing with linking and execution have been
160		moved into their own substructures.
161
162		(The ultimate goal of these changes is to provide a light-weight
163		binfile loader/linker (at least for, e.g., stable libraries) that
164		does not require CM or the compiler to be present.)
165
166		CM documentation has been updated to reflect the changes to library
167		organization.
168
169		----------------------------------------------------------------------
170		Name: Matthias Blume
171		Date: 2001/07/10 17:30:00 EDT
172		Tag: Release_110_34
173		Description:
174
175		Minor tweak to 110.34 (re-tagged):
176
177		- README.html file added to CVS repository
178		- runtime compiles properly under FreeBSD 3.X and 4.X
179
180		----------------------------------------------------------------------
181		Name: Matthias Blume
182		Date: 2001/07/10 17:30:00 EDT
183		Tag: Release_110_34
184		Description:
185
186		New version number (110.34). New bootfiles.
187
188		----------------------------------------------------------------------
189		Name: Matthias Blume
190		Date: 2001/07/09 16:00:00 EDT
191		Tag: blume-20010709-more-varargs
192		Description:
193
194		I changed the handling of varargs in ml-nlffigen again:
195		The ellipsis ... will now simply be ignored (with an accompanying warning).
196
197		The immediate effect is that you can actually call a varargs function
198		from ML -- but you can't actually supply any arguments beyond the ones
199		specified explicitly.  (For example, you can call printf with its format
200		string, but you cannot pass additional arguments.)
201
202		This behavior is only marginally more useful than the one before, but
203		it has the advantage that a function or, more importantly, a function
204		type never gets dropped on the floor, thus avoiding follow-up problems with
205		other types that refer to the offending one.
206
207		----------------------------------------------------------------------
208		Name: Matthias Blume
209		Date: 2001/07/09 11:25:00 EDT
210		Tag: blume-20010709-varargs
211		Description:
212
213		1. ckit-lib.cm now exports structure Error
214		2. ml-nlffigen reports occurences of "..." (i.e., varargs function types)
215		with a warning accompanied by a source location.  Moreover, it
216		merely skips the offending function or type and proceeds with the
217		rest of its work.u  As a result, one can safely feed C code containing
218		"..." to ml-nlffigen.
219		3. There are some internal improvements to CM, providing slightly
220		more general string substitutions in the tools subsystem.
221
222		----------------------------------------------------------------------
223		Name: Matthias Blume
224		Date: 2001/06/27 15:10:00 EDT
225		Tag: blume-20010627-concur
226		Description:
227
228		Fixed a small bug in CM's handling of parallel compilation.
229		(You could observe the bug by Control-C-interrupting an ordinary
230		CMB.make or CM.stabilize and then attaching some compile servers.
231		The result was that all of a sudden the previously interrupted
232		compilation would continue on its own.  This was because of
233		an over-optimization: CM did not bother to clean out certain queues
234		when no servers were attached "anyway", resulting in the contents
235		of these queues to grab control when new servers did get attached.)
236
237		There is also another minor update to the CM manual.
238
239		----------------------------------------------------------------------
240		Name: Matthias Blume
241		Date: 2001/06/26 16:15:00 EDT
242		Tag: blume-20010626-cmdoc
243		Description:
244
245		Minor typo fixed in CM manual (syntax diagram for libraries).
246
247		----------------------------------------------------------------------
248		Name: Matthias Blume
249		Date: 2001/06/25 22:55:00 EDT
250		Tag: blume-20010625-x86pc
251		Description:
252
253		Fixed a nasty bug in the X86 assembly code that caused signal
254		handlers to fail (crash) randomly.
255
256		----------------------------------------------------------------------
257		Name: Matthias Blume
258		Date: 2001/06/25 12:05:00 EDT
259		Tag: blume-20010625-nlffigen
260		Description:
261
262		This update fixes a number of minor bugs in ml-nlffigen as reported by
263		Nick Carter <nbc@andrew.cmu.edu>.
264
265		1. Silly but ok typedefs of the form "typedef void myvoid;" are now accepted.
266		2. Default names for generated files are now derived from the name of
267		the C file *without its directory*.  In particular, this causes generated
268		files to be placed locally even if the C file is in some system directory.
269		3. Default names for generated signatures and structures are also derived
270		from the C file name without its directory.  This avoids silly things
271		like "structure GL/GL".
272		(Other silly names are still possible because ml-nlffigen does not do
273		a thorough check of whether generated names are legal ML identifiers.
274		When in doubt, use command line arguments to force particular names.)
275
276		----------------------------------------------------------------------
277		Name: Matthias Blume
278		Date: 2001/06/21 12:25:00 EDT
279		Tag: blume-20010621-eXene
280		Description:
281
282		eXene now compiles and (sort of) works again.
283
284		The library name (for version > 110.33) is $/eXene.cm.
285
286		I also added an new example in src/eXene/examples/nbody.  See the
287		README file there for details.
288
289		----------------------------------------------------------------------
290	Name: Matthias Blume	Name: Matthias Blume
291	Date: 2001/06/20 16:40:00 EDT	Date: 2001/06/20 16:40:00 EDT
292	Tag: blume-20010620-cml	Tag: blume-20010620-cml

---

Colored Diff Long Colored Diff Unidiff Context Diff Side by Side

Legend: Removed from v.844   changed lines   Added in v.896

---

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