This file is indexed.

/usr/share/doc/smlnj-doc/mlrisc/mltree.html is in smlnj-doc 110.78-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- Generated by mltex2html -->
<!-- do not edit this file -->

<html>
  <head>
     <title> The MLTREE Language </title>
  </head>
  <body bgcolor="#ffffff" text="#000020" 
   link="navy" vlink="gray" alink="maroon">
  <table border=0> 
  <tr>
          <td valign=top align=left width="170">
     <!-- table of contents -->
  <table cellpadding=0 cellspacing=0 border=0 width=170 bgcolor="#e6e6e6"> 
  <tr><td>
    </td></tr><tr><td>
    <table bgcolor="#486591" width="100%" border=0 
      cellpadding=0 cellspacing=0>
    <tr><td align=center><font color="ffffff">
    MLRISC
    </font>
    </td></tr></table><tr><td>
     <a href="INTRO.html"><font size="-1">MLRISC</font></a><br>
     <a href="contributors.html"><font size="-1">Contributors</font></a><br>
     <a href="requirements.html"><font size="-1">Requirements</font></a><br>
     <a href="availability.html"><font size="-1">How to Obtain MLRISC</font></a><br>
    </td></tr><tr><td>
    <table bgcolor="#486591" width="100%" border=0 
      cellpadding=0 cellspacing=0>
    <tr><td align=center><font color="ffffff">
    Overview
    </font>
    </td></tr></table><tr><td>
     <a href="problem.html"><font size="-1">Problem Statement</font></a><br>
     <a href="contributions.html"><font size="-1">Contributions</font></a><br>
     <a href="mlrisc-compiler.html"><font size="-1">MLRISC Based Compiler</font></a><br>
     <a href="mlrisc-ir-rep.html"><font size="-1">MLRISC Intermediate Representation</font></a><br>
     <a href="mlrisc-gen.html"><font size="-1">MLRisc Generation</font></a><br>
     <a href="backend-opt.html"><font size="-1">Back End Optimizations</font></a><br>
     <a href="mlrisc-ra.html"><font size="-1">Register Allocation</font></a><br>
     <a href="mlrisc-md.html"><font size="-1">Machine Description</font></a><br>
     <a href="gc.html"><font size="-1">Garbage Collection Safety</font></a><br>
     <a href="sys-integration.html"><font size="-1">System Integration</font></a><br>
     <a href="optimizations.html"><font size="-1">Optimizations</font></a><br>
     <a href="mlrisc-graphics.html"><font size="-1">Graphical Interface</font></a><br>
     <a href="line-counts.html"><font size="-1">Line Counts</font></a><br>
     <a href="systems.html"><font size="-1">Systems Using MLRISC</font></a><br>
     <a href="future-work.html"><font size="-1">Future Work</font></a><br>
    </td></tr><tr><td>
    <table bgcolor="#486591" width="100%" border=0 
      cellpadding=0 cellspacing=0>
    <tr><td align=center><font color="ffffff">
    System
    </font>
    </td></tr></table><tr><td>
     <a href="mlrisc-arch.html"><font size="-1">Architecture of MLRISC</font></a><br>
     <a href="mltree.html"><font size="-1"><font color="#486591"><b>The MLTREE Language</b></font></font></a><br>
     <a href="mltree-ext.html"><font size="-1">MLTree Extensions</font></a><br>
     <a href="mltree-util.html"><font size="-1">MLTree Utilities</font></a><br>
     <a href="instrsel.html"><font size="-1">Instruction Selection</font></a><br>
     <a href="asm.html"><font size="-1">Assemblers</font></a><br>
     <a href="mc.html"><font size="-1">Machine Code Emitters</font></a><br>
     <a href="delayslots.html"><font size="-1">Delay Slot Filling</font></a><br>
     <a href="span-dep.html"><font size="-1">Span Dependency Resolution</font></a><br>
     <a href="graphs.html"><font size="-1">The Graph Library</font></a><br>
     <a href="graphics.html"><font size="-1">The Graph Visualization Library</font></a><br>
     <a href="compiler-graphs.html"><font size="-1">Basic Compiler Graphs</font></a><br>
     <a href="mlrisc-ir.html"><font size="-1">The MLRISC IR</font></a><br>
     <a href="SSA.html"><font size="-1">SSA Optimizations</font></a><br>
     <a href="ILP.html"><font size="-1">ILP Optimizations</font></a><br>
     <a href="VLIW.html"><font size="-1">Optimizations for VLIW/EPIC Architectur...</font></a><br>
     <a href="ra.html"><font size="-1">Register Allocator</font></a><br>
    </td></tr><tr><td>
    <table bgcolor="#486591" width="100%" border=0 
      cellpadding=0 cellspacing=0>
    <tr><td align=center><font color="ffffff">
    Back Ends
    </font>
    </td></tr></table><tr><td>
     <a href="alpha.html"><font size="-1">The Alpha Back End</font></a><br>
     <a href="hppa.html"><font size="-1">The PA RISC Back End</font></a><br>
     <a href="sparc.html"><font size="-1">The Sparc Back End</font></a><br>
     <a href="x86.html"><font size="-1">The Intel x86 Back End</font></a><br>
     <a href="ppc.html"><font size="-1">The PowerPC Back End</font></a><br>
     <a href="mips.html"><font size="-1">The MIPS Back End</font></a><br>
     <a href="C6.html"><font size="-1">The TI C6x Back End</font></a><br>
    </td></tr><tr><td>
    <table bgcolor="#486591" width="100%" border=0 
      cellpadding=0 cellspacing=0>
    <tr><td align=center><font color="ffffff">
    Basic Types
    </font>
    </td></tr></table><tr><td>
     <a href="annotations.html"><font size="-1">Annotations</font></a><br>
     <a href="cells.html"><font size="-1">Cells</font></a><br>
     <a href="cluster.html"><font size="-1">Cluster</font></a><br>
     <a href="constants.html"><font size="-1">Client Defined Constants</font></a><br>
     <a href="pseudo-ops.html"><font size="-1">Client Defined Pseudo Ops</font></a><br>
     <a href="instructions.html"><font size="-1">Instructions</font></a><br>
     <a href="streams.html"><font size="-1">Instruction Streams</font></a><br>
     <a href="labelexp.html"><font size="-1">Label Expressions</font></a><br>
     <a href="labels.html"><font size="-1">Labels</font></a><br>
     <a href="regions.html"><font size="-1">Regions</font></a><br>
     <a href="regmap.html"><font size="-1">Regmap</font></a><br>
   </td></tr>
  </table>
  <!-- end of table of contents -->

      </td>

    <td width=2> </td>
    <td valign=top align=left> 
    <center><h1><font color="#486591"><b>The MLTREE Language</b></font></h1></center>
    <hr> 
      <!-- table of contents -->
  <table cellpadding=0 cellspacing=0 border=0 align=right bgcolor="#e6e6e6"> 
  <tr><td>
    </td></tr><tr><td>
    <table bgcolor="#486591" width="100%" border=0 
      cellpadding=0 cellspacing=0>
    <tr><td align=center><font color="ffffff">
    The MLTREE Language
    </font>
    </td></tr></table><tr><td>
     <a href="#link0000"><font size="-1" color="#486591">The Definitions</font></a><br>
     -<a href="#link0001"><font size="-1" color="#486591">Basic Types</font></a><br>
     -<a href="#link0002"><font size="-1" color="#486591">The Basis</font></a><br>
     <a href="#link0003"><font size="-1" color="#486591">Integer Expressions</font></a><br>
     -<a href="#link0004"><font size="-1" color="#486591">Sign and Zero Extension</font></a><br>
     -<a href="#link0005"><font size="-1" color="#486591">Conditional Move</font></a><br>
     -<a href="#link0006"><font size="-1" color="#486591">Integer Loads</font></a><br>
     -<a href="#link0007"><font size="-1" color="#486591">Miscellaneous Integer Operators</font></a><br>
     <a href="#link0008"><font size="-1" color="#486591">Floating Point Expressions</font></a><br>
     <a href="#link0009"><font size="-1" color="#486591">Condition Expressions</font></a><br>
     <a href="#link0010"><font size="-1" color="#486591">Statements</font></a><br>
     -<a href="#link0011"><font size="-1" color="#486591">Assignments</font></a><br>
     -<a href="#link0012"><font size="-1" color="#486591">Parallel Copies</font></a><br>
     -<a href="#link0013"><font size="-1" color="#486591">Jumps and Conditional Branches</font></a><br>
     -<a href="#link0014"><font size="-1" color="#486591">Calls and Returns</font></a><br>
     -<a href="#link0015"><font size="-1" color="#486591">Stores</font></a><br>
     -<a href="#link0016"><font size="-1" color="#486591">Miscelleneous Statements</font></a><br>
     <a href="#link0017"><font size="-1" color="#486591">Annotations</font></a><br>
   </td></tr>
  </table>
  <!-- end of table of contents -->

    
 
 <font color="#ff0000">MLTree</font> is the 
 register transfer language used in the MLRISC system.
 It serves two important purposes:
 <img alt="MLTree" src=pictures/png/mlrisc-ir.png align=right>
 <ol>
 <li> As an intermediate representation for a compiler front-end 
   to talk to the MLRISC system,
 <li> As specifications for instruction semantics
 </ol>
 The latter is needed for optimizations which require precise knowledge of such;
 for example, algebraic simplification and constant folding.
 <p>
 MLTree is a low-level <font color="#ff0000">typed</font> language: 
 all operations are typed by its width or precision.  
 Operations on floating point, integer, and condition code 
 are also segregated, to prevent accidental misuse. 
 MLTree is also <em>tree-oriented</em> so that it is possible to write efficient
 MLTree transformation routines that uses SML pattern matching.
 <p>
 Here are a few examples of MLTree statements.
 <font color="#000000"><small><pre>
    MV(32,t,
       ADDT(32,
         MULT(32,REG(32,b),REG(32,b)),
         MULT(32,
           MULT(32,LI(4),REG(32,a)),REG(32,c))))
 </pre></small></font>
 computes <tt>t := b*b + 4*a*c</tt>, all in 32-bit precision and overflow
 trap enabled; while
 <font color="#000000"><small><pre>
    MV(32,t,
       ADD(32,
         CVTI2I(32,SIGN_EXTEND,8,
           LOAD(8,
             ADD(32,REG(32,a),REG(32,i))))))
 </pre></small></font>
 loads the byte in address <tt>a+i</tt> and sign extend it to a 32-bit
 value. 
 <p>
 The statement
 <font color="#000000"><small><pre>
    IF([],CMP(64,GE,REG(64,a),LI 0),
          MV(64, t, REG(64, a)),
          MV(64, t, NEG(64, REG(64, a)))
      )
 </pre></small></font>
 in more traditional form means:
 <font color="#000000"><small><pre>
    if a &gt;= 0 then 
       t := a
    else
       t := -a
 </pre></small></font> 
 This example can be also expressed in a few different ways: 
 <ol>
    <li> With the conditional move construct described in 
 Section <a href="mltree.html#sec:cond-move">Conditional Move</a>:
      <font color="#000000"><small><pre>
     MV(64, t, 
        COND(CMP(64, GE, REG(64, a)), 
             REG(64, a), 
             NEG(64, REG(64, a))))
      </pre></small></font>
   <li> With explicit branching using the conditional branch
 construct <tt>BCC</tt>:
     <font color="#000000"><small><pre>
      MV(64, t, REG(64, a));
      BCC([], CMP(64, GE, REG(64, a)), L1);
      MV(64, t, NEG(64, REG(64, a)));
      DEFINE L1;
     </pre></small></font>
 </ol>
 <a name="link0000"></a>
