Hard to read through this without commenting.
The issue with GCC is that there is no real intermediate code. Yes, it passes "rtl" to the backend, but it is pretty much designed not
to park intermediate form into a file. This is deliberate. The GCC makers realized that if they provided an intermediate form
that the backend could get used as a general purpose tool, especially with respect to licencing. That is, there would be nothing
to prevent use with a commercial tool set.
In fact, I looked at using gcc as a backend long ago and realized that restriction, and decided against using it. That was about 1993.
LLVM is a different story, and that is certainly one reason it took off in popularity.
The other factor in this is designing the compiler in Pascal itself. FPC (for example) SHOULD be less efficient than a full blown
C written front end for GCC, since GCC got some world class attention to it's backend. However, as you discovered, the language
it was written in was less important than the platform. Its easier to add optimization to FPC than it is to port a GCC front end, because
FPC is defined in it's own language.
Is FPC a good Pascal target? The group there has made major strides to embrace the ISO 7185 as a dialect. My only issue with
them is that they don't use my help much :) ie, I write HUGE amounts of ISO 7185 tests and they appear to not be using much or
any of it, and when they do they don't talk to me (ie., give me any feedback whatever).
If gpc, or a "gpc like" compiler were written for LLVM (or similar), I would suggest that be done in Pascal itself. The phrase
is "eat your own dog food", that is, use your own tooling. Writing a compiler in its own language tends to wring out bugs
much faster, and tends to force you to provide more of your own infrastructure. GPC (sorry) suffers from this. There are too
many places you have to just declare an external call to C to get anything done in GPC.
Scott Franco
--------- Original Message ---------
Subject: Re: Plan to Update GPC
From: "Waldek Hebisch" <hebisch@math.uni.wroc.pl>
Date: 6/3/20 7:40 am
To: "gpc@gnu.de" <gpc@gnu.de>
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...
--
Waldek Hebisch
_______________________________________________
Gpc mailing list
Gpc@gnu.de
https://www.g-n-u.de/mailman/listinfo/gpc