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 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  Name: Lal George
129  Date: 2002/03/05 17:24:48 EST  Date: 2002/03/05 17:24:48 EST
130  Tag: george-20020305-linkage-cluster  Tag: george-20020305-linkage-cluster
131    
132  In order to support the block placement optimization, the first  In order to support the block placement optimization, a new cluster
133  cluster that is generated (called the linkage cluster) contains a jump  is generated as the very first cluster (called the linkage cluster).
134  to the entry point for the compilation unit. The linkage cluster  It contains a single jump to the 'real' entry point for the compilation
135  contains only one function, so block placement will have no effect on  unit. Block placement has no effect on the linkage cluster itself, but
136  the linkage cluster itself, but all the other clusters have full  all the other clusters  have full freedom in the manner in which they
137  freedom in the manner in which they reorder blocks or functions.  reorder blocks or functions.
138    
139  On the x86 the typical linkage code that is generated is:  On the x86 the typical linkage code that is generated is:
140     ----------------------     ----------------------
141          .align 2          .align 2
142     L0:     L0:
143          addl    $L1-L0, 72(%esp)          addl    $L1-L0, 72(%esp)
144          jmp     L0          jmp     L1
145    
146    
147          .align  2          .align  2
# Line 38  Line 150 
150    
151  72(%esp) is the memory location for the stdlink register. This  72(%esp) is the memory location for the stdlink register. This
152  must contain the address of the CPS function being called. In the  must contain the address of the CPS function being called. In the
153  above example, it contains the address of memory for  L0; before  above example, it contains the address of  L0; before
154  calling L1 (the real entry point for the compilation unit), it  calling L1 (the real entry point for the compilation unit), it
155  must contain the address for L1, and hence  must contain the address for L1, and hence
156    
157          addl $L1-L0, 72(%esp)          addl $L1-L0, 72(%esp)
158    
159  I have tested this on all architectures except the hppa.  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  Name: Allen Leung

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

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