<h2><font color="#486591">The Definitions</font></h2>

 
 MLTree is defined in the signature <a href="../../mltree/mltree.sig" target=code><tt>MLTREE</tt></a>
 and the functor <a href="../../mltree/mltree.sml" target=code><tt>MLTreeF</tt></a>
 <p>
 The functor <tt>MLTreeF</tt> is parameterized in terms of
 the label expression type, the client supplied region datatype,
 the instruction stream type, and the client defined MLTree extensions.
 <font color="#000000"><small><pre>
   <font color="#6060a0"><b>functor</b></font> MLTreeF
     (<font color="#6060a0"><b>structure</b></font> LabelExp : <a href="labelexp.html">LABELEXP</a>
      <font color="#6060a0"><b>structure</b></font> Region : <a href="regions.html">REGION</a>
      <font color="#6060a0"><b>structure</b></font> Stream : <a href="streams.html">INSTRUCTION_STREAM</a>
      <font color="#6060a0"><b>structure</b></font> Extension : <a href="../../mltree/mltree-extension.sig" target=code>MLTREE_EXTENSION</a>
     ) : MLTREE
 </pre></small></font>
 
 <a name="link0001"></a>
<h3><font color="#486591">Basic Types</font></h3>

 
   The basic types in MLTree are statements (<font color="#ff0000"><tt>stm</tt></font>)
 integer expressions (<font color="#ff0000"><tt>rexp</tt></font>), 
 floating point expression (<font color="#ff0000"><tt>fexp</tt></font>), 
 and conditional expressions (<font color="#ff0000"><tt>ccexp</tt></font>). 
 Statements are evaluated for their effects,
 while expressions are evaluated for their value. (Some expressions
 could also have trapping effects.  The semantics of traps are unspecified.)
 These types are parameterized by an extension
 type, which we can use to extend the set of MLTree 
 operators.  How this is used is described in Section <a href="mltree-ext.html#sec:mltree-extension">MLTree Extensions</a>.
 <p>
 References to registers are represented internally as integers, and are denoted
 as the type <tt>reg</tt>. In addition, we use the types <tt>src</tt> and <tt>dst</tt>
 as abbreviations for source and destination registers.
 <font color="#000000"><small><pre>
    <font color="#6060a0"><b>type</b></font> reg = int
    <font color="#6060a0"><b>type</b></font> src = reg
    <font color="#6060a0"><b>type</b></font> dst = reg
 </pre></small></font>
 
 All operators on MLTree are <em>typed</em>
 by the number of bits that 
 they work on.  For example, 32-bit addition between <tt>a</tt> and <tt>b</tt>
 is written as <tt>ADD(32,a,b)</tt>, while 64-bit addition between the same
 is written as <tt>ADD(64,a,b)</tt>.  Floating point operations are
 denoted in the same manner.  For example, IEEE single-precision floating
 point add is written as <tt>FADD(32,a,b)</tt>, while the same in
 double-precision is written as <tt>FADD(64,a,b)</tt> 
 <p>
 Note that these types are low level.  Higher level distinctions such
 as signed and unsigned integer value, are not distinguished by the type.  
 Instead, operators are usually partitioned into signed and unsigned versions, 
 and it is legal (and often useful!) to mix signed and unsigned operators in
 an expression.
 <p>
 Currently, we don't provide a direct way to specify non-IEEE floating point 
 together with
 IEEE floating point arithmetic.  If this distinction is needed then
 it can be encoded using the extension mechanism described
 in Section <a href="mltree-ext.html#sec:mltree-extension">MLTree Extensions</a>.
 <p>
 We use the types <tt>ty</tt> and <tt>fty</tt> to stand for the number of
 bits in integer and floating point operations.  
 <font color="#000000"><small><pre>
   <font color="#6060a0"><b>type</b></font> ty  = int
   <font color="#6060a0"><b>type</b></font> fty = int
 </pre></small></font>
 
 <a name="link0002"></a>
