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 1116, Tue Mar 5 23:17:18 2002 UTC revision 1133, Tue Mar 12 03:56:23 2002 UTC
# Line 14  Line 14 
14    
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16  Name: Lal George  Name: Lal George
17    Date: 2002/03/11 11 22:38:53 EST
18    Tag: george-20020311-jump-chain-elim
19    Description:
20    
21    Tested the jump chain elimination on all architectures (except the
22    hppa).  This is on by default right now and is profitable for the
23    alpha and x86, however, it may not be profitable for the sparc and ppc
24    when compiling the compiler.
25    
26    The gc test will typically jump to a label at the end of the cluster,
27    where there is another jump to an external cluster containing the actual
28    code to invoke gc. This is to allow factoring of common gc invocation
29    sequences. That is to say, we generate:
30    
31            f:
32               testgc
33               ja   L1      % jump if above to L1
34    
35            L1:
36               jmp L2
37    
38    
39    After jump chain elimination the 'ja L1' instructions is converted to
40    'ja L2'. On the sparc and ppc, many of the 'ja L2' instructions may end
41    up being implemented in their long form (if L2 is far away) using:
42    
43            jbe     L3      % jump if below or equal to L3
44            jmp     L2
45         L3:
46            ...
47    
48    
49    For large compilation units L2  may be far away.
50    
51    
52    ----------------------------------------------------------------------
53    Name: Matthias Blume
54    Date: 2002/03/11 13:30:00 EST
55    Tag: blume-20020311-mltreeeval
56    Description:
57    
58    A functor parameter was missing.
59    
60    ----------------------------------------------------------------------
61    Name: Allen Leung
62    Date: 2002/03/11 10:30:00 EST
63    Tag: leunga-20020310-runtime-string0
64    Description:
65    
66       The representation of the empty string now points to a
67    legal null terminated C string instead of unit.  It is now possible
68    to convert an ML string into C string with InlineT.CharVector.getData.
69    This compiles into one single machine instruction.
70    
71    ----------------------------------------------------------------------
72    Name: Allen Leung
73    Date: 2002/03/10 23:55:00 EST
74    Tag: leunga-20020310-x86-call
75    Description:
76    
77       Added machine generation for CALL instruction (relative displacement mode)
78    
79    ----------------------------------------------------------------------
80    Name: Matthias Blume
81    Date: 2002/03/08 16:05:00
82    Tag: blume-20020308-entrypoints
83    Description:
84    
85    Version number bumped to 110.39.1.  NEW BOOTFILES!
86    
87    Entrypoints: non-zero offset into a code object where execution should begin.
88    
89    - Added the notion of an entrypoint to CodeObj.
90    - Added reading/writing of entrypoint info to Binfile.
91    - Made runtime system bootloader aware of entrypoints.
92    - Use the address of the label of the first function given to mlriscGen
93      as the entrypoint.  This address is currently always 0, but it will
94      not be 0 once we turn on block placement.
95    - Removed the linkage cluster code (which was The Other Way(tm) of dealing
96      with entry points) from mlriscGen.
97    
98    ----------------------------------------------------------------------
99    Name: Allen Leung
100    Date: 2002/03/07 20:45:00 EST
101    Tag: leunga-20020307-x86-cmov
102    Description:
103    
104       Bug fixes for CMOVcc on x86.
105    
106       1. Added machine code generation for CMOVcc
107       2. CMOVcc is now generated in preference over SETcc on PentiumPro or above.
108       3. CMOVcc cannot have an immediate operand as argument.
109    
110    ----------------------------------------------------------------------
111    Name: Matthias Blume
112    Date: 2002/03/07 16:15:00 EST
113    Tag: blume-20020307-controls
114    Description:
115    
116    This is a very large but mostly boring patch which makes (almost)
117    every tuneable compiler knob (i.e., pretty much everything under
118    Control.* plus a few other things) configurable via both the command
119    line and environment variables in the style CM did its configuration
120    until now.
121    
122    Try starting sml with '-h' (or, if you are brave, '-H')
123    
124    To this end, I added a structure Controls : CONTROLS to smlnj-lib.cm which
125    implements the underlying generic mechanism.
126    
127    The interface to some of the existing such facilities has changed somewhat.
128    For example, the MLRiscControl module now provides mkFoo instead of getFoo.
129    (The getFoo interface is still there for backward-compatibility, but its
130    use is deprecated.)
131    
132    The ml-build script passes -Cxxx=yyy command-line arguments through so
133    that one can now twiddle the compiler settings when using this "batch"
134    compiler.
135    
136    TODO items:
137    
138    We should go through and throw out all controls that are no longer
139    connected to anything.  Moreover, we should go through and provide
140    meaningful (and correct!) documentation strings for those controls
141    that still are connected.
142    
143    Currently, multiple calls to Controls.new are accepted (only the first
144    has any effect).  Eventually we should make sure that every control
145    is being made (via Controls.new) exactly once.  Future access can then
146    be done using Controls.acc.
147    
148    Finally, it would probably be a good idea to use the getter-setter
149    interface to controls rather than ref cells.  For the time being, both
150    styles are provided by the Controls module, but getter-setter pairs are
151    better if thread-safety is of any concern because they can be wrapped.
152    
153    *****************************************
154    
155    One bug fix: The function blockPlacement in three of the MLRISC
156    backpatch files used to be hard-wired to one of two possibilities at
157    link time (according to the value of the placementFlag).  But (I
158    think) it should rather sense the flag every time.
159    
160    *****************************************
161    
162    Other assorted changes (by other people who did not supply a HISTORY entry):
163    
164    1. the cross-module inliner now works much better (Monnier)
165    2. representation of weights, frequencies, and probabilities in MLRISC
166       changed in preparation of using those for weighted block placement
167       (Reppy, George)
168    
169    ----------------------------------------------------------------------
170    Name: Lal George
171    Date: 2002/03/07 14:44:24 EST 2002
172    Tag: george-20020307-weighted-block-placement
173    
174    Tested the weighted block placement optimization on all architectures
175    (except the hppa) using AMPL to generate the block and edge frequencies.
176    Changes were required in the machine properties to correctly
177    categorize trap instructions. There is an MLRISC flag
178    "weighted-block-placement" that can be used to enable weighted block
179    placement, but this will be ineffective without block/edge
180    frequencies (coming soon).
181    
182    
183    ----------------------------------------------------------------------
184    Name: Lal George
185  Date: 2002/03/05 17:24:48 EST  Date: 2002/03/05 17:24:48 EST
186  Tag: george-20020305-linkage-cluster  Tag: george-20020305-linkage-cluster
187    
188  In order to support the block placement optimization, the first  In order to support the block placement optimization, a new cluster
189  cluster that is generated (called the linkage cluster) contains a jump  is generated as the very first cluster (called the linkage cluster).
190  to the entry point for the compilation unit. The linkage cluster  It contains a single jump to the 'real' entry point for the compilation
191  contains only one function, so block placement will have no effect on  unit. Block placement has no effect on the linkage cluster itself, but
192  the linkage cluster itself, but all the other clusters have full  all the other clusters  have full freedom in the manner in which they
193  freedom in the manner in which they reorder blocks or functions.  reorder blocks or functions.
194    
195  On the x86 the typical linkage code that is generated is:  On the x86 the typical linkage code that is generated is:
196     ----------------------     ----------------------
197          .align 2          .align 2
198     L0:     L0:
199          addl    $L1-L0, 72(%esp)          addl    $L1-L0, 72(%esp)
200          jmp     L0          jmp     L1
201    
202    
203          .align  2          .align  2
# Line 38  Line 206 
206    
207  72(%esp) is the memory location for the stdlink register. This  72(%esp) is the memory location for the stdlink register. This
208  must contain the address of the CPS function being called. In the  must contain the address of the CPS function being called. In the
209  above example, it contains the address of memory for  L0; before  above example, it contains the address of  L0; before
210  calling L1 (the real entry point for the compilation unit), it  calling L1 (the real entry point for the compilation unit), it
211  must contain the address for L1, and hence  must contain the address for L1, and hence
212    
213          addl $L1-L0, 72(%esp)          addl $L1-L0, 72(%esp)
214    
215  I have tested this on all architectures except the hppa.  I have tested this on all architectures except the hppa.The increase
216    in code size is of course negligible
217    
218  ----------------------------------------------------------------------  ----------------------------------------------------------------------
219  Name: Allen Leung  Name: Allen Leung

Legend:
Removed from v.1116  
changed lines
  Added in v.1133

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