The GNU Modula-2 front end to GCC
 |
 |
|
|
This section is not designed to generate a language war, but rather map out some of the advantages of using GNU Modula-2 rather than translate Modula-2 sources into another language.
It is expected that the primary purpose of GNU Modula-2 will be to compile legacy code. Currently there are only a few commercial Modula-2 compilers being actively maintained. Code which was written ten or fifteen years ago may still be compiled by older commercial (possibly unmaintained) compilers. While the 32 bit x86 remains these compilers presumably can be run in compatibility mode (some compilers only produced 16 bit code). Time is running out as the computing industry is switching to 64 microprocessors. While x86 emulation or 16 bit backwards compatibility is always possible it has some serious drawbacks. In order for the older source to run natively the source code will either have to be translated into another high level language or alternatively a Modula-2 compiler which can target these new generation of microprocessors will have to be acquired. GNU Modula-2 builds and passes all its regression tests on Debian Pure 64 LP64 (x86_64 architecture), 32 bit x86 GNU/Linux (Debian, stable and unstable). It almost certainly builds and passes on more platforms (for an up to date list of ports please see the GNU Modula-2 homepage). GNU Modula-2 has also been configured as a cross compiler for embedded microprocessors such as the ATMega8 and StrongArm.
GNU Modula-2 also has the advantage of being closely tied to GCC. Not only does this produce excellent code and excellent architectural and operating system coverage but it also utilises many of the GCC features. For example GNU Modula-2 can invoke the C preprocessor to manage conditional compilation; in-lining of SYSTEM procedures, intrinsic functions, memory copying routines are also exploited; access to assembly language using GCC syntax is also provided. GNU Modula-2 also support sets of any ordinal type (memory permitting). The compiler can also easily generate shared library modules and it has an automatic method of producing a swig interface file from a definition module. This means that after a few command line invocations the compiler can generate Python, Perl or TCL shared library modules providing they use simple data types.
GNU Modula-2 was based on a Modula-2 front end which performed a substantial amount of static analysis of the source code (see -Wpedantic, -Wpedantic-param-names, -Wstudents and -Wpedentic-cast.
Finally runtime checking has been implemented and can check to ensure that ranges of subranges are not exceeded, array indices are within range, functions execute a RETURN statement, a pointer does not dereference a NIL pointer value and that the expression within a CASE statement is correctly matched. The compiler performs semantic analysis for the above exceptions post optimization and will generate warnings should any of these be known to be reachable. See See (Semantic checking, gm2).