<h3><font color="#486591">The Basis</font></h3>

 The signature <a href="../../mltree/mltree-basis.sig" target=code>MLTREE_BASIS</a>
 defines the basic helper types used in the MLTREE signature.  
 <font color="#000000"><small><pre>
 <font color="#6060a0"><b>signature</b></font> MLTREE_BASIS =
 <font color="#6060a0"><b><font color="#6060a0"><b>sig</b></font></b></font>
  
   <font color="#6060a0"><b>datatype</b></font> cond = LT | LTU | LE | LEU | EQ | NE | GE | GEU | GT | GTU 
 
   <font color="#6060a0"><b>datatype</b></font> fcond = 
      ? | !&lt;=&gt; | == | ?= | !&lt;&gt; | !?&gt;= | &lt; | ?&lt; | !&gt;= | !?&gt; |
      &lt;= | ?&lt;= | !&gt; | !?&lt;= | &gt; | ?&gt; | !&lt;= | !?&lt; | &gt;= | ?&gt;= |
      !&lt; | !?= | &lt;&gt; | != | !? | &lt;=&gt; | ?&lt;&gt;
 
   <font color="#6060a0"><b>datatype</b></font> ext = SIGN_EXTEND | ZERO_EXTEND
 
   <font color="#6060a0"><b>datatype</b></font> rounding_mode = TO_NEAREST | TO_NEGINF | TO_POSINF | TO_ZERO
 
   <font color="#6060a0"><b>type</b></font> ty = int
   <font color="#6060a0"><b>type</b></font> fty = int
 
 <font color="#6060a0"><b>end</b></font>
 </pre></small></font>
 
 The most important of these are the 
 types <font color="#ff0000"><tt>cond</tt></font> and <font color="#ff0000"><tt>fcond</tt></font>, which represent the set of integer
 and floating point comparisions.  These types can be combined with
 the comparison constructors <tt>CMP</tt> and <tt>FCMP</tt> to form
 integer and floating point comparisions.
 <table border=1 align=left><tr><td align=center> 
    Operator </td><td align=center> Comparison </tr><tr><td align=center> 
     <tt>LT</tt>     </td><td align=center> Signed less than </tr><tr><td align=center>
     <tt>LTU</tt>    </td><td align=center> Unsigned less than </tr><tr><td align=center>
     <tt>LE</tt>     </td><td align=center> Signed less than or equal </tr><tr><td align=center>
     <tt>LEU</tt>    </td><td align=center> Unsigned less than or equal </tr><tr><td align=center>
     <tt>EQ</tt>     </td><td align=center> Equal </tr><tr><td align=center>
     <tt>NE</tt>     </td><td align=center> Not equal </tr><tr><td align=center>
     <tt>GE</tt>     </td><td align=center> Signed greater than or equal </tr><tr><td align=center>
     <tt>GEU</tt>    </td><td align=center> Unsigned greater than or equal </tr><tr><td align=center>
     <tt>GT</tt>     </td><td align=center> Signed greater than </tr><tr><td align=center>
     <tt>GTU</tt>    </td><td align=center> Unsigned greater than </tr><tr><td align=center>
 
 </td></tr></table>
 
 Floating point comparisons can be ``decoded'' as follows.
 In IEEE floating point, there are four different basic comparisons 
 tests that we can performed given two numbers <math class="inline"><i>a</i></math> and <math class="inline"><i>y</i></math>:
 <dl>
    <dt><font color="#000070"><math class="inline"><i>a &lt; b</i></math></font><dd> Is <math class="inline"><i>a</i></math> less than <math class="inline"><i>b</i></math>?
    <dt><font color="#000070"><math class="inline"><i>a = b</i></math></font><dd> Is <math class="inline"><i>a</i></math> equal to <math class="inline"><i>b</i></math>?
    <dt><font color="#000070"><math class="inline"><i>a &gt; b</i></math></font><dd> Is <math class="inline"><i>a</i></math> greater than to <math class="inline"><i>b</i></math>?
    <dt><font color="#000070"><math class="inline"><i>a ? b</i></math></font><dd> Are <math class="inline"><i>a</i></math> and <math class="inline"><i>b</i></math> unordered (incomparable)?
 </dl>
 Comparisons can be joined together.  For example, 
 given two double-precision floating point expressions <math class="inline"><i>a</i></math> and <math class="inline"><i>b</i></math>,
 the expression <tt>FCMP(64,<=>,a,b)</tt> 
 asks whether <math class="inline"><i>a</i></math> is less than, equal to or greater than <math class="inline"><i>b</i></math>, i.e.~whether
 <math class="inline"><i>a</i></math> and <math class="inline"><i>b</i></math> are comparable.  
 The special symbol <tt>!</tt> negates
 the meaning the of comparison.    For example, <tt>FCMP(64,!>=,a,b)</tt> 
 means testing whether <math class="inline"><i>a</i></math> is less than or incomparable with <math class="inline"><i>b</i></math>. 
 <p>
 <a name="link0003"></a>
