On Wed, Jun 03, 2020 at 09:03:44AM -0400, Kevan Hashemi wrote:
Dear Tom,
At least now there is some record and maybe that will help the next person to work on this.
I'll add two more comments that explain why I gave up on the GNU Compiler Collection.
(7) Waldek has GPC compiling on GCC 4.3.5. As I describe in (5) and (6), I was unable to build GCC 4.3.5 on MacOS. But I do have GCC 4.9.4, installed by Home Brew. So I thought, "Surely I can just use 4.9.4, maybe a few tweaks will be required." But no, it's not just a few tweaks. Between GCC 4.3.5 and 4.9.4, the GCC people made dramatic changes to the interface between the front end and the middle end. The file varray.c is gone. The definition of the GENERIC tree structure is scattered through a bunch of new files and is incompatible with the old structures.
My past experience was that I needed about month of work to update to new GCC version (say 4.1 to 4.2). Skipping intermediate versions can save some work. OTOH, since changes are larger more effort goes into finding new way of doing things.
The GCC team claim their objective is to provide a platform upon which we can create front-ends for any and all languages we want. It's the "GNU Compiler Collection". It's a great idea. It's the idea that drew me into GPC and GCC in the first place. We can combine FORTRAN, Pascal, and C and link them into one executable. It was great.
http://www.bndhep.net/Software/Mixing/Mixing_Manual.html
But fundamental to any such endeavor is a firm commitment to backward compatibility. Making dramatic changes to the trees interface that break other people's front ends is absolutely contrary to the "compiler collection" philosophy. The GCC team has abandoned its mission. Maybe they have recovered their sense of direction in the past ten years, since GCC 4, heading into GCC 11, but I doubt it.
Yes. There is "Run with us or get lost" attiude in GCC comunity. Just to keep front end in sync with backend requires substantial work.
And that's when I gave up. I hate C, that's why I program in Pascal. Spending hundreds of hours programming in C to get a Pascal compiler to work was going to be painful.
Sure, understand.
So I switched to FPC. And now I discover that the secondary problems with GCC (it's a pain in the neck) have been obscuring its primary problems.
(8) According to comments in the GPC source files, one of the reasons the GCC team goes ahead and breaks other people's front ends is because they are implementing new optimisation routines. So, we would expect the GCC code to be fast, even if GCC itself is a pain in the neck. But my FPC code runs approximately twice as fast as my GCC code. I tested it inverting 100 x 100 matrices on a Linux machine where I have both GPC and FPC running in 64-bit.
Could you post your benchmark. To say the truth I spent some time looking at assembly code produced by GPC and cases when it was possible to gain significant speedup at assembly level were quite rare. What I have seen were: - tiny routines (especially tiny loops) have kind of random speed, adding useless instrution can make tiny look go faster, moving code to different place in memory can change runtime - Pascal semantics sometimes forces less efficient code. In particular Pascal requires "correct" handling of edge cases and code needed for this may increase runtime - bit-packed arrays are particularly inefficient. Decision to implement bit-packing in GNU Pascal was long ago and probably was a mistake. Here most of blame is on front end, AFAIK GNU Pascal is the only Pascal compiler that implements bit-packing. Theoretically back end could do better job with bit-packing, but it is hard to blame GCC folks that they do not optimize code that almost nobody uses.
Most compile-time optimisation takes place in the middle and back ends, not the front end. So, after all that fuss, and making so much work for Waldek and the rest of the GPC writers, the GCC crew still can't produce efficient code. And because GCC compiles itslef, the compiler itself is slow. Compiling my code with FPC goes twice as fast as compiling with GCC.
My conclusion is that GCC is a disorganised and ineffectual mess. The header and macro arrangement beloved of C has created a monstrous body of code that is almost impossible to compile and is being modified continuously by people who don't want to maintain the version they released six months ago, even though that version was dramatically different from the version they released a year ago. I note that MacOS abandoned GCC, switching to CLANG, and Windows does not appear to use GCC at all. Only on Linux is GCC common, but people are starting to build Linux with CLANG, so we'll see what the future holds for GCC. I'm not optimistic.
Well, Aplle decided to use LLVM mostly for licencing reasons: they want to control software on iPhones (so that it is Apple who controls what gets installed on users iPhone), and GPL 3 (used for GCC 4.2 and higher) requires that users have ability to install their own programs.
LLVM is a fresh start, so it was cleaner due to lack of of old warts. Now LLVM has accumulated its own warts and partially in response to LLVM GCC folks have done large cleanups. And one effect of GCC cleanups is that old interfaces used by GPC got replaced by different ones making GPC porting harder...
BTW. My student made a small compiler interfacing LLVM (he did not want to deal with GCC). In about 2 years his compiler got completely broken by changes to LLVM interface...