![[ICO]](/icons/blank.gif){kind=icon}
![[PARENTDIR]](/icons/back.gif){kind=icon}
![[TXT]](/icons/text.gif){kind=icon}
![[ ]](/icons/unknown.gif){kind=icon}
![[ ]](/icons/layout.gif){kind=icon}
| Name | Last modified | Size |
|---|---|---|---|
| Parent Directory | - | |
| README.html | 2024-05-12 09:41 | 9.9K |
| TestWriteLongReal.lst-gcc-15-20240428 | 2024-05-09 16:47 | 2.9K |
| TestWriteLongReal.mod | 2024-05-09 16:46 | 1.2K |
| TestWriteReal.lst-gcc-15-20240428 | 2024-05-09 15:56 | 2.5K |
| TestWriteReal.mod | 2024-05-09 15:24 | 1.0K |
| TestWriteShortReal.lst-gcc-15-20240428 | 2024-05-09 15:56 | 1.2K |
| TestWriteShortReal.mod | 2024-05-09 15:34 | 1.1K |
| app-modula-2-2024-03-09.pdf | 2024-03-09 09:03 | 193K |
| app-oberon-2024-04-09.pdf | 2024-04-09 15:37 | 252K |
Original version:
Thu May 9 17:04:50 2024
Last updates:
Fri May 10 17:14:45 2024
This Web site holds Modula-2 code examples, and their output, to supplement communications on the GNU Modula-2 compiler (gm2) discussion list at https://lists.nongnu.org/archive/html/gm2.
There is an extensive BibTeX bibliography (intended to be complete) of the works of Niklaus Wirth (15 February 1934–1 January 2024), the designer of Euler, Algol-W, Pascal, Modula-2, Oberon, and several other programming languages, in BibTeX and HTML formats. That bibliography also includes numerous entries for publications by others about Niklaus Wirth, or his works. Many of those publications are about Modula, Modula-2, and Modula-3.
The TestWrite*Real.* files relate to my posting about the precision of floating-point output, for which the list archives contain followups by others. The test programs can be compiled and run like this:
% gm2 TestWriteShortReal.mod && ./a.out > TestWriteShortReal.lst
% gm2 TestWriteReal.mod && ./a.out > TestWriteReal.lst
% gm2 -fiso TestWriteLongReal.mod && ./a.out > TestWriteLongReal.lst
The -fiso option (indicating the language level defined by the ISO/IEC 10514-3:1998 Standard for Modula-2) is needed to access modules that support I/O for the LONGREAL datatype. That type corresponds to the IEEE 754 binary80 floating-point type on platforms with M68K, x86, or x86_64 CPUs, and to the binary128 type on systems with Alpha, ARM64 (a.k.a Aarch64), HPPA, MIPS, PPC64, RISC-V, S390X, SPARC, and other CPU families. Support for that type in gm2 depends upon its being available in the underlying gcc compilers, which might in turn depend on the host operating system and C libraries on those systems.
Because some compilers remap longer floating-point types to shorter types, the three test programs report the storage size of their floating-point types, and compute the machine epsilon (the smallest positive floating-point number whose sum with 1.0 exceeds 1.0) to verify the precision that is actually used.
Appendices in my large book, The Mathematical-Function Computation Handbook: Programming Using the MathCW Portable Software Library, describe how a large numerical library written in highly portable C can be interfaced to several other programming languages, including Ada, C#, C++, Fortran, Java, and Pascal. Since the book appeared, I have written additional virtual appendices on similar interfaces for Cobol, Go, Modula-2, Oberon, and Rust. They will eventually be made available at the book's Web site, but are stable enough that I have copied two of them to this site, in the files app-*-YYYY-MM-DD.pdf. Those filenames include a date so that any subsequent changes are identifiable via the names. However, I do not currently expect further changes in them.
While the book itself is copyrighted, the virtual appendices are being made freely downloadable. They include enough of a description of the programming languages to document how interfaces to C are created, so they can also serve as tutorials on a subset of those languages.
There is great variety in module implementations for the Modula and Oberon families, and that has a large impact on software written in those languages. The two appendices discuss those issues in detail, and make recommendations for improving that unfortunate situation.
I have a strong personal interest in the GNU gm2 compiler providing a reliable, stable, and widely available, compiler for Modula-2, so that Niklaus Wirth's carefully reasoned ideas about programming can have a long and healthy future. gm2 could rapidly become the default compiler worldwide for that language, and as gm2 is further developed, it might implement new language features in the R10 extension approved by Niklaus Wirth.
Perhaps in the future, gm2 might even spawn a GNU Oberon compiler, for which I'm proposing the name goc. The Excelsior compilers, xc and xm, each support both languages, so there is precedence for doing so in the important GNU gcc compiler family.
I also believe that gm2, with only a modest development effort, could serve as a testbed for a significant extension of Modula-2 to provide three or four decimal floating-point arithmetic types, which would offer precisions of 7, 16, 34, and 70 decimal digits, based on the IEEE 754 Standard and its future extensions. All are already fully supported in my MathCW library. Humans continue to be confounded by computations done in binary arithmetic, but for which input and output are in decimal arithmetic. A lot of existing software would be substantially improved for human use if it switched to decimal arithmetic, or at least offered it as an alternative to binary arithmetic.
On modern computer hardware, the rate-limiting steps are often not numerical instructions, but rather movements of data over networks, between slow memory and fast CPUs, and on effective use of multiple levels of cache memory, as well as exploiting multicore CPUs that are now commonly available. Thus, hardware implementations of decimal arithmetic that are currently somewhat slower than for binary arithmetic may, in practice, mean that the instruction timing differences are mostly irrelevant for overall performance and throughput. Computations should not only produce the correct answer, but that answer should also be right for humans.
Author and site maintainer: Nelson H. F. Beebe
E-mail: beebe@math.utah.edu
Internet: http://www.math.utah.edu/~beebe