<h2><font color="#486591">Integer Expressions</font></h2>

 
 A reference to the <math class="inline"><i>i</i></math>th 
 integer register with an <math class="inline"><i>n</i></math>-bit value is written 
 as <tt>REG(</tt><math class="inline"><i>n</i></math>,<math class="inline"><i>i</i></math><tt>)</tt>.  The operators <tt>LI</tt>, <tt>LI32</tt>,
 and <tt>LABEL</tt>, <tt>CONST</tt> are used to represent constant expressions 
 of various forms.  The sizes of these constants are inferred from context.
 <font color="#000000"><small><pre>  
   REG   : ty * reg -&gt; rexp
   LI    : int -&gt; rexp
   LI32  : Word32.word -&gt; rexp
   LABEL : LabelExp.labexp -&gt; rexp
   CONST : Constant.const -&gt; rexp
 </pre></small></font>
 
 The following figure lists all the basic integer operators and their
 intuitive meanings.  All operators except <tt>NOTB, NEG, NEGT</tt> are binary 
 and have the type
 <font color="#000000"><small><pre>
   ty * rexp * rexp -&gt; rexp
 </pre></small></font>
 The operators <tt>NOTB, NEG, NEGT</tt> have the type
 <font color="#000000"><small><pre>
   ty * rexp -&gt; rexp
 </pre></small></font>
 
 <table border=1 align=center><tr><td align=left> 
    <tt>ADD</tt> </td><td align=left> Twos complement addition </tr><tr><td align=left>
   <tt>NEG</tt>      </td><td align=left> negation </tr><tr><td align=left>
   <tt>SUB</tt>      </td><td align=left> Twos complement subtraction </tr><tr><td align=left>
   <tt>MULS</tt>     </td><td align=left> Signed multiplication </tr><tr><td align=left>
   <tt>DIVS</tt>     </td><td align=left> Signed division, round to zero (nontrapping) </tr><tr><td align=left>
   <tt>QUOTS</tt>    </td><td align=left> Signed division, round to negative infinity (nontrapping) </tr><tr><td align=left>
   <tt>REMS</tt>     </td><td align=left> Signed remainder (???) </tr><tr><td align=left>
   <tt>MULU</tt>     </td><td align=left> Unsigned multiplication </tr><tr><td align=left>
   <tt>DIVU</tt>     </td><td align=left> Unsigned division </tr><tr><td align=left>
   <tt>REMU</tt>     </td><td align=left> Unsigned remainder </tr><tr><td align=left>
   <tt>NEGT</tt>      </td><td align=left> signed negation, trap on overflow </tr><tr><td align=left>
   <tt>ADDT</tt>     </td><td align=left> Signed addition, trap on overflow </tr><tr><td align=left>
   <tt>SUBT</tt>     </td><td align=left> Signed subtraction, trap on overflow </tr><tr><td align=left>
   <tt>MULT</tt>     </td><td align=left> Signed multiplication, trap on overflow </tr><tr><td align=left>
   <tt>DIVT</tt>     </td><td align=left> Signed division, round to zero,
    trap on overflow or division by zero </tr><tr><td align=left>
   <tt>QUOTT</tt>    </td><td align=left> Signed division, round to negative infinity, trap on overflow or division by zero </tr><tr><td align=left>
   <tt>REMT</tt>     </td><td align=left> Signed remainder, trap on division by zero </tr><tr><td align=left>
   <tt>ANDB</tt>     </td><td align=left> bitwise and </tr><tr><td align=left>
   <tt>ORB</tt>      </td><td align=left> bitwise or </tr><tr><td align=left>
   <tt>XORB</tt>     </td><td align=left> bitwise exclusive or </tr><tr><td align=left>
   <tt>NOTB</tt>     </td><td align=left> ones complement </tr><tr><td align=left>
   <tt>SRA</tt>      </td><td align=left> arithmetic right shift </tr><tr><td align=left>
   <tt>SRL</tt>      </td><td align=left> logical right shift </tr><tr><td align=left>
   <tt>SLL</tt>      </td><td align=left> logical left shift </tr><tr><td align=left>
 </td></tr></table>
 
 <a name="link0004"></a>
