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 1168, Fri Mar 22 19:19:32 2002 UTC revision 1183, Fri Mar 29 19:09:48 2002 UTC
# Line 13  Line 13 
13  Description:  Description:
14    
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16    Name: Matthias Blume
17    Date: 2002/03/29 14:10:00 EST
18    Tag: blume-20020329-inlprims
19    Description:
20    
21    NEW BOOTFILES!!!    Version number bumped to 110.39.3.
22    
23    Primops have changed. This means that the bin/boot-file formats have
24    changed as well.
25    
26    To make sure that there is no confusion, I made a new version.
27    
28    
29    CHANGES:
30    
31    * removed REMT from mltree (remainder should never overflow).
32    
33    * added primops to deal with divisions of all flavors to the frontend
34    
35    * handled these primops all the way through so they map to their respective
36      MLRISC support
37    
38    * used these primops in the implementation of Int, Int32, Word, Word32
39    
40    * removed INLDIV, INLMOD, and INLREM as they are no longer necessary
41    
42    * parameterized INLMIN, INLMAX, and INLABS by a numkind
43    
44    * translate.sml now deals with all flavors of INL{MIN,MAX,ABS}, including
45      floating point
46    
47    * used INL{MIN,MAX,ABS} in the implementation of Int, Int32, Word, Word32,
48      and Real (but Real.abs maps to a separate floating-point-only primop)
49    
50    
51    TODO items:
52    
53    * Hacked Alpha32 instruction selection, disabling the selection of REMx
54      instructions because the machine instruction encoder cannot handle
55      them.  (Hppa, PPC, and Sparc instruction selection did not handle
56      REM in the first place, and REM is supported by the x86 machine coder.)
57    
58    * Handle DIV and MOD with DIV_TO_NEGINF directly in the x86 instruction
59      selection phase.  (The two can be streamlined because the hardware
60      delivers both quotient and remainder at the same time anyway.)
61    
62    * Think about what to do with "valOf(Int32.minInt) div ~1" and friends.
63      (Currently the behavior is inconsistent both across architectures and
64      wrt. the draft Basis spec.)
65    
66    * Word8 should eventually be handled natively, too.
67    
68    * There seems to be one serious bug in mltree-gen.sml.  It appears, though,
69      as if there currently is no execution path that could trigger it in
70      SML/NJ.  (The assumptions underlying functions arith and promotable do not
71      hold for things like multiplication and division.)
72    
73    ----------------------------------------------------------------------
74    Name: Matthias Blume
75    Date: 2002/03/27 16:27:00 EST
76    Tag: blume-20020327-mlrisc-divisions
77    Description:
78    
79    Added support for all four division operations (ML's div, mod, quot,
80    and rem) to MLRISC.  In the course of doing so, I also rationalized
81    the naming (no more annoying switch-around of DIV and QUOT), by
82    parameterizing the operation by div_rounding_mode (which can be either
83    DIV_TO_ZERO or DIV_TO_NEGINF).
84    
85    The generic MLTreeGen functor takes care of compiling all four
86    operations down to only round-to-zero div.
87    
88    Missing pieces:
89    
90      * Doing something smarter than relying on MLTreeGen on architectures
91        like, e.g., the x86 where hardware division delivers both quotient and
92        remainder at the same time.  With this, the implementation of the
93        round-to-neginf operations could be further streamlined.
94    
95      * Remove inlining support for div/mod/rem from the frontend and replace it
96        with primops that get carried through to the backend.  Do this for all
97        int and word types.
98    
99    ----------------------------------------------------------------------
100    Name: Matthias Blume
101    Date: 2002/03/25 17:25:00 EST
102    Tag: blume-20020325-divmod
103    Description:
104    
105    I improved (hopefully without breaking them) the implementation of Int.div,
106    Int.mod, and Int.rem.   For this, the code in translate.sml now takes
107    advantage of the following observations:
108    
109      Let  q = x quot y      r = x rem y
110           d = x div  y      m = x mod y
111    
112    where "quot" is the round-to-zero version of integer division that
113    hardware usually provides.  Then we have:
114    
115         r = x - q * y        where neither the * nor the - will overflow
116         d = if q >= 0 orelse x = q * y then q else q - 1
117                              where neither the * nor the - will overflow
118         m = if q >= 0 orelse r = 0 then r else r + y
119                              where the + will not overflow
120    
121    This results in substantial simplification of the generated code.
122    The following table shows the number of CFG nodes and edges generated
123    for
124            fun f (x, y) = x OPER y
125            (* with OPER \in div, mod, quot, rem *)
126    
127    
128        OPER | nodes(old) | edges(old) | nodes(new) | edges(new)
129        --------------------------------------------------------
130         div |         24 |         39 |         12 |         16
131         mod |         41 |         71 |         12 |         16
132        quot |          8 |         10 |          8 |         10
133         rem |         10 |         14 |          8 |         10
134    
135    
136    ----------------------------------------------------------------------
137    Name: Matthias Blume
138    Date: 2002/03/25 22:06:00 EST
139    Tag: blume-20020325-cprotobug
140    Description:
141    
142    Fixed a bug in cproto (c prototype decoder).
143    
144    ----------------------------------------------------------------------
145    Name: Matthias Blume
146    Date: 2002/03/25 16:00:00 EST
147    Tag: blume-20020325-raw-primops
148    Description:
149    
150    I did some cleanup to Allen's new primop code and
151    replaced yesterday's bootfiles with new ones.
152    (But they are stored in the same place.)
153    
154    ----------------------------------------------------------------------
155    Name: Matthias Blume
156    Date: 2002/03/24 22:40:00 EST
157    Tag: blume-20020324-bootfiles
158    Description:
159    
160    Made the bootfiles that Allen asked for.
161    
162    ----------------------------------------------------------------------
163    Name: Allen Leung
164    Date: 2002/03/23 15:50:00 EST
165    Tag: leunga-20020323-flint-cps-rcc-primops
166    Description:
167    
168      1. Changes to FLINT primops:
169    
170        (* make a call to a C-function;
171         * The primop carries C function prototype information and specifies
172         * which of its (ML-) arguments are floating point. C prototype
173         * information is for use by the backend, ML information is for
174         * use by the CPS converter. *)
175      | RAW_CCALL of { c_proto: CTypes.c_proto,
176                       ml_args: ccall_type list,
177                       ml_res_opt: ccall_type option,
178                       reentrant : bool
179                     } option
180       (* Allocate uninitialized storage on the heap.
181        * The record is meant to hold short-lived C objects, i.e., they
182        * are not ML pointers.  With the tag, the representation is
183        * the same as RECORD with tag tag_raw32 (sz=4), or tag_fblock (sz=8)
184        *)
185      | RAW_RECORD of {tag:bool,sz:int}
186      and ccall_type = CCALL_INT32 | CCALL_REAL64 | CCALL_ML_PTR
187    
188      2.  These CPS primops are now overloaded:
189    
190           rawload of {kind:numkind}
191           rawstore of {kind:numkind}
192    
193          The one argument form is:
194    
195             rawload {kind} address
196    
197          The two argument form is:
198    
199             rawload {kind} [ml object, byte-offset]
200    
201      3. RAW_CCALL/RCC now takes two extra arguments:
202    
203         a. The first is whether the C call is reentrant, i.e., whether
204            ML state should be saved and restored.
205         b. The second argument is a string argument specifying the name of
206            library and the C function.
207    
208         These things are currently not handled in the code generator, yet.
209    
210      4. In CProto,
211    
212         An encoding type of "bool" means "ml object" and is mapped into
213         C prototype of PTR.  Note that "bool" is different than "string",
214         even though "string" is also mapped into PTR, because "bool"
215         is assigned an CPS type of BOGt, while "string" is assigned INT32t.
216    
217      5. Pickler/unpicker
218    
219         Changed to handle RAW_RECORD and newest RAW_CCALL
220    
221      6. MLRiscGen,
222    
223         1. Changed to handle the new rawload/rawstore/rawrecord operators.
224         2. Code for handling C Calls has been moved to a new module CPSCCalls,
225            in the file CodeGen/cpscompile/cps-c-calls.sml
226    
227      7. Added the conditional move operator
228    
229             condmove of branch
230    
231         to cps.  Generation of this is still buggy so it is currently
232         disabled.
233    
234    ----------------------------------------------------------------------
235  Name: Lal George  Name: Lal George
236  Date: 2002/03/22 14:18:25 EST  Date: 2002/03/22 14:18:25 EST
237  Tag: blume-20020321-cps-branch-prob  Tag: george-20020322-cps-branch-prob
238  Description:  Description:
239    
240  Implemented the Ball-Larus branch prediction-heuristic, and  Implemented the Ball-Larus branch prediction-heuristics, and
241  incorporated graphical viewers for control flow graphs.  incorporated graphical viewers for control flow graphs.
242    
243  Ball-Larus Heuristic:  Ball-Larus Heuristics:
244  ---------------------  ---------------------
245  See the file compiler/CodeGen/cpscompile/cpsBranchProb.sml.  See the file compiler/CodeGen/cpscompile/cpsBranchProb.sml.
246    
# Line 33  Line 252 
252  the ball-larus heuristics predicts that the n=0 is unlikely  the ball-larus heuristics predicts that the n=0 is unlikely
253  (OH-heuristic), and the 'then' branch is unlikely because of the  (OH-heuristic), and the 'then' branch is unlikely because of the
254  RH-heuristic -- giving the 'then' branch an even lower combined  RH-heuristic -- giving the 'then' branch an even lower combined
255  probability using the Dempster-Shater theory.  probability using the Dempster-Shafer theory.
256    
257  Finally, John Reppy's loop analysis in MLRISC, further lowers the  Finally, John Reppy's loop analysis in MLRISC, further lowers the
258  probability of the 'then' branch because of the loop in the else  probability of the 'then' branch because of the loop in the else

Legend:
Removed from v.1168  
changed lines
  Added in v.1183

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