Diff of /sml/trunk/HISTORY

Parent Directory | Revision Log | Patch

	revision 1094, Mon Feb 25 09:58:56 2002 UTC	revision 1137, Tue Mar 12 22:28:55 2002 UTC
#	Line 11	Line 11
11	Date: yyyy/mm/dd	Date: yyyy/mm/dd
12	Tag: <post-commit CVS tag>	Tag: <post-commit CVS tag>
13	Description:	Description:
14		----------------------------------------------------------------------
15		Name: Matthias Blume
16		Date: 2002/03/12 17:30:00 EST
17		Tag: blume-20020312-version110392
18		Description:
19
20		Yet another version number bump (because of small changes to the
21		binfile format).  Version number is now 110.39.2.  NEW BOOTFILES!
22
23		Changes:
24
25		The new pid generation scheme described a few weeks ago was overly
26		complicated.  I implemented a new mechanism that is simpler and
27		provides a bit more "stability":  Once CM has seen a compilation
28		unit, it keeps its identity constant (as long as you do not delete
29		those crucial CM/GUID/* files).  This means that when you change
30		and interface, compiler, then go back to the old interface, and
31		compile again, you arrive at the original pid.
32
33		There now also is a mechanism that instructs CM to use the plain
34		environment hash as a module's pid (effectively making its GUID
35		the empty string).  For this, "noguid" must be specified as an
36		option to the .sml file in question within its .cm file.
37		This is most useful for code that is being generated by tools such
38		as ml-nlffigen (because during development programmers tend to
39		erase the tool's entire output directory tree including CM's cached
40		GUIDs).  "noguid" is somewhat dangerous (since it can be used to locally
41		revert to the old, broken behavior of SML/NJ, but in specific cases
42		where there is no danger of interface confusion, its use is ok
43		(I think).
44
45		ml-nlffigen by default generates "noguid" annotations.  They can be
46		turned off by specifying -guid in its command line.
47
48		----------------------------------------------------------------------
49		Name: Lal George
50		Date: 2002/03/12 12 14:42:36 EST
51		Tag: george-20020312-frequency-computation
52		Description:
53
54		Integrated jump chaining and static block frequency into the
55		compiler. More details and numbers later.
56
57		----------------------------------------------------------------------
58		Name: Lal George
59		Date: 2002/03/11 11 22:38:53 EST
60		Tag: george-20020311-jump-chain-elim
61		Description:
62
63		Tested the jump chain elimination on all architectures (except the
64		hppa).  This is on by default right now and is profitable for the
65		alpha and x86, however, it may not be profitable for the sparc and ppc
66		when compiling the compiler.
67
68		The gc test will typically jump to a label at the end of the cluster,
69		where there is another jump to an external cluster containing the actual
70		code to invoke gc. This is to allow factoring of common gc invocation
71		sequences. That is to say, we generate:
72
73		f:
74		testgc
75		ja   L1      % jump if above to L1
76
77		L1:
78		jmp L2
79
80
81		After jump chain elimination the 'ja L1' instructions is converted to
82		'ja L2'. On the sparc and ppc, many of the 'ja L2' instructions may end
83		up being implemented in their long form (if L2 is far away) using:
84
85		jbe     L3      % jump if below or equal to L3
86		jmp     L2
87		L3:
88		...
89
90
91		For large compilation units L2  may be far away.
92
93
94		----------------------------------------------------------------------
95		Name: Matthias Blume
96		Date: 2002/03/11 13:30:00 EST
97		Tag: blume-20020311-mltreeeval
98		Description:
99
100		A functor parameter was missing.
101
102		----------------------------------------------------------------------
103		Name: Allen Leung
104		Date: 2002/03/11 10:30:00 EST
105		Tag: leunga-20020310-runtime-string0
106		Description:
107
108		The representation of the empty string now points to a
109		legal null terminated C string instead of unit.  It is now possible
110		to convert an ML string into C string with InlineT.CharVector.getData.
111		This compiles into one single machine instruction.
112
113		----------------------------------------------------------------------
114		Name: Allen Leung
115		Date: 2002/03/10 23:55:00 EST
116		Tag: leunga-20020310-x86-call
117		Description:
118
119		Added machine generation for CALL instruction (relative displacement mode)
120
121		----------------------------------------------------------------------
122		Name: Matthias Blume
123		Date: 2002/03/08 16:05:00
124		Tag: blume-20020308-entrypoints
125		Description:
126
127		Version number bumped to 110.39.1.  NEW BOOTFILES!
128
129		Entrypoints: non-zero offset into a code object where execution should begin.
130
131		- Added the notion of an entrypoint to CodeObj.
132		- Added reading/writing of entrypoint info to Binfile.
133		- Made runtime system bootloader aware of entrypoints.
134		- Use the address of the label of the first function given to mlriscGen
135		as the entrypoint.  This address is currently always 0, but it will
136		not be 0 once we turn on block placement.
137		- Removed the linkage cluster code (which was The Other Way(tm) of dealing
138		with entry points) from mlriscGen.
139
140		----------------------------------------------------------------------
141		Name: Allen Leung
142		Date: 2002/03/07 20:45:00 EST
143		Tag: leunga-20020307-x86-cmov
144		Description:
145
146		Bug fixes for CMOVcc on x86.
147
148		1. Added machine code generation for CMOVcc
149		2. CMOVcc is now generated in preference over SETcc on PentiumPro or above.
150		3. CMOVcc cannot have an immediate operand as argument.
151
152		----------------------------------------------------------------------
153		Name: Matthias Blume
154		Date: 2002/03/07 16:15:00 EST
155		Tag: blume-20020307-controls
156		Description:
157
158		This is a very large but mostly boring patch which makes (almost)
159		every tuneable compiler knob (i.e., pretty much everything under
160		Control.* plus a few other things) configurable via both the command
161		line and environment variables in the style CM did its configuration
162		until now.
163
164		Try starting sml with '-h' (or, if you are brave, '-H')
165
166		To this end, I added a structure Controls : CONTROLS to smlnj-lib.cm which
167		implements the underlying generic mechanism.
168
169		The interface to some of the existing such facilities has changed somewhat.
170		For example, the MLRiscControl module now provides mkFoo instead of getFoo.
171		(The getFoo interface is still there for backward-compatibility, but its
172		use is deprecated.)
173
174		The ml-build script passes -Cxxx=yyy command-line arguments through so
175		that one can now twiddle the compiler settings when using this "batch"
176		compiler.
177
178		TODO items:
179
180		We should go through and throw out all controls that are no longer
181		connected to anything.  Moreover, we should go through and provide
182		meaningful (and correct!) documentation strings for those controls
183		that still are connected.
184
185		Currently, multiple calls to Controls.new are accepted (only the first
186		has any effect).  Eventually we should make sure that every control
187		is being made (via Controls.new) exactly once.  Future access can then
188		be done using Controls.acc.
189
190		Finally, it would probably be a good idea to use the getter-setter
191		interface to controls rather than ref cells.  For the time being, both
192		styles are provided by the Controls module, but getter-setter pairs are
193		better if thread-safety is of any concern because they can be wrapped.
194
195		*****************************************
196
197		One bug fix: The function blockPlacement in three of the MLRISC
198		backpatch files used to be hard-wired to one of two possibilities at
199		link time (according to the value of the placementFlag).  But (I
200		think) it should rather sense the flag every time.
201
202		*****************************************
203
204		Other assorted changes (by other people who did not supply a HISTORY entry):
205
206		1. the cross-module inliner now works much better (Monnier)
207		2. representation of weights, frequencies, and probabilities in MLRISC
208		changed in preparation of using those for weighted block placement
209		(Reppy, George)
210
211		----------------------------------------------------------------------
212		Name: Lal George
213		Date: 2002/03/07 14:44:24 EST 2002
214		Tag: george-20020307-weighted-block-placement
215
216		Tested the weighted block placement optimization on all architectures
217		(except the hppa) using AMPL to generate the block and edge frequencies.
218		Changes were required in the machine properties to correctly
219		categorize trap instructions. There is an MLRISC flag
220		"weighted-block-placement" that can be used to enable weighted block
221		placement, but this will be ineffective without block/edge
222		frequencies (coming soon).
223
224
225		----------------------------------------------------------------------
226		Name: Lal George
227		Date: 2002/03/05 17:24:48 EST
228		Tag: george-20020305-linkage-cluster
229
230		In order to support the block placement optimization, a new cluster
231		is generated as the very first cluster (called the linkage cluster).
232		It contains a single jump to the 'real' entry point for the compilation
233		unit. Block placement has no effect on the linkage cluster itself, but
234		all the other clusters  have full freedom in the manner in which they
235		reorder blocks or functions.
236
237		On the x86 the typical linkage code that is generated is:
238		----------------------
239		.align 2
240		L0:
241		addl    $L1-L0, 72(%esp)
242		jmp     L1
243
244
245		.align  2
246		L1:
247		----------------------
248
249		72(%esp) is the memory location for the stdlink register. This
250		must contain the address of the CPS function being called. In the
251		above example, it contains the address of  L0; before
252		calling L1 (the real entry point for the compilation unit), it
253		must contain the address for L1, and hence
254
255		addl $L1-L0, 72(%esp)
256
257		I have tested this on all architectures except the hppa.The increase
258		in code size is of course negligible
259
260		----------------------------------------------------------------------
261		Name: Allen Leung
262		Date: 2002/03/03 13:20:00 EST
263		Tag: leunga-20020303-mlrisc-tools
264
265		Added #[ ... ] expressions to mlrisc tools
266
267		----------------------------------------------------------------------
268		Name: Matthias Blume
269		Date: 2002/02/27 12:29:00 EST
270		Tag: blume-20020227-cdebug
271		Description:
272
273		- made types in structure C and C_Debug to be equal
274		- got rid of code duplication (c-int.sml vs. c-int-debug.sml)
275		- there no longer is a C_Int_Debug (C_Debug is directly derived from C)
276
277		----------------------------------------------------------------------
278		Name: Matthias Blume
279		Date: 2002/02/26 12:00:00 EST
280		Tag: blume-20020226-ffi
281		Description:
282
283		1. Fixed a minor bug in CM's "noweb" tool:
284		If numbering is turned off, then truly don't number (i.e., do not
285		supply the -L option to noweb).  The previous behavior was to supply
286		-L'' -- which caused noweb to use the "default" line numbering scheme.
287		Thanks to Chris Richards for pointing this out (and supplying the fix).
288
289		2. Once again, I reworked some aspects of the FFI:
290
291		A. The incomplete/complete type business:
292
293		- Signatures POINTER_TO_INCOMPLETE_TYPE and accompanying functors are
294		gone!
295		- ML types representing an incomplete type are now *equal* to
296		ML types representing their corresponding complete types (just like
297		in C).  This is still safe because ml-nlffigen will not generate
298		RTTI for incomplete types, nor will it generate functions that
299		require access to such RTTI.   But when ML code generated from both
300		incomplete and complete versions of the C type meet, the ML types
301		are trivially interoperable.
302
303		NOTE:  These changes restore the full generality of the translation
304		(which was previously lost when I eliminated functorization)!
305
306		B. Enum types:
307
308		- Structure C now has a type constructor "enum" that is similar to
309		how the "su" constructor works.  However, "enum" is not a phantom
310		type because each "T enum" has values (and is isomorphic to
311		MLRep.Signed.int).
312		- There are generic access operations for enum objects (using
313		MLRep.Signed.int).
314		- ml-nlffigen will generate a structure E_foo for each "enum foo".
315		* The structure contains the definition of type "mlrep" (the ML-side
316		representation type of the enum).  Normally, mlrep is the same
317		as "MLRep.Signed.int", but if ml-nlffigen was invoked with "-ec",
318		then mlrep will be defined as a datatype -- thus facilitating
319		pattern matching on mlrep values.
320		("-ec" will be suppressed if there are duplicate values in an
321		enumeration.)
322		* Constructors ("-ec") or values (no "-ec") e_xxx of type mlrep
323		will be generated for each C enum constant xxx.
324		* Conversion functions m2i and i2m convert between mlrep and
325		MLRep.Signed.int.  (Without "-ec", these functions are identities.)
326		* Coversion functions c and ml convert between mlrep and "tag enum".
327		* Access functions (get/set) fetch and store mlrep values.
328		- By default (unless ml-nlffigen was invoked with "-nocollect"), unnamed
329		enumerations are merged into one single enumeration represented by
330		structure E_'.
331
332	----------------------------------------------------------------------	----------------------------------------------------------------------
333	Name: Allen Leung	Name: Allen Leung
#	Line 69	Line 386
386	TOTAL                                   2375.26u  57.21s  48.00g	TOTAL                                   2375.26u  57.21s  48.00g
387
388	As you can see the old cps spill module suffers from some serious	As you can see the old cps spill module suffers from some serious
389	performance problem but since I cannot decipher the old code fully,	performance problem.  But since I cannot decipher the old code fully,
390	innstead of patching the problems up, I'm reimplementing it	instead of patching the problems up, I'm reimplementing it
391	with a different algorithm.  The new code is more modular,	with a different algorithm.  The new code is more modular,
392	smaller when compiled, and substantially faster	smaller when compiled, and substantially faster
393	(O(n log n) time and O(n) space).  Timing of the new spill module:	(O(n log n) time and O(n) space).  Timing of the new spill module:

---

Colored Diff Long Colored Diff Unidiff Context Diff Side by Side

Legend: Removed from v.1094   changed lines   Added in v.1137

---

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