Since the first open source release there have been many changes to CM3. For an overview of the major events have a look at the
News Items
For a more detailed history you may refer to the
CM3 ChangeLog
The latest release is CM3 5.8. Below that you will find some older notes from the time of the first open source releases.
The updated language definition can be found here.
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:
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.
For the first free release of CM3, Elego Software Solutions has added the following changes:
Please have a look at the (yet incomplete) CM3 5.1 Documentation.
For general information about Modula-3 have a look at the Modula-3 FAQ and the PM3 distribution.
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).
The most obvious change is that the TextF interface is gone. The TextF (Text friends) interface revealed Text.Ts to be of type REF ARRAY OF CHAR. This is no more possible, since TEXTs can contain 16 bit characters as well (i.e. WIDECHARs). Rather than extending all TEXTs to arrays of WIDECHARs, a different solution has been implemented. TEXTs are now opaque objects (see Text.T) that may be of several different sub-types and contain parts and concatenations of 8 and 16 bit character sequences ( Text8.T, Text16.T, Text8Short.T, Text16Short.T, TextCat.T, TextSub.T). Access to the individual characters of a TEXT is only possible through the defined standard interface Text.GetChar(t, i) and the new interface Text.GetWideChar(t, i).
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 TextF interface (most often for performance optimizations) will break as the interface has vanished and the structure of TEXT objects is now hidden. Retrieving characters of a text now must use the GetChar procedures, and writing characters into a TEXT directly is no more possible at all. C-style string comparisions or copies (strcmp, strcpy, memcmp, memcpy) 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.
There is no general rule how to change code that uses the cold TextF 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 Text.Cat() (& operator) and Text.Sub() are now much faster (for long strings), since no copying takes place.
In the compiler release 5.1.2 some minimal support for profiling has been added (option -profile 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.
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 RTCollector and RTCollectorSRC interfaces to learn more about the garbage collector.
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 M3toC the procedure TtoS is gone. SharedTtoS and FreeSharedS 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.
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 TEXT optimizations, and generally been able to achieve the same performace as before.