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

Legend:
Removed from v.1115  
changed lines
  Added in v.1131

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