An Algol 68 front end for GCC

[Posted January 1, 2025 by corbet]

While some people are focused on new and trendy languages, José Marchesi has, instead, gifted the world with a GCC front end for the Algol 68 language.

This WIP is a GCC front-end for Algol 68, the fascinating, generally poorly understood and often vilified programming language. It is common knowledge that Algol 68 was well ahead of its time back when it was introduced, and anyone who knows the language well will suspect this probably still holds true today, but more than fifty years after the publication of the Revised Report the world may finally be ready for it, or perhaps not, we shall see.

For those who see Algol 68 as too new, there was also a COBOL front end posted in December.

GCC front-ends

Posted Jan 1, 2025 17:22 UTC (Wed) by ibukanov (subscriber, #3942) [Link] (16 responses)

It is interesting that it is GCC front-end, not LLVM. And I thought GCC was criticized with its hard-to-use API while LLVM was created from the start to be modular and for easy front-end work. Has GCC improved in that area?

GCC front-ends

Posted Jan 1, 2025 17:41 UTC (Wed) by quotemstr (subscriber, #45331) [Link]

GCC supports more obscure architectures for code generation than LLVM does, yes? I can imagine the same person who'd write an ALGOL front end would care about esoteric backends.

GCC front-ends

Posted Jan 1, 2025 18:12 UTC (Wed) by ceplm (subscriber, #41334) [Link] (7 responses)

There is and there never was anything significantly wrong with GCC. If all these projects [1] managed to work with GCC, it means to me that there is nothing significantly wrong with. The only reason for Apple’s switch to LLVM then (I am not going into battle on merits between LLVM and GCC *now*, that’s a different story) was Steve Job being a control freak, who cannot live without having complete toolset under his control, and perhaps him taking revenge on GCC for forcing him to give up on the Objective-C front end [2].

[1] https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Sup...
[2] https://github.com/JoshCheek/clisp/blob/master/doc/Why-CL... and https://www.gnu.org/philosophy/pragmatic.html

GCC front-ends

Posted Jan 1, 2025 18:18 UTC (Wed) by ceplm (subscriber, #41334) [Link]

Better URL for the CLISP-related correspondence is https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc...

GCC front-ends

Posted Jan 1, 2025 22:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> There is and there never was anything significantly wrong with GCC.

Care to remember the state of GCC around 2005? It was a crusty C codebase that still pretended to be buildable by pre-C89 compilers.

The first clang compiler set the bar on error reporting, with colored output that pinpointed the exact position of the errors. GCC later replicated that.

GCC front-ends

Posted Jan 2, 2025 17:12 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

> The only reason for Apple’s switch to LLVM then ...

https://blog.robenkleene.com/2019/04/11/2012-apples-great...

It's far beyond GCC.

GCC front-ends

Posted Jan 2, 2025 17:21 UTC (Thu) by marcH (subscriber, #57642) [Link]

The GPLv2 has a political agenda but it's still just a "pure" software licence. Legal departments are not fans but they've learned to live with it.

The GPL v3 elevated the agenda much higher and reaches beyond software itself. Legal departments generally hate it. Unlike v2, it's been pretty much banned all across Apple products, see reference above.

Whether you agree with the political agenda or not is irrelevant, I'm just sticking to facts here.

GCC front-ends

Posted Jan 3, 2025 2:24 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

> Steve Job being a control freak, who cannot live without having complete toolset under his control

That was never the case and it's pretty easy to prove: to this very day every macOS device carries bash (version 3.2.57), screen (version 4.0.3) and many other tools not controlled by Apple.

It was always about GPLv3. That's why Apple never upgraded past GCC 4.2.

GCC front-ends

Posted Jan 4, 2025 20:25 UTC (Sat) by Heretic_Blacksheep (guest, #169992) [Link] (1 responses)

Doesn't prove anything.

The reason that's the case is because the BSD software MacOS/Darwin are based on never upgraded past GCC 4 because of GPL v3. That's one remove. What it does say is that because LLVM has a vastly more permissive license it's more acceptable to businesses who are in the business of selling software tool sets without giving hints away of what's in their secret sauce. It's business as usual in exploiting unpaid labor whether it's gladly or grudgingly granted without doing more than tossing the open source world a bone from time to time.

GCC front-ends

Posted Jan 4, 2025 23:26 UTC (Sat) by geofft (subscriber, #59789) [Link]

> It's business as usual in exploiting unpaid labor

I would assume that the vast majority of labor that goes into LLVM is paid, much of it by Apple.

The cause of free software is hurt by pretending that free software spontaneously comes into existence from unpaid hobbyists—it means that businesses who would pay for that labor think, it's going to happen on its own whether or not we pay for it, and if we start to pay for it we might prevent it from happening.

GCC front-ends

Posted Jan 1, 2025 18:30 UTC (Wed) by jklowden (guest, #107637) [Link] (4 responses)

LLVM is the target, right, the low-level virtual machine? Clang is the compiler toolkit. My experience with clang over a decade ago is why we opted for GCC over clang for COBOL. If the GCC API is criticized as hard to use, it has one singular advantage over clang: it exists.

Those years ago, I wanted to use clang to parse C++, and write the metadata to a database. I left with the sense that it might be possible, but I'd have to write the manual first.

(I still *do* want to write that tool. It would underpin a source-code navigation tool for C++, something that doesn't exist for large code bases. We have C-based tools like GNU Global and cscope, and I remember using a web-based text-search engine, but nothing that could distinguish open(2) from std::stream::open(), or report the call stack that modifies a variable.)

The GCC Internals manual runs some 800 pages. Even at that, the 10% of that document devoted to front-end development woefully inadequate; after all, the ISO COBOL specification is 1280 pages, and it describes only one language. But that document, plus a tutorial example, gave us a toehold. Within a week we had the "hello world" version of a COBOL compiler. Then it was just a quick 8 or so man-years of work.

GCC front-ends

Posted Jan 1, 2025 19:07 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link]

The tool you want to write sounds like it could be most easily written as a client of the clangd language server.

https://clangd.llvm.org/

GCC front-ends

Posted Jan 1, 2025 22:32 UTC (Wed) by ejr (subscriber, #51652) [Link]

Having had to port front- and back-ends from LLVM 12 to 18, I concur on the lack of an API.

Both systems have their benefits and drawbacks. Neither "wins." What we had to do would have been much more painful in GCC for various reasons. But so was the forward porting. meh. That's why we're "engineers," right?

GCC front-ends

Posted Jan 2, 2025 14:58 UTC (Thu) by iabervon (subscriber, #722) [Link]

LLVM is the cross-language backend part; clang is the C family frontend part. Unlike with GCC, the same frontend is used for C, C++, and ObjC, but I assume Algol or COBOL would be a separate frontend (like Rust, for example).

GCC front-ends

Posted Jan 4, 2025 23:31 UTC (Sat) by geofft (subscriber, #59789) [Link]

I found the LLVM tutorial excellent when I was going through it recently - I got a working AOT compiler for a tiny subset of Python going in a couple of hours.

This is the opposite of what you're looking for, to be fair; I wanted to use LLVM's compilation backend with a non-C language, and you wanted to use Clang's C parser. But there is a libclang tutorial that looks brief and readable that might be what you wanted. (Perhaps it did not exist at the time.)

GCC front-ends

Posted Jan 1, 2025 20:41 UTC (Wed) by segher (subscriber, #109337) [Link]

GCC frontends are mostly stand-alone code, creating its *own* data structures. Only when converting the data *out of* the frontend you convert it to something more generic (GENERIC and/or Gimple, usually).

GCC front-ends

Posted Jan 1, 2025 22:50 UTC (Wed) by jwakely (subscriber, #60262) [Link]

Jose has been a contributor to GCC, binutils etc for years.

mundane topics...

Posted Jan 2, 2025 12:14 UTC (Thu) by eru (subscriber, #2753) [Link] (5 responses)

From announcement: "The Revised Report didn't concern itself with mundane topics as separated compilation, " -- Typical of old academic languages. Pascal had the same flaw, and I think this, along with the lack of sane standard I/O system was one reason it lost to C, in spite of being very popular in the 80's. It was hard to make a portable Pascal program that did something useful.

mundane topics...

Posted Jan 2, 2025 15:22 UTC (Thu) by anselm (subscriber, #2796) [Link] (3 responses)

It was hard to make a portable Pascal program that did something useful.

Donald E. Knuth managed reasonably well with TeX and METAFONT …

mundane topics...

Posted Jan 2, 2025 15:43 UTC (Thu) by eru (subscriber, #2753) [Link] (2 responses)

Knuth didn't actually use pure Pascal. The code is in the "Web" language, which combines code and documentation. This is then run through a pre-processor called "Tangle" to produce the compilable code. This can handle variations in compilers.

https://ctan.org/tex-archive/systems/knuth/dist/web

As an another example of workarounds, there is the book "Software Tools in Pascal" by Kernighan and Plauger (1981), where some deficiencies of Pascal are papered over with a m4-like macro processor, source included in the book. I read this decades ago, but have forgotten how it was bootstrapped.

mundane topics...

Posted Jan 2, 2025 18:53 UTC (Thu) by willy (subscriber, #9762) [Link]

https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-... seems relevant here

mundane topics...

Posted Jan 10, 2025 2:30 UTC (Fri) by jschrod (subscriber, #1646) [Link]

Well, TeX's programming language history is more complicated.

TeX was originally written in SAIL, a local programming language in use at Stanford.

Then, after AMS got interested, it was rewritten in Pascal.

Afterwards, it was rewritten in Web, introducing Literate Programming.

I joined the TeX community at a time when we rewrote our own Pascal compiler (at the Technical University of Darmstadt) to port the Pascal version. In fact, one of my early programming tasks in that project was porting TANGLE to a BS2000 mainframe, when we migrated to the Web version.

I still have all those sources lying somewhere - but you can also find them online on CTAN. (I'm one of the CTAN founders.)

Oh, and you don't need to explain TeX's code base to anselm - he was an early TeX hacker as well, having written one of the first DVI drivers while he was at Darmstadt's math department in the 80s.

mundane topics...

Posted Jan 3, 2025 16:51 UTC (Fri) by epa (subscriber, #39769) [Link]

I worked in a shop where the old-timers had written the early code in Pascal, because at the time it was somewhat portable and C wasn’t. Some years later it was run through a Pascal to C translator.