Original version:
Sat Jun 6 13:10:07 2026
Last updates:
Sat Jun 6 13:10:14 2026
…
Tue Aug 18 08:54:23 2026
Current time in Salt Lake City, Utah, USA:
Tuesday, 18-Aug-2026 16:31:32 MDT
In late November 2025, a new compiler for Algol 68, ga68, was merged into the GNU Compiler Collection source trees for gcc-16 and gcc-17. I have been routinely building gcc releases from source code since 2006, so it was a trivial matter to add algol68 to the list of languages for which I routinely build compilers.
Work still needs to be done at the developer end to ensure that ga68 can be built on more systems, because I found that builds failed on many of the platforms that I tried.
There is an active mailing list for ga68 at https://gcc.gnu.org/pipermail/algol68/.
I have written dozens of test programs to explore features of Algol 68 as implemented by ga68, and the links to files utah-ga68-YYYY-MM-DD.* in this directory allow others to test my code, simply by unbundling one of those files, and then running make in the just-created source directory. At Utah, that reports ALL TESTS PASSED on GNU/Linux systems running on physical and QEMU-emulated virtual AMD64 (== x86_64), ARM64 (== AARCH64), RISC-V64, and S390x CPUs. The latter two represent the newest and oldest CPU families in current wide user, and S390x uses big-endian addressing while the others are little-endian systems.
In addition to my compiler and Algol 68 language explorations, I have developed two extensive bibliographies of the history of the Algol programming language family: algol68.bib and algol-bulletin.bib, Together, they provide about 2100 entries into the large body of literature on the Algol family. Extensive comment headers in those two files supply helpful background on their contents.
The *rand48* files in the bundles show how to create an interface from Algol 68 code to the POSIX standard random number functions in the Standard C Library. The posixrandom.a68 file contains an Algol 68 module that defines prototypes for accessing the POSIX functions, and the libga68-rand48.c file supplies the wrapper functions that are needed when a direct call from Algol 68 to C is not possible. At present, there is a compiler implementation issue in ga68 that prevents passing writable arrays to functions in other languages, so until that is repaired, three of the POSIX functions need a different call signature from Algol 68.
The erand48.a68, jrand48.a68, and nrand48.a68 files do not use the interface module, but instead, just supply private prototypes of the POSIX random number functions that they use.
Once the compiler has been extended, it should then be possible to create clean module interfaces from Algol 68 code to major C libraries, such as -lgmp, -lmpfr, -lgsl, -llapack, and many others, and well as to many commonly needed Standard C functions, greatly extending the applicability and portability of new Algol 68 code.
Although the ga68 compiler is a rather recent addition to the gcc compiler family, it is already in the binary package systems of a few operating systems and CPU families, including these:
At Utah, I have successfully built and installed ga68 from source code on at least these systems and CPU types:
A correspondent reported to me in August 2026 that ga68 from gcc-16.2.0 is now available in the Gentoo Linux distribution, which is one of the few that routinely build packages on the local machine from source code.
There is a much older (by 25 years!) compiler for Algol 68, Marcel van der Veer's GENIE compiler, a68g. It is available in binary, documentation, and source distributions via links here. The binary packages include three distributions (Debian, Fedora, and Ubuntu) of Linux, FreeBSD, NetBSD, OpenBSD, Microsoft Windows (all for the Intel x86_64 (amd64) CPU architecture), plus Apple macOS on both x86_64 and aarch64 (arm64).
I have been able to prepare versions of most of my ga68 test code to work under that older compiler, but the changes to do so are significant. In the GENIE compiler, there appears to be one source form, with keywords in UPPERCASE, and everything else in lowercase. The I/O functions are different, and so is the comment syntax. More seriously, there appears to be no way to invoke code written in other languages. Although the mathematical function repertoire in a68g is larger than in ga68, without access to direct calls to other libraries, it is difficult to do intensive testing of accuracy and behavior of integer and floating-point arithmetic, and of numerical library functions.
The lack of easy code portability between the two Algol 68 compilers, a68g and ga68, and the absence of a software tool to convert code between the formats expected by the two compilers, make me disinclined to consider a68g further.
Given the drawbacks of a68g, it seems more likely that ga68 could soon become the standard Algol 68 compiler on all systems on which the gcc compiler family can be easily built — today, that is almost all Unix-family systems, except OpenBSD, which remains a significant impediment. Its most recent release (OpenBSD 7.9) has gcc-15.2.0 in the binary package system, with compilers for Ada, C, D, and Fortran, but not for C++, which is needed to bootstrap builds of some of the other language compilers.
In August 2026, a correspondent kindly reported that the OpenBSD ports system has a g++ package. I have successfully built the ports package for the GNU Cobol compiler, cobc, version 3.2.0, on OpenBSD 7.9, but that is not part of gcc. Build attempts in ports for g++ at my site have failed on two independent OpenBSD 7.9 systems, even after increasing the virtual machine resources on one of them to 12 CPUs and 12GB of DRAM.
Another attempt on OpenBSD 7.8 also failed: on that system, with 4 CPUs and 4GB DRAM, the build of several compilers appeared to complete, with *.tgz files created in /usr/ports/packages/amd64/all for g++, g95, gcc, gcc-libs, gdc, gnat, and gobjc, but the install step failed because of conflicts with already-installed packages. There are several other needed compiler-dependent packages that I had already installed from the binary package system, so it is not possible to remove the earlier GNU compiler packages in the hope that the ports build could be installed.
Sadly, although both clang and gcc compilers are designed to be installed in version-dependent directory trees, so that multiple versions can coexist on the same system without conflict, the OpenBSD developers have not followed that model, and permit only a single version of each compiler family to be installed from the binary package system.
The next major release of OpenBSD, 8.0, is expected near the end of 2026, and I will retry a ports build of the gcc compiler family when I have a new virtual machine for that O/S.
I recently learned of a68toc, a translator from Algol 68 to C. It is available here. So far, I have been able to build and install it from source code, but initial experiments suggest that like the two compilers, it has a notion of a particular dialect and syntax format of Algol 68 code, and I have yet to have it successfully translate short test programs.
Testing at Utah of conversion of integers to strings in ga68 in Spring 2026 demonstrated that conversions of the most negative value, -2**(n - 1), for n-bit integers are incorrect. This has been traced to different behavior of the Algol 68 MOD operator, compared to the C remainder operator, %, when operands are negative. Differing computation of the integer remainder has affected many programming languages, and is defined to be implementation dependent or platform dependent in some ISO programming language standards.
Here is a comparison of remainder operations in the two languages:
Algol 68: +57 MOD +10 = +7 +57 MOD -10 = +7 -57 MOD +10 = +3 -57 MOD -10 = +3
C: +57 % +10 = +7 +57 % -10 = +7 -57 % +10 = -7 -57 % -10 = -7
^^^^^^^^^^^ differences ^^^^^^^^^^
Solutions are exhibited in the bundled files inttostr-algol-v*.a68 for each of the integer types supported by ga68, in the form of a procedure posrem(num,den) that replaces use of the MOD operator, and produces correct conversions. The companion file inttostr.c illustrates similar conversions in the C language.
The Web links are to HTML versions of the bibliographies that supply live hypertext links. Change the final .html to .bib for the BibTeX original that is needed for literature citations.
Despite the name algol68, the first of those contains extensive references to work on about two dozen variants of earlier Algol compilers, as well as subset Algol 68 compilers. They are all covered because there are evolutionary relations that deserved to be documented in a single BibTeX file.
The Web links are to HTML versions of the bibliographies that supply live hypertext links, Change the final .html to .bib for the BibTeX original that is needed for literature citations.
Other people who occur frequently in the Algol literature, but are not covered in the BibNet Project, include Paul Branquart, Ole Johan Dahl [ACM Turing Award 2001], Jacobus de Bakker, Fraser G. Duncan, Robert W. Floyd [ACM Turing Award 1978], George E. Forsythe, Julien Green, Ian D. Hill, Charles A. Katz, Donald E. Knuth [ACM Turing Award 1974], Cornelis H. A. Koster, Johan Lewi, Charles H. Lindsey, Barry J. Mailloux, John McCarthy [ACM Turing Award 1971], Lambert G. L. Meertens, Karl Nickel, Kristen Nygaard [ACM Turing Award 2001], John E. L. Peck, Klaus Samelson, Michel Sintzoff, Johannes C. van Vliet, Adriaan van Wijngaarden, Bernard Vauquois, Joseph H. Wegstein, Brian A. Wichmann, and Michael Woodger.
Collectively, a dozen ACM Turing Awards, and three of the first five, have been to people who helped develop the Algol language family. Of course, those people made important contributions in other areas of computer science too.