Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Diff of /sml/trunk/HISTORY
ViewVC logotype

Diff of /sml/trunk/HISTORY

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1098, Wed Feb 27 17:29:47 2002 UTC revision 1130, Mon Mar 11 04:49:41 2002 UTC
# Line 13  Line 13 
13  Description:  Description:
14    
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16    Name: Allen Leung
17    Date: 2002/03/10 23:55:00 EST
18    Tag: leunga-20020310-x86-call
19    Description:
20    
21       Added machine generation for CALL instruction (relative displacement mode)
22    
23    ----------------------------------------------------------------------
24    Name: Matthias Blume
25    Date: 2002/03/08 16:05:00
26    Tag: blume-20020308-entrypoints
27    Description:
28    
29    Version number bumped to 110.39.1.  NEW BOOTFILES!
30    
31    Entrypoints: non-zero offset into a code object where execution should begin.
32    
33    - Added the notion of an entrypoint to CodeObj.
34    - Added reading/writing of entrypoint info to Binfile.
35    - Made runtime system bootloader aware of entrypoints.
36    - Use the address of the label of the first function given to mlriscGen
37      as the entrypoint.  This address is currently always 0, but it will
38      not be 0 once we turn on block placement.
39    - Removed the linkage cluster code (which was The Other Way(tm) of dealing
40      with entry points) from mlriscGen.
41    
42    ----------------------------------------------------------------------
43    Name: Allen Leung
44    Date: 2002/03/07 20:45:00 EST
45    Tag: leunga-20020307-x86-cmov
46    Description:
47    
48       Bug fixes for CMOVcc on x86.
49    
50       1. Added machine code generation for CMOVcc
51       2. CMOVcc is now generated in preference over SETcc on PentiumPro or above.
52       3. CMOVcc cannot have an immediate operand as argument.
53    
54    ----------------------------------------------------------------------
55    Name: Matthias Blume
56    Date: 2002/03/07 16:15:00 EST
57    Tag: blume-20020307-controls
58    Description:
59    
60    This is a very large but mostly boring patch which makes (almost)
61    every tuneable compiler knob (i.e., pretty much everything under
62    Control.* plus a few other things) configurable via both the command
63    line and environment variables in the style CM did its configuration
64    until now.
65    
66    Try starting sml with '-h' (or, if you are brave, '-H')
67    
68    To this end, I added a structure Controls : CONTROLS to smlnj-lib.cm which
69    implements the underlying generic mechanism.
70    
71    The interface to some of the existing such facilities has changed somewhat.
72    For example, the MLRiscControl module now provides mkFoo instead of getFoo.
73    (The getFoo interface is still there for backward-compatibility, but its
74    use is deprecated.)
75    
76    The ml-build script passes -Cxxx=yyy command-line arguments through so
77    that one can now twiddle the compiler settings when using this "batch"
78    compiler.
79    
80    TODO items:
81    
82    We should go through and throw out all controls that are no longer
83    connected to anything.  Moreover, we should go through and provide
84    meaningful (and correct!) documentation strings for those controls
85    that still are connected.
86    
87    Currently, multiple calls to Controls.new are accepted (only the first
88    has any effect).  Eventually we should make sure that every control
89    is being made (via Controls.new) exactly once.  Future access can then
90    be done using Controls.acc.
91    
92    Finally, it would probably be a good idea to use the getter-setter
93    interface to controls rather than ref cells.  For the time being, both
94    styles are provided by the Controls module, but getter-setter pairs are
95    better if thread-safety is of any concern because they can be wrapped.
96    
97    *****************************************
98    
99    One bug fix: The function blockPlacement in three of the MLRISC
100    backpatch files used to be hard-wired to one of two possibilities at
101    link time (according to the value of the placementFlag).  But (I
102    think) it should rather sense the flag every time.
103    
104    *****************************************
105    
106    Other assorted changes (by other people who did not supply a HISTORY entry):
107    
108    1. the cross-module inliner now works much better (Monnier)
109    2. representation of weights, frequencies, and probabilities in MLRISC
110       changed in preparation of using those for weighted block placement
111       (Reppy, George)
112    
113    ----------------------------------------------------------------------
114    Name: Lal George
115    Date: 2002/03/07 14:44:24 EST 2002
116    Tag: george-20020307-weighted-block-placement
117    
118    Tested the weighted block placement optimization on all architectures
119    (except the hppa) using AMPL to generate the block and edge frequencies.
120    Changes were required in the machine properties to correctly
121    categorize trap instructions. There is an MLRISC flag
122    "weighted-block-placement" that can be used to enable weighted block
123    placement, but this will be ineffective without block/edge
124    frequencies (coming soon).
125    
126    
127    ----------------------------------------------------------------------
128    Name: Lal George
129    Date: 2002/03/05 17:24:48 EST
130    Tag: george-20020305-linkage-cluster
131    
132    In order to support the block placement optimization, a new cluster
133    is generated as the very first cluster (called the linkage cluster).
134    It contains a single jump to the 'real' entry point for the compilation
135    unit. Block placement has no effect on the linkage cluster itself, but
136    all the other clusters  have full freedom in the manner in which they
137    reorder blocks or functions.
138    
139    On the x86 the typical linkage code that is generated is:
140       ----------------------
141            .align 2
142       L0:
143            addl    $L1-L0, 72(%esp)
144            jmp     L1
145    
146    
147            .align  2
148       L1:
149       ----------------------
150    
151    72(%esp) is the memory location for the stdlink register. This
152    must contain the address of the CPS function being called. In the
153    above example, it contains the address of  L0; before
154    calling L1 (the real entry point for the compilation unit), it
155    must contain the address for L1, and hence
156    
157            addl $L1-L0, 72(%esp)
158    
159    I have tested this on all architectures except the hppa.The increase
160    in code size is of course negligible
161    
162    ----------------------------------------------------------------------
163    Name: Allen Leung
164    Date: 2002/03/03 13:20:00 EST
165    Tag: leunga-20020303-mlrisc-tools
166    
167      Added #[ ... ] expressions to mlrisc tools
168    
169    ----------------------------------------------------------------------
170  Name: Matthias Blume  Name: Matthias Blume
171  Date: 2002/02/27 12:29:00 EST  Date: 2002/02/27 12:29:00 EST
172  Tag: blume-20020227-cdebug  Tag: blume-20020227-cdebug
# Line 134  Line 288 
288         TOTAL                                   2375.26u  57.21s  48.00g         TOTAL                                   2375.26u  57.21s  48.00g
289    
290  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
291  performance problem but since I cannot decipher the old code fully,  performance problem.  But since I cannot decipher the old code fully,
292  innstead of patching the problems up, I'm reimplementing it  instead of patching the problems up, I'm reimplementing it
293  with a different algorithm.  The new code is more modular,  with a different algorithm.  The new code is more modular,
294  smaller when compiled, and substantially faster  smaller when compiled, and substantially faster
295  (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:

Legend:
Removed from v.1098  
changed lines
  Added in v.1130

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