<h3><font color="#486591">Sign and Zero Extension</font></h3>

 Sign extension and zero extension are written using the operator
 <tt>CVTI2I</tt>. <tt>CVTI2I(</tt><math class="inline"><i>m</i></math>,<tt>SIGN_EXTEND</tt>,<math class="inline"><i>n</i></math>,<math class="inline"><i>e</i></math><tt>)</tt> 
 sign extends the <math class="inline"><i>n</i></math>-bit value <math class="inline"><i>e</i></math> to an <math class="inline"><i>m</i></math>-bit value, i.e. the
 <math class="inline"><i>n-1</i></math>th bit is of <math class="inline"><i>e</i></math> is treated as the sign bit.  Similarly,
 <tt>CVTI2I(</tt><math class="inline"><i>m</i></math>,<tt>ZERO_EXTEND</tt>,<math class="inline"><i>n</i></math>,<math class="inline"><i>e</i></math><tt>)</tt> 
 zero extends an <math class="inline"><i>n</i></math>-bit value to an <math class="inline"><i>m</i></math>-bit
 value.  If <math class="inline"><i>m &lt;= n</i></math>, then 
 <tt>CVTI2I(</tt><math class="inline"><i>m</i></math>,<tt>SIGN_EXTEND</tt>,<math class="inline"><i>n</i></math>,<math class="inline"><i>e</i></math><tt>)</tt> = 
 <tt>CVTI2I</tt>(<math class="inline"><i>m</i></math>,<tt>ZERO_EXTEND</tt>,<math class="inline"><i>n</i></math>,<math class="inline"><i>e</i></math><tt>)</tt>.
 <p>
 <font color="#000000"><small><pre>
     <font color="#6060a0"><b>datatype</b></font> ext = SIGN_EXTEND | ZERO_EXTEND
     CVTI2I : ty * ext * ty * rexp -&gt; rexp 
 </pre></small></font>
 
 <a name="link0005"></a>
