Diff of /sml/trunk/HISTORY

Parent Directory | Revision Log | Patch

	revision 836, Fri May 25 19:28:51 2001 UTC	revision 920, Tue Aug 28 18:03:37 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
406		Tag: blume-20010709-varargs
407		Description:
408
409		1. ckit-lib.cm now exports structure Error
410		2. ml-nlffigen reports occurences of "..." (i.e., varargs function types)
411		with a warning accompanied by a source location.  Moreover, it
412		merely skips the offending function or type and proceeds with the
413		rest of its work.u  As a result, one can safely feed C code containing
414		"..." to ml-nlffigen.
415		3. There are some internal improvements to CM, providing slightly
416		more general string substitutions in the tools subsystem.
417
418		----------------------------------------------------------------------
419		Name: Matthias Blume
420		Date: 2001/06/27 15:10:00 EDT
421		Tag: blume-20010627-concur
422		Description:
423
424		Fixed a small bug in CM's handling of parallel compilation.
425		(You could observe the bug by Control-C-interrupting an ordinary
426		CMB.make or CM.stabilize and then attaching some compile servers.
427		The result was that all of a sudden the previously interrupted
428		compilation would continue on its own.  This was because of
429		an over-optimization: CM did not bother to clean out certain queues
430		when no servers were attached "anyway", resulting in the contents
431		of these queues to grab control when new servers did get attached.)
432
433		There is also another minor update to the CM manual.
434
435		----------------------------------------------------------------------
436		Name: Matthias Blume
437		Date: 2001/06/26 16:15:00 EDT
438		Tag: blume-20010626-cmdoc
439		Description:
440
441		Minor typo fixed in CM manual (syntax diagram for libraries).
442
443		----------------------------------------------------------------------
444		Name: Matthias Blume
445		Date: 2001/06/25 22:55:00 EDT
446		Tag: blume-20010625-x86pc
447		Description:
448
449		Fixed a nasty bug in the X86 assembly code that caused signal
450		handlers to fail (crash) randomly.
451
452		----------------------------------------------------------------------
453		Name: Matthias Blume
454		Date: 2001/06/25 12:05:00 EDT
455		Tag: blume-20010625-nlffigen
456		Description:
457
458		This update fixes a number of minor bugs in ml-nlffigen as reported by
459		Nick Carter <nbc@andrew.cmu.edu>.
460
461		1. Silly but ok typedefs of the form "typedef void myvoid;" are now accepted.
462		2. Default names for generated files are now derived from the name of
463		the C file *without its directory*.  In particular, this causes generated
464		files to be placed locally even if the C file is in some system directory.
465		3. Default names for generated signatures and structures are also derived
466		from the C file name without its directory.  This avoids silly things
467		like "structure GL/GL".
468		(Other silly names are still possible because ml-nlffigen does not do
469		a thorough check of whether generated names are legal ML identifiers.
470		When in doubt, use command line arguments to force particular names.)
471
472		----------------------------------------------------------------------
473		Name: Matthias Blume
474		Date: 2001/06/21 12:25:00 EDT
475		Tag: blume-20010621-eXene
476		Description:
477
478		eXene now compiles and (sort of) works again.
479
480		The library name (for version > 110.33) is $/eXene.cm.
481
482		I also added an new example in src/eXene/examples/nbody.  See the
483		README file there for details.
484
485		----------------------------------------------------------------------
486		Name: Matthias Blume
487		Date: 2001/06/20 16:40:00 EDT
488		Tag: blume-20010620-cml
489		Description:
490
491		CML now compiles and works again.
492
493		Libraries (for version > 110.33):
494
495		$cml/cml.cm            Main CML library.
496		$cml/basis.cm          CML's version of $/basis.cm.
497		$cml/cml-internal.cm   Internal helper library.
498		$cml/core-cml.cm       Internal helper library.
499		$cml-lib/trace-cml.cm  Tracing facility.
500		$cml-lib/smlnj-lib.cm  CML's version of $/smlnj-lib.cm
501
502		The installer (config/install.sh) has been taught how to properly
503		install this stuff.
504
505		----------------------------------------------------------------------
506		Name: Matthias Blume
507		Date: 2001/06/19 17:55:00 EDT
508		Tag: blume-20010619-instantiate
509		Description:
510
511		This un-breaks the fix for bug 1432.
512		(The bug was originally fixed in 110.9 but I broke it again some
513		time after that.)
514
515		----------------------------------------------------------------------
516		Name: Matthias Blume
517		Date: 2001/06/19 17:25:00 EDT
518		Tag: blume-20010619-signals
519		Description:
520
521		This should (hopefully) fix the long-standing signal handling bug.
522		(The runtime system was constructing a continuation record with an
523		incorrect descriptor which would cause the GC to drop data on the floor...)
524
525		----------------------------------------------------------------------
526		Name: Matthias Blume
527		Date: 2001/06/15 15:05:00 EDT
528		Tag: blume-20010615-moresparc
529		Description:
530
531		Here is a short late-hour update related to Sparc c-calls:
532
533		-- made handling of double-word arguments a bit smarter
534
535		-- instruction selection phase tries to collapse certain clumsily
536		constructed ML-Trees; typical example:
537
538		ADD(ty,ADD(_,e,LI d1),LI d2)  ->  ADD(ty,e,LI(d1+d2))
539
540		This currently has no further impact on SML/NJ since mlriscGen does
541		not seem to generate such patterns in the first place, and c-calls
542		(which did generate them in the beginning) has meanwhile been fixed
543		so as to avoid them as well.
544
545		----------------------------------------------------------------------
546		Name: Matthias Blume
547		Date: 2001/06/15 15:05:00 EDT
548		Tag: blume-20010615-sparc
549		Description:
550
551		The purpose of this update is to provide an implementation of NLFFI
552		on Sparc machines.
553
554		Here are the changes in detail:
555
556		* src/MLRISC/sparc/c-calls/sparc-c-calls.sml is a new file containing
557		the Sparc implementation of the c-calls API.
558		* The Sparc backend of SML/NJ has been modified to uniformely use %fp
559		for accessing the ML frame.  Thus, we have a real frame pointer and
560		can freely modify %sp without need for an omit-frame-ptr phase.
561		The vfp logic in src/compiler/CodeGen/* has been changed to accomodate
562		this case.
563		* ml-nlffigen has been taught to produce code for different architectures
564		and calling conventions.
565		* In a way similar to what was done in the x86 case, the Sparc
566		backend uses its own specific extension to mltree.  (For example,
567		it needs to be able to generate UNIMP instructions which are part
568		of the calling convention.)
569		* ml-nlffi-lib was reorganized to make it more modular (in particular,
570		to make it easier to plug in new machine- and os-dependent parts).
571
572		There are some other fairly unrelated bug fixes and cleanups as well:
573
574		* I further hacked the .cm files for MLRISC tools (like MDLGen) so
575		that they properly share their libraries with existing SML/NJ libraries.
576		* I fixed a minor cosmetic bug in CM, supressing certain spurious
577		follow-up error messages.
578		* Updates to CM/CMB documentation.
579
580		TODO items:
581
582		* MLRISC should use a different register as its asmTemp on the Sparc.
583		(The current %o2 is a really bad choice because it is part of the
584		calling conventions, so things might interfere in unexpected ways.)
585
586		----------------------------------------------------------------------
587		Name: Matthias Blume
588		Date: 2001/06/07
589		Tag: blume-20010607-calls
590		Description:
591
592		A number of internal changes related to C calls and calling conventions:
593
594		1. ML-Tree CALL statements now carry a "pops" field.  It indicates the
595		number of bytes popped implicitly (by the callee).  In most cases
596		this field is 0 but on x86/win32 it is some non-zero value.  This
597		is information provided for the benefit of the "omit-frameptr" pass.
598		2. The CALL instruction on the x86 carries a similar "pops" field.
599		The instruction selection phase copies its value from the ML-Tree
600		CALL statement.
601		3. On all other architectures, the instruction selection phase checks
602		whether "pops=0" and complains if not.
603		4. The c-calls implementation for x86 now accepts two calling conventions:
604		"ccall" and "stdcall".  When "ccall" is selected, the caller cleans
605		up after the call and pops is set to 0.  For "stdcall", the caller
606		does nothing, leaving the cleanup to the callee; pops is set to
607		the number of bytes that were pushed onto the stack.
608		5. The cproto decoder (compiler/Semant/types/cproto.sml) now can
609		distinguish between "ccall" and "stdcall".
610		6. The UNIMP instruction has been added to the supported Sparc instruction
611		set. (This is needed for implementing the official C calling convention
612		on this architecture.)
613		7. I fixed some of the .cm files under src/MLRISC/Tools to make them
614		work with the latest CM.
615
616		----------------------------------------------------------------------
617		Name: Matthias Blume
618		Date: 2001/06/05 15:10:00 EDT
619		Tag: blume-20010605-cm-index
620		Description:
621
622		0. The "lambdasplit" parameter for class "sml" in CM has been documented.
623
624		1. CM can now generate "index files".  These are human-readable files
625		that list on a per-.cm-file basis each toplevel symbol defined or
626		imported.  The location of the index file for
627		<p>/<d>.cm is <p>/CM/INDEX/<d>.cm.
628		To enable index-file generation, set CM.Control.generate_index to true
629		or export an environment-symbol: export CM_GENERATE_INDEX=true.
630
631		The CM manual has been updated accordingly.
632
633		2. I made some slight modifications to the c-calls API in MLRISC.
634
635		a) There is now a callback to support saving/restoring of
636		dedicated but caller-save registers around the actual call
637		instruction.
638		b) One can optionally specify a comment-annotation for the
639		call instruction.
640
641		3. SML/NJ (mlriscGen.sml) uses this new API for the rawccall primop.
642		(For example, the comment annotation shows the C prototype of
643		the function being called.)
644
645		----------------------------------------------------------------------
646		Name: Matthias Blume
647		Date: 2001/06/01 13:30:00 EDT
648		Tag: blume-20010601-nlffi-cleanup
649		Description:
650
651		This is mostly a cleanup of MLFFI stuff:
652
653		- some signature files have been put into a more exposed place
654		- the ugly 'f type parameter is gone (simplifies types tremendously!)
655		- ml-nlffigen changed accordingly
656		- tutorial updated
657
658		Other changes:
659
660		- author's affiliation in CM manual(s) updated
661		- some more recognized keywords added to Allen's sml.sty
662
663		----------------------------------------------------------------------
664		Name: Matthias Blume
665	Date: 2001/05/25 15:30:00 EDT	Date: 2001/05/25 15:30:00 EDT
666	Tag: blume-20010525-iptr	Tag: blume-20010525-iptr
667	Description:	Description:

---

Colored Diff Long Colored Diff Unidiff Context Diff Side by Side

Legend: Removed from v.836   changed lines   Added in v.920

---

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