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 1094, Mon Feb 25 09:58:56 2002 UTC revision 1128, Fri Mar 8 21:05:27 2002 UTC
# Line 13  Line 13 
13  Description:  Description:
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16    Name: Matthias Blume
17    Date: 2002/03/08 16:05:00
18    Tag: blume-20020308-entrypoints
19    Description:
21    Version number bumped to 110.39.1.  NEW BOOTFILES!
23    Entrypoints: non-zero offset into a code object where execution should begin.
25    - Added the notion of an entrypoint to CodeObj.
26    - Added reading/writing of entrypoint info to Binfile.
27    - Made runtime system bootloader aware of entrypoints.
28    - Use the address of the label of the first function given to mlriscGen
29      as the entrypoint.  This address is currently always 0, but it will
30      not be 0 once we turn on block placement.
31    - Removed the linkage cluster code (which was The Other Way(tm) of dealing
32      with entry points) from mlriscGen.
34    ----------------------------------------------------------------------
35    Name: Allen Leung
36    Date: 2002/03/07 20:45:00 EST
37    Tag: leunga-20020307-x86-cmov
38    Description:
40       Bug fixes for CMOVcc on x86.
42       1. Added machine code generation for CMOVcc
43       2. CMOVcc is now generated in preference over SETcc on PentiumPro or above.
44       3. CMOVcc cannot have an immediate operand as argument.
46    ----------------------------------------------------------------------
47    Name: Matthias Blume
48    Date: 2002/03/07 16:15:00 EST
49    Tag: blume-20020307-controls
50    Description:
52    This is a very large but mostly boring patch which makes (almost)
53    every tuneable compiler knob (i.e., pretty much everything under
54    Control.* plus a few other things) configurable via both the command
55    line and environment variables in the style CM did its configuration
56    until now.
58    Try starting sml with '-h' (or, if you are brave, '-H')
60    To this end, I added a structure Controls : CONTROLS to smlnj-lib.cm which
61    implements the underlying generic mechanism.
63    The interface to some of the existing such facilities has changed somewhat.
64    For example, the MLRiscControl module now provides mkFoo instead of getFoo.
65    (The getFoo interface is still there for backward-compatibility, but its
66    use is deprecated.)
68    The ml-build script passes -Cxxx=yyy command-line arguments through so
69    that one can now twiddle the compiler settings when using this "batch"
70    compiler.
72    TODO items:
74    We should go through and throw out all controls that are no longer
75    connected to anything.  Moreover, we should go through and provide
76    meaningful (and correct!) documentation strings for those controls
77    that still are connected.
79    Currently, multiple calls to Controls.new are accepted (only the first
80    has any effect).  Eventually we should make sure that every control
81    is being made (via Controls.new) exactly once.  Future access can then
82    be done using Controls.acc.
84    Finally, it would probably be a good idea to use the getter-setter
85    interface to controls rather than ref cells.  For the time being, both
86    styles are provided by the Controls module, but getter-setter pairs are
87    better if thread-safety is of any concern because they can be wrapped.
89    *****************************************
91    One bug fix: The function blockPlacement in three of the MLRISC
92    backpatch files used to be hard-wired to one of two possibilities at
93    link time (according to the value of the placementFlag).  But (I
94    think) it should rather sense the flag every time.
96    *****************************************
98    Other assorted changes (by other people who did not supply a HISTORY entry):
100    1. the cross-module inliner now works much better (Monnier)
101    2. representation of weights, frequencies, and probabilities in MLRISC
102       changed in preparation of using those for weighted block placement
103       (Reppy, George)
105    ----------------------------------------------------------------------
106    Name: Lal George
107    Date: 2002/03/07 14:44:24 EST 2002
108    Tag: george-20020307-weighted-block-placement
110    Tested the weighted block placement optimization on all architectures
111    (except the hppa) using AMPL to generate the block and edge frequencies.
112    Changes were required in the machine properties to correctly
113    categorize trap instructions. There is an MLRISC flag
114    "weighted-block-placement" that can be used to enable weighted block
115    placement, but this will be ineffective without block/edge
116    frequencies (coming soon).
119    ----------------------------------------------------------------------
120    Name: Lal George
121    Date: 2002/03/05 17:24:48 EST
122    Tag: george-20020305-linkage-cluster
124    In order to support the block placement optimization, a new cluster
125    is generated as the very first cluster (called the linkage cluster).
126    It contains a single jump to the 'real' entry point for the compilation
127    unit. Block placement has no effect on the linkage cluster itself, but
128    all the other clusters  have full freedom in the manner in which they
129    reorder blocks or functions.
131    On the x86 the typical linkage code that is generated is:
132       ----------------------
133            .align 2
134       L0:
135            addl    $L1-L0, 72(%esp)
136            jmp     L1
139            .align  2
140       L1:
141       ----------------------
143    72(%esp) is the memory location for the stdlink register. This
144    must contain the address of the CPS function being called. In the
145    above example, it contains the address of  L0; before
146    calling L1 (the real entry point for the compilation unit), it
147    must contain the address for L1, and hence
149            addl $L1-L0, 72(%esp)
151    I have tested this on all architectures except the hppa.The increase
152    in code size is of course negligible
154    ----------------------------------------------------------------------
155    Name: Allen Leung
156    Date: 2002/03/03 13:20:00 EST
157    Tag: leunga-20020303-mlrisc-tools
159      Added #[ ... ] expressions to mlrisc tools
161    ----------------------------------------------------------------------
162    Name: Matthias Blume
163    Date: 2002/02/27 12:29:00 EST
164    Tag: blume-20020227-cdebug
165    Description:
167    - made types in structure C and C_Debug to be equal
168    - got rid of code duplication (c-int.sml vs. c-int-debug.sml)
169    - there no longer is a C_Int_Debug (C_Debug is directly derived from C)
171    ----------------------------------------------------------------------
172    Name: Matthias Blume
173    Date: 2002/02/26 12:00:00 EST
174    Tag: blume-20020226-ffi
175    Description:
177    1. Fixed a minor bug in CM's "noweb" tool:
178       If numbering is turned off, then truly don't number (i.e., do not
179       supply the -L option to noweb).  The previous behavior was to supply
180       -L'' -- which caused noweb to use the "default" line numbering scheme.
181       Thanks to Chris Richards for pointing this out (and supplying the fix).
183    2. Once again, I reworked some aspects of the FFI:
185       A. The incomplete/complete type business:
187       - Signatures POINTER_TO_INCOMPLETE_TYPE and accompanying functors are
188         gone!
189       - ML types representing an incomplete type are now *equal* to
190         ML types representing their corresponding complete types (just like
191         in C).  This is still safe because ml-nlffigen will not generate
192         RTTI for incomplete types, nor will it generate functions that
193         require access to such RTTI.   But when ML code generated from both
194         incomplete and complete versions of the C type meet, the ML types
195         are trivially interoperable.
197         NOTE:  These changes restore the full generality of the translation
198         (which was previously lost when I eliminated functorization)!
200       B. Enum types:
202       - Structure C now has a type constructor "enum" that is similar to
203         how the "su" constructor works.  However, "enum" is not a phantom
204         type because each "T enum" has values (and is isomorphic to
205         MLRep.Signed.int).
206       - There are generic access operations for enum objects (using
207         MLRep.Signed.int).
208       - ml-nlffigen will generate a structure E_foo for each "enum foo".
209         * The structure contains the definition of type "mlrep" (the ML-side
210         representation type of the enum).  Normally, mlrep is the same
211         as "MLRep.Signed.int", but if ml-nlffigen was invoked with "-ec",
212         then mlrep will be defined as a datatype -- thus facilitating
213         pattern matching on mlrep values.
214         ("-ec" will be suppressed if there are duplicate values in an
215          enumeration.)
216         * Constructors ("-ec") or values (no "-ec") e_xxx of type mlrep
217         will be generated for each C enum constant xxx.
218         * Conversion functions m2i and i2m convert between mlrep and
219         MLRep.Signed.int.  (Without "-ec", these functions are identities.)
220         * Coversion functions c and ml convert between mlrep and "tag enum".
221         * Access functions (get/set) fetch and store mlrep values.
222       - By default (unless ml-nlffigen was invoked with "-nocollect"), unnamed
223         enumerations are merged into one single enumeration represented by
224         structure E_'.
226    ----------------------------------------------------------------------
227  Name: Allen Leung  Name: Allen Leung
228  Date: 2002/02/25 04:45:00 EST  Date: 2002/02/25 04:45:00 EST
229  Tag: leunga-20020225-cps-spill  Tag: leunga-20020225-cps-spill
# Line 69  Line 280 
280         TOTAL                                   2375.26u  57.21s  48.00g         TOTAL                                   2375.26u  57.21s  48.00g
282  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
283  performance problem but since I cannot decipher the old code fully,  performance problem.  But since I cannot decipher the old code fully,
284  innstead of patching the problems up, I'm reimplementing it  instead of patching the problems up, I'm reimplementing it
285  with a different algorithm.  The new code is more modular,  with a different algorithm.  The new code is more modular,
286  smaller when compiled, and substantially faster  smaller when compiled, and substantially faster
287  (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:

Removed from v.1094  
changed lines
  Added in v.1128

ViewVC Help
Powered by ViewVC 1.0.0