<h3><font color="#486591">Conditional Move</font></h3>
 <a name="sec:cond-move"></a>
 Most new superscalar architectures incorporate conditional move 
 instructions in their ISAs.  
 Modern VLIW architectures also directly support full predication.  
 Since branching (especially with data dependent branches) can
 introduce extra latencies in highly pipelined architectures,
 condtional moves should be used in place of short branch sequences. 
 MLTree provide a conditional move instruction <tt>COND</tt>,
 to make it possible to directly express conditional moves without using
 branches. 
 <font color="#000000"><small><pre>
    COND : ty * ccexp * rexp * rexp -&gt; rexp
 </pre></small></font>
 
 Semantically, <tt>COND(</tt><em>ty</em>,<em>cc</em>,<math class="inline"><i>a</i></math>,<math class="inline"><i>b</i></math><tt>)</tt> means to evaluate
 <em>cc</em>, and if <em>cc</em> evaluates to true then the value of the entire expression is
 <math class="inline"><i>a</i></math>; otherwise the value is <math class="inline"><i>b</i></math>.  Note that <math class="inline"><i>a</i></math> and <math class="inline"><i>b</i></math> are allowed to be
 <em>eagerly</em>
 evaluated.  In fact, we are allowed to evaluate to <em>both</em>
 branches, one branch, or neither~\footnote{When possible.}. 
 <p>
 Various idioms of the <tt>COND</tt> form are useful for expressing common
 constructs in many programming languages.  For example, MLTree does not
 provide a primitive construct for converting an integer value <tt>x</tt> to a
 boolean value (0 or 1).  But using <tt>COND</tt>, this is expressible as
 <tt>COND(32,CMP(32,NE,x,LI 0),LI 1,LI 0)</tt>.  SML/NJ represents
 the boolean values true and false as machine integers 3 and 1 respectively.
 To convert a boolean condition <math class="inline"><i>e</i></math> into an ML boolean value, we can use
 <font color="#000000"><small><pre>
    COND(32,e,LI 3,LI 1)
 </pre></small></font>
 
 Common C idioms can be easily mapped into the <tt>COND</tt> form. For example,
 <ul>
   <li> <tt>if (e1) x = y</tt> translates into
   <tt>MV(32,x,COND(32,e1,REG(32,y),REG(32,x)))</tt>
   <li>
    <font color="#000000"><small><pre>
      x = e1; 
      if (e2) x = y
    </pre></small></font>
     translates into 
   <tt>MV(32,x,COND(32,e2,REG(32,y),e1))</tt>
   <li> <tt>x = e1 == e2</tt> translates into
   <tt>MV(32,x,COND(32,CMP(32,EQ,e1,e2),LI 1,LI 0)</tt>
   <li> <tt>x = ! e</tt> translates into
    <tt>MV(32,x,COND(32,CMP(32,NE,e,LI 0),LI 1,LI 0)</tt>
   <li> <tt>x = e ? y : z</tt> translates into
    <tt>MV(32,x,COND(32,e,REG(32,y),REG(32,z)))</tt>, and
   <li> <tt>x = y < z ? y : z</tt> translates into
    <font color="#000000"><pre>
      MV(32,x,
          COND(32,
             CMP(32,LT,REG(32,y),REG(32,z)),
                REG(32,y),REG(32,z)))
    </pre></font> 
 </ul>
 <p>
 In general, the <tt>COND</tt> form should be used in place of MLTree's branching
 constructs whenever possible, since the former is usually highly 
 optimized in various MLRISC backends. 
 <p>
 <a name="link0006"></a>
<h3><font color="#486591">Integer Loads</font></h3>

 
 Integer loads are written using the constructor <tt>LOAD</tt>.
 <font color="#000000"><small><pre>
    LOAD  : ty * rexp * Region.region -&gt; rexp
 </pre></small></font>
 The client is required to specify a <a href="regions.html">region</a> that
 serves as aliasing information for the load.  
 <p>
 <a name="link0007"></a>
<h3><font color="#486591">Miscellaneous Integer Operators</font></h3>

 
 An expression of the <tt>LET</tt>(<math class="inline"><i>s</i></math>,<math class="inline"><i>e</i></math>) evaluates the statement <math class="inline"><i>s</i></math> for
 its effect, and then return the value of expression <math class="inline"><i>e</i></math>.
 <font color="#000000"><small><pre>
   LET  : stm * rexp -&gt; rexp
 </pre></small></font>
 Since the order of evaluation is MLTree operators are 
 <em>unspecified</em>
 the use of this operator should be severely restricted to only 
 <em>side-effect</em>-free forms.
 <p>
 <a name="link0008"></a>
<h2><font color="#486591">Floating Point Expressions</font></h2>

 
  Floating registers are referenced using the term <tt>FREG</tt>.  The
 <math class="inline"><i>i</i></math>th floating point register with type <math class="inline"><i>n</i></math> is written 
 as <tt>FREG(</tt><math class="inline"><i>n</i></math>,<math class="inline"><i>i</i></math><tt>)</tt>.
 <font color="#000000"><small><pre>
    FREG   : fty * src -&gt; fexp
 </pre></small></font>
 
 Built-in floating point operations include addition (<tt>FADD</tt>), 
 subtraction (<tt>FSUB</tt>), multiplication (<tt>FMUL</tt>), division 
 (<tt>FDIV</tt>), absolute value (<tt>FABS</tt>), negation (<tt>FNEG</tt>)
 and square root (<tt>FSQRT</tt>).
 <font color="#000000"><small><pre>
    FADD  : fty * fexp * fexp -&gt; fexp
    FSUB  : fty * fexp * fexp  -&gt; fexp
    FMUL  : fty * fexp * fexp -&gt; fexp
    FDIV  : fty * fexp * fexp -&gt; fexp
    FABS  : fty * fexp -&gt; fexp
    FNEG  : fty * fexp -&gt; fexp
    FSQRT : fty * fexp -&gt; fexp
 </pre></small></font>
 
 A special operator is provided for manipulating signs.
 To combine the sign of <math class="inline"><i>a</i></math> with the magnitude of <math class="inline"><i>b</i></math>, we can
 write <tt>FCOPYSIGN(</tt><math class="inline"><i>a</i></math>,<math class="inline"><i>b</i></math><tt>)</tt>\footnote{What should 
 happen if <math class="inline"><i>a</i></math> or <math class="inline"><i>b</i></math> is nan?}.
 <font color="#000000"><small><pre>
    FCOPYSIGN : fty * fexp * fexp -&gt; fexp
 </pre></small></font>
 
 To convert an <math class="inline"><i>n</i></math>-bit signed integer <math class="inline"><i>e</i></math> into an <math class="inline"><i>m</i></math>-bit floating point value,
 we can write <tt>CVTI2F(</tt><math class="inline"><i>m</i></math>,<math class="inline"><i>n</i></math>,<math class="inline"><i>e</i></math><tt>)</tt>\footnote{What happen to unsigned integers?}.
 <font color="#000000"><small><pre>
    CVTI2F : fty * ty * rexp -&gt; fexp
 </pre></small></font>
 
 Similarly, to convert an <math class="inline"><i>n</i></math>-bit floating point value <math class="inline"><i>e</i></math> to an <math class="inline"><i>m</i></math>-bit
 floating point value, we can write <tt>CVTF2F(</tt><math class="inline"><i>m</i></math>,<math class="inline"><i>n</i></math>,<math class="inline"><i>e</i></math><tt>)</tt>\footnote{
 What is the rounding semantics?}.
 <font color="#000000"><small><pre>
    CVTF2F : fty * fty * -&gt; fexp
 </pre></small></font>
 
 <font color="#000000"><small><pre>
   <font color="#6060a0"><b>datatype</b></font> rounding_mode = TO_NEAREST | TO_NEGINF | TO_POSINF | TO_ZERO
   CVTF2I : ty * rounding_mode * fty * fexp -&gt; rexp
 </pre></small></font>
 
 <font color="#000000"><small><pre>
    FLOAD : fty * rexp * Region.region -&gt; fexp
 </pre></small></font>
 
 <a name="link0009"></a>
<h2><font color="#486591">Condition Expressions</font></h2>

 Unlike languages like C, MLTree makes the distinction between condition 
 expressions and integer expressions.  This distinction is necessary for
 two purposes:
 <ul>
   <li> It clarifies the proper meaning intended in a program, and
   <li> It makes to possible for a MLRISC backend to map condition
 expressions efficiently onto various machine architectures with different
 condition code models.  For example, architectures like the Intel x86, 
 Sparc V8, and PowerPC contains dedicated condition code registers, which
 are read from and written to by branching and comparison instructions.
 On the other hand, architectures such as the Texas Instrument C6, PA RISC,
 Sparc V9, and Alpha does not include dedicated condition code registers.
 Conditional code registers in these architectures
 can be simulated by integer registers.
 </ul>
 <p>
 
 A conditional code register bit can be referenced using the constructors
 <tt>CC</tt> and <tt>FCC</tt>.  Note that the <em>condition</em> must be specified
 together with the condition code register.
 <font color="#000000"><small><pre>
    CC   : Basis.cond * src -&gt; ccexp 
    FCC  : Basis.fcond * src -&gt; ccexp    
 </pre></small></font>
 For example, to test the <tt>Z</tt> bit of the <tt>%psr</tt> register on the
 Sparc architecture, we can used <tt>CC(EQ,SparcCells.psr)</tt>.  
 <p>
 The comparison operators <tt>CMP</tt> and <tt>FCMP</tt> performs integer and
 floating point tests.  Both of these are <em>typed</em> by the precision
 in which the test must be performed under.
 <font color="#000000"><small><pre>
    CMP  : ty * Basis.cond * rexp * rexp -&gt; ccexp  
    FCMP : fty * Basis.fcond * fexp * fexp -&gt; ccexp
 </pre></small></font>
 
 Condition code expressions may be combined with the following
 logical connectives, which have the obvious meanings.
 <font color="#000000"><small><pre>
    TRUE  : ccexp 
    FALSE : ccexp 
    NOT   : ccexp -&gt; ccexp 
    AND   : ccexp * ccexp -&gt; ccexp 
    OR    : ccexp * ccexp -&gt; ccexp 
    XOR   : ccexp * ccexp -&gt; ccexp 
 </pre></small></font>
 
 <a name="link0010"></a>
<h2><font color="#486591">Statements</font></h2>

 
 Statement forms in MLTree includes assignments, parallel copies,
 jumps and condition branches, calls and returns, stores, sequencing,
 and annotation.
 <p>
 <a name="link0011"></a>
<h3><font color="#486591">Assignments</font></h3>

 
 Assignments are segregated among the integer, floating point and
 conditional code types.  In addition, all assignments are <em>typed</em>
 by the precision of destination register.
 <p>
 <font color="#000000"><small><pre>
    MV   : ty * dst * rexp -&gt; stm
    FMV  : fty * dst * fexp -&gt; stm
    CCMV : dst * ccexp -&gt; stm
 </pre></small></font>  
 
 <a name="link0012"></a>
<h3><font color="#486591">Parallel Copies</font></h3>

 
 Special forms are provided for parallel copies for integer and
 floating point registers.  It is important to emphasize that
 the semantics is that all assignments are performed in parallel.
 <p>
 <font color="#000000"><small><pre>
    COPY  : ty * dst list * src list -&gt; stm
    FCOPY : fty * dst list * src list -&gt; stm
 </pre></small></font>
 
 <a name="link0013"></a>
<h3><font color="#486591">Jumps and Conditional Branches</font></h3>
  
 
 Jumps and conditional branches in MLTree take two additional set of
 annotations.  The first represents the <font color="#ff0000">control flow</font> and is denoted
 by the type <tt>controlflow</tt>.  The second represent 
 <font color="#ff0000">control-dependence</font> and <font color="#ff0000">anti-control-dependence</font> 
 and is denoted by the type <tt>ctrl</tt>.
 <p>
 <font color="#000000"><small><pre>
    <font color="#6060a0"><b>type</b></font> controlflow = Label.label list
    <font color="#6060a0"><b>type</b></font> ctrl = reg list
 </pre></small></font>
 Control flow annotation is simply a list of labels, which represents
 the set of possible targets of the associated jump.  Control dependence
 annotations attached to a branch or jump instruction represents the
 new definition of <font color="#ff0000">pseudo control dependence predicates</font>.  These
 predicates have no associated dynamic semantics; rather they are used
 to constraint the set of potential code motion in an optimizer
 (more on this later).
 <p>
 The primitive jumps and conditional branch forms are represented
 by the constructors <tt>JMP</tt>, <tt>BCC</tt>.
 <font color="#000000"><small><pre>
    JMP : ctrl * rexp * controlflow  -&gt; stm
    BCC : ctrl * ccexp * Label.label -&gt; stm
 </pre></small></font>
 
 In addition to <tt>JMP</tt> and <tt>BCC</tt>, 
 there is a <em>structured</em> if/then/else statement.
 <font color="#000000"><small><pre>
    IF  : ctrl * ccexp * stm * stm -&gt; stm
 </pre></small></font>
 
 Semantically, <tt>IF</tt>(<math class="inline"><i>c,x,y,z</i></math>) is identical to
 <font color="#000000"><small><pre>
    BCC(<math class="inline"><i>c</i></math>, <math class="inline"><i>x</i></math>, L1)
    <math class="inline"><i>z</i></math>
    JMP([], L2)
    DEFINE L1
    <math class="inline"><i>y</i></math>
    DEFINE L2
 </pre></small></font>
 where <tt>L1</tt> and <tt>L2</tt> are new labels, as expected.
 <p>
 Here's an example of how control dependence predicates are used.
 Consider the following MLTree statement:
 <font color="#000000"><small><pre>
    IF([p], CMP(32, NE, REG(32, a), LI 0),
         MV(32, b, PRED(LOAD(32, m, ...)), p),
         MV(32, b, LOAD(32, n, ...)))
 </pre></small></font>
 In the first alternative of the <tt>IF</tt>, the <tt>LOAD</tt>
 expression is constrainted by the control dependence 
 predicate <tt>p</tt> defined in the <tt>IF</tt>,
 using the predicate constructor <tt>PRED</tt>.  These states that
 the load is <em>control dependent</em> on the test of the branch,
 and thus it may not be legally hoisted above the branch without
 potentially violating the semantics of the program. 
 For example,
 semantics violation may happen  if the value of <tt>m</tt> and <tt>a</tt>
 is corrolated, and whenever <tt>a</tt> = 0, the address in <tt>m</tt> is
 not a legal address. 
 <p>
 Note that on architectures with speculative loads, 
 the control dependence information can be used to 
 guide the transformation of control dependent loads into speculative loads.
 <p>
 Now in constrast, the <tt>LOAD</tt> in the second alternative is not
 control dependent on the control dependent predicate <tt>p</tt>, and
 thus it is safe and legal to hoist the load above the test, as in
 <font color="#000000"><small><pre>
    MV(32, b, LOAD(32, n, ...));
    IF([p], CMP(32, NE, REG(32, a), LI 0),
         MV(32, b, PRED(LOAD(32, m, ...)), p),
         SEQ []
      )
 </pre></small></font>
 Of course, such transformation is only performed if the optimizer
 phases think that it can benefit performance.  Thus the control dependence
 information does <em>not</em> directly specify any transformations, but it
 is rather used to indicate when aggressive code motions are legal and safe.
 <p>
 <a name="link0014"></a>
<h3><font color="#486591">Calls and Returns</font></h3>

 
 Calls and returns in MLTree are specified using the constructors
 <tt>CALL</tt> and <tt>RET</tt>, which have the following types.
 <font color="#000000"><small><pre>
    CALL : rexp * controlflow * mlrisc * mlrisc * 
           ctrl * ctrl * Region.region -&gt; stm
    RET  : ctrl * controlflow -&gt; stm
 </pre></small></font>
 
 The <tt>CALL</tt> form is particularly complex, and require some explanation.
 Basically the seven parameters are, in order:
 <dl>
    <dt><font color="#000070">address</font><dd> of the called routine.
    <dt><font color="#000070">control flow</font><dd> annotation for this call.  This information 
 specifies the potential targets of this call instruction.  Currently
 this information is ignored but will be useful for interprocedural   
 optimizations in the future.
    <dt><font color="#000070">definition and use</font><dd>  These lists specify the list of
 potential definition and uses during the execution of the call.
 Definitions and uses are represented as the type <font color="#ff0000"><tt>mlrisc</tt></font> list.
 The contructors for this type is:
 <font color="#000000"><small><pre>
   CCR : ccexp -&gt; mlrisc
   GPR : rexp -&gt; mlrisc
   FPR : fexp -&gt; mlrisc
 </pre></small></font>
    <dt><font color="#000070">definition of control and anti-control dependence</font><dd> 
 These two lists specifies definitions of control and anti-control dependence.
    <dt><font color="#000070">region</font><dd> annotation for the call, which summarizes
 the set of potential memory references during execution of the call.
 </dl>
 <p>
 The matching return statement constructor <tt>RET</tt> has two
 arguments.  These are:
 <dl>
   <dt><font color="#000070">anti-control dependence</font><dd>  This parameter represents
 the set of anti-control dependence predicates defined by the return
 statement.
   <dt><font color="#000070">control flow</font><dd>  This parameter specifies the set of matching
 procedure entry points of this return.  For example, suppose we have
 a procedure with entry points <tt>f</tt> and <tt>f'</tt>.  
 Then the MLTree statements 
 <font color="#000000"><small><pre>
   f:   ...
        JMP L1
   f':  ...
   L1:  ...
        RET ([], [f, f'])
 </pre></small></font>
 can be used to specify that the return is either from
 the entries <tt>f</tt> or <tt>f'</tt>.  
 </dl>
 <p>
 <a name="link0015"></a>
<h3><font color="#486591">Stores</font></h3>

 Stores to integer and floating points are specified using the
 constructors <tt>STORE</tt> and <tt>FSTORE</tt>.   
 <font color="#000000"><small><pre>
    STORE  : ty * rexp * rexp * Region.region -&gt; stm
    FSTORE : fty * rexp * fexp * Region.region -&gt; stm
 </pre></small></font>
 
 The general form is
 <font color="#000000"><small><pre>
    STORE(<math class="inline"><i>width</i></math>, <math class="inline"><i>address</i></math>, <math class="inline"><i>data</i></math>, <math class="inline"><i>region</i></math>)
 </pre></small></font>
 
 Stores for condition codes are not provided.
 <a name="link0016"></a>
<h3><font color="#486591">Miscelleneous Statements</font></h3>

 
 Other useful statement forms of MLTree are for sequencing (<tt>SEQ</tt>),
 defining a local label (<tt>DEFINE</tt>).
 <font color="#000000"><small><pre>
    SEQ    : stm list -&gt; stm
    DEFINE : Label.label -&gt; stm
 </pre></small></font>
 The constructor <tt>DEFINE L</tt> has the same meaning as 
 executing the method <tt>defineLabel L</tt> in the 
 <a href="stream.html">stream interface</a>.
 <p>
 <a name="link0017"></a>
<h2><font color="#486591">Annotations</font></h2>

 <a href="annotations.html">Annotations</a> are used as the generic mechanism for
 exchanging information between different phases of the MLRISC system, and
 between a compiler front end and the MLRISC back end.
 The following constructors can be used to annotate a MLTree term with
 an annotation:
 <font color="#000000"><small><pre>
    MARK : rexp * Annotations.annotation -&gt; rexp
    FMARK : fexp * Annotations.annotation -&gt; fexp
    CCMARK : ccexp * Annotations.annotation -&gt; ccexp 
    ANNOTATION : stm * Annotations.annotation -&gt; stm
 </pre></small></font>

    <hr>
  <table cellpadding=0 cellspacing=0 width="100%">
  <tr>
    <td align=left>
    <table>
<tr><td><font size="-1">
<a href="mailto:george@research.bell-labs.com">Lal George</a>
</font></td></tr>
<tr><td><font size="-1">
<a href="mailto:leunga@cs.nyu.edu">Allen Leung</a>
</font></td></tr>
</table>

    </td>
    <td align=right>
      <a href="http://cm.bell-labs.com/cm/cs/what/smlnj/index.html">
      <img src="graphics/smlnj.jpg" width=80 height=50 
       alt="SML/NJ" border=0>
      </a>
      <a href="http://validator.w3.org/check?url=http://www.cs.nyu.edu/leunga/MLRISC/Doc/html/">
         <img src="graphics/vh401.gif" width=88 height=31 
          alt="Validate this page" border=0>
       </a>
    </td>
  </tr>
  <tr> <td align=left> 
       <font size="-1">
       <i> Generated by 
          <a href="mltex.html"> 
             <font color="#007777">mltex2html</font>
          </a>
       </i> 
       </font>
      </td>
  </tr>
  <tr> <td>
    <font size="-2">
    Last modified: Thu Jul 23 11:23:33 UTC 2015 by buildd@lgw01-47
    </font>
    </td>
  </tr>
  </table>

    </td>
  </tr>
  </table>
  </body>
</html>