modula3.github.io/about-cm3.html at master · modula3/modula3.github.io · GitHub

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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title>About CM3</title>
    <META HTTP-EQUIV="Content-Type" CONTENT="text/html">
    <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
    <META HTTP-EQUIV="Resource-type" CONTENT="document">
    <META HTTP-EQUIV="Reply-to" CONTENT="m3-support@elego.de">
    <LINK HREF="normal.css" REL="stylesheet" TYPE="text/css">
    <META NAME="robots" content="noindex">
  </head>

  <body bgcolor="#ffffff">
    <h2>About CM3</h2>

    <p>
      Critical Mass Modula-3 (CM3) is the
      release of the Modula-3 compiler produced by Critical
      Mass, which contains considerable enhancements to the compiler,
      run-time system, and core libraries, which have not been
      publicly available so far. The changes made by Critical Mass,
      Inc. since their CM3 4.1 release include:
    </p>
    <ul>
      <li>Modula-3 modules loadable at runtime</li>
      <li>
        <tt>&lt;*IMPLICIT*&gt;</tt> exceptions (changes language
        semantics)
      </li>
      <li>
        checked runtime errors are mapped to the implicit exception
        <tt>RuntimeError.E</tt>
      </li>
      <li>
        garbage collector failures are also mapped to implicit exceptions
      </li>
      <li>COM-compatible object layout (for WIN32)</li>
      <li>
        Unicode support: WIDECHAR, Text, Text8, Text16, Unicode
        interfaces
      </li>
      <li>extended ASSERT pragma:<br>
        <tt>&lt;*ASSERT condition [ ("," | WITH) msg ] *&gt></tt>
      </li>
      <li>new DEBUG pragma:<br>
        <tt>
          &lt;*DEBUG condition [ ("," | WITH) msg {, msg} ] *&gt;<br>
          &lt;*DEBUG [ msg {, msg } ] *&gt;
        </tt>
      </li>
      <li>64 bit support for 64 bit machines</li>
    </ul>

    <p>
      There have been many more changes, and the 4.1 release also
      contained lots of improvements compared to the SRC release, for
      example support for DLL generation on Win32,  much easier
      configuration procedure, binary installation (and installer),
      reorganization and speedup of the builder etc.
    </p>

    <p>
      For the first free release of CM3, <a
      href="http://www.elego-software-solutions.com">Elego Software
      Solutions</a> has added the following changes:
    </p>
    <ul>
      <li>
        new gcc backend based on gcc 2.95.2
      </li>
      <li>
        updated/added runtime support for platforms FreeBSD2,
        FreeBSD3, FreeBSD4, LINUXLIBC6, and SOLgnu
      </li>
      <li>
        minimal binary installation packages for Win32, Linux,
        FreeBSD, and SOLgnu
      </li>
      <li>
        scripts for m3 package handling, system booting, installation,
        and distribution archive creation
      </li>
    </ul>

    <p>
      Please have a look at the (yet incomplete)
      <a href="doc/index.html">CM3 5.1 Documentation</a>.
    </p>

    <p>
      For general information about <a
        href="http://www.elegosoft.com/index.php?id=171&L=1">
        Modula-3</a> have a look at the <a
        href="http://modula3.elegosoft.com/pm3/intro/questions/questions.html">Modula-3
        FAQ</a> and <a href="http://www.elegosoft.com/solutions/modula-3.html">the PM3 distribution</a>.
    </p>

    <a name="if-changes">
    <h2>CM3 5.1 Interface Changes and Performance Considerations</h2>
    </a>

    <p>
      There are some more or less incompatible interface changes
      between CM3 5.1 and all other Modula-3 distributions. These are
      caused by the extension of the TEXT type from 8 bit character
      sequences to arbitrary 8 and 16 bit character sequences
      (Unicode).
    </p>

    <p>
      The most obvious change is that the <tt>TextF</tt> interface is
      gone. The <tt>TextF</tt> (<em>Text friends</em>) interface
      revealed <tt>Text.Ts</tt> to be of type <tt>REF ARRAY OF
      CHAR</tt>. This is no more possible, since <tt>TEXT</tt>s can
      contain 16 bit characters as well
      (i.e. <tt>WIDECHAR</tt>s). Rather than extending all
      <tt>TEXT</tt>s to arrays of <tt>WIDECHAR</tt>s, a different
      solution has been implemented. <tt>TEXT</tt>s are now opaque
      objects (see <a
        href="doc/help/gen_html/m3core/src/text/Text.i3.html">Text.T</a>)
      that may be of several different sub-types and contain
      parts and concatenations of 8 and 16 bit character sequences
      (<tt>
        <a href="doc/help/gen_html/m3core/src/text/Text8.i3.html">Text8.T</a>,
        <a href="doc/help/gen_html/m3core/src/text/Text16.i3.html">Text16.T</a>,
        <a href="doc/help/gen_html/m3core/src/text/Text8Short.i3.html">Text8Short.T</a>,
        <a href="doc/help/gen_html/m3core/src/text/Text16Short.i3.html">Text16Short.T</a>,
        <a href="doc/help/gen_html/m3core/src/text/TextCat.i3.html">TextCat.T</a>,
        <a href="doc/help/gen_html/m3core/src/text/TextSub.i3.html">TextSub.T</a></tt>).
      Access to the individual characters of a
      <tt>TEXT</tt> is only possible through the defined standard
      interface <tt>Text.GetChar(t, i)</tt> and the new interface
      <tt>Text.GetWideChar(t, i)</tt>.
    </p>

    <p>
      This design has several consequences. Old code that uses only
      the standard interfaces will still work (though it will not be
      able to use Unicode characters). Old code that uses the
      <tt>TextF</tt> interface (most often for performance
      optimizations) will break as the interface has vanished and the
      structure of <tt>TEXT</tt> objects is now hidden. Retrieving
      characters of a text now <em>must</em> use the <tt>GetChar</tt>
      procedures, and writing characters into a <tt>TEXT</tt> directly
      is no more possible at all. C-style string comparisions or
      copies (<tt>strcmp, strcpy, memcmp, memcpy</tt>) are no more
      possible, too. Modules that made use of these features will not
      only have to be rewritten to rely on the new interfaces only, but
      probably algorithmic changes will be necessary, too, since the
      cost for the standard operations has changed and code must be
      optimized very differently for performance.
    </p>

    <p>
      There is no general rule how to change code that uses the cold
      <tt>TextF</tt> interface and preserve the same
      performance. Sometimes it may not be possible at all, but in
      many cases performance gains in other operations will compensate
      for the loss due to more complex structure. The previously
      costly operations <tt>Text.Cat()</tt> (<tt>&amp; operator</tt>)
      and <tt>Text.Sub()</tt> are now much faster (for long strings),
      since no copying takes place.
    </p>

    <p>
      In the compiler release 5.1.2 some minimal support for profiling
      has been added (option <tt>-profile</tt> and configuration
      template additions) for some POSIX platforms. You should use
      this facility or other profiling tools to find the performance
      bottlenecks in your programs.
    </p>

    <p>
      Performance optimization is difficult though. You may find that
      many things you consider to be obvious optimizations turn out to
      be pessimizations, and a simple change in one routine can make
      the program 300% faster.
      There are also subtle dependencies with garbage collection
      (heap size, paged out memory, and collection strategy (sweep
      and copy, incremental and generational, concurrent)). For simple
      short-running programs it might be better to disable all
      garbage collection, while long-running interactive applications
      need all the features of the garbage collector. The garbage
      collector is more or less effective with different strategies
      depending on the memory use patterns (e.g. many small objects
      due to lots of concatenated texts).
      Have a look at the <a
      href="doc/help/gen_html/m3core/src/runtime/common/RTCollector.i3.html">
      RTCollector</a> and <a
      href="doc/help/gen_html/m3core/src/runtime/common/RTCollectorSRC.i3.html">
      RTCollectorSRC</a> interfaces to learn more about the garbage
      collector.
    </p>

    <p>
      The support of Unicode texts has also introduced another
      performance bottleneck and interface change which shows itself
      when interfacing to other languages like C. In the interface <a
      href="doc/help/gen_html/m3core/src/C/Common/M3toC.i3.html">M3toC</a>
      the procedure <tt>TtoS</tt> is gone. <tt>SharedTtoS</tt> and
      <tt>FreeSharedS</tt> must be used instead. Again, the syntactical
      change is easy, but the operations are now more costly than before
      and may contribute an unforeseen amount of execution time to
      your applications.
    </p>

    <p>
      Thus said, I should mention that I have ported some medium
      to big size applications to the CM3 5.1 system, some of which
      made heavy use of <tt>TEXT</tt> optimizations, and generally
      been able to achieve the same performace as before.
    </p>

    <hr>
    <address><a href="mailto:m3-support{at}elego.de">m3-support{at}elego.de</a></address>
<!-- Created: Fri Feb 16 15:27:10 MET 2001 -->
  </body>
</html>