Re: GCC

[cgd@broadcom.com]

this discussion isn't really specific to gcc, it applies to, say,
binutils too.  but since gcc is where it started that's where i'm
going to leave it.  8-)


At Thu, 31 Jul 2003 06:42:29 +0000 (UTC), "Steven Bosscher" wrote:
> I'm not sure why they think it is so difficult.

I'm not a "processor architect," but I interact with some of them, and
i've tried to get some of them to be more GCC cognizant.  I am,
however, somebody who works on low-level "processor stuff," and these
are factors in my experience:

(1) the assignments *are* a pain in the butt, but the amount of pain
    can be highly variable.  Originallly, no problem to get them
    signed (though the processing lag was annoying).  Later, new
    lawyers, much wrangling to get something OK to all sides,
    ultimately consumed about 5 months...  "ugh."

(2) slow patch approval times can be a problem, especially for people
    who are new.

    Looking back at my old patch list back to when I started
    submitting stuff (mid-2000), wait-for-approval time of > a month
    wasn't uncommon.

    These days, for me at least, the time is shorter.  I don't know if
    that's the experience of new developers, though.

(3) at least when i started doing this, there wasn't that much working
    documentation about how stuff could/should be tested (i.e., run
    with this sim, which is actually likely to work, by doing these
    steps...)  That made me uncertain of what I was doing, at least a
    bit.  I think this is getting better.

So, that's for me, a low-level OS hacker who thinks himself fairly
adaptable.  8-)

Note that these are all things that people care about only if doing
the GCC work themselves.  They can be addressed easily by hiring
somebody to do a port and submit it back.  Costs some money, but then,
so does processor design.



Sounds like the panel included processor architects who had been
"reached."  I think if you actually want to reach "processor
architects" generally, there are more problems IMO:

Processor architects do processor architecture.  Typically, they don't
know GCC internals.  (Often some will have *some* compiler exposure,
but the amount varies.)  If they're making a new processor, they
probably don't have time to learn GCC internals, or even to become
involved in the GCC community.

The result of that is that they might not be cognizant of things that
they should try to avoid if they want a good GCC back-end (if they're
designing with a new architecture) or a good scheduler description (if
they're doing a new implementation of an existing architecture).

Some seem obvious, e.g., if you make your scheduling rules bizarre and
with many exceptions, it'll be difficult to create an "optimal" (or
close to) code schduler for them.  Seems obvious enough to someone who
touches GCC a lot, but

        (1) it might not be to someone who doesn't, and

        (2) at some point, you hit a wall where "difficult" is "really
            really difficult," i.e., 2 pages of instruction issue rule
            special cases can translate into much more if you want to
            model them well.  8-)

Other stuff pops into mind: e.g. if you're designing a new
architecture, and want a good GCC port, and are on the fence about
branch delay slots (or whatever): obviously GCC supports them on
multiple architectures...  Does that mean they're *easy* to cope with
in GCC (or the other tools)?  etc.  

I think these are questions that you don't know about GCC unless
you've been in it for some amount of time -- which architects aren't
likely to have put in.

A collection of wisdom related to "designing architecture to make GCC
happy" would probably help.

These types of issues are ones where, unless you get it right early on
during the architecture of your part, it may be very very difficult to
get a good GCC port years later.  I don't know that they can be
addressed well by throwing money at some GCC developers, either.  (I
mean, they probably can be addressed, but it IMO it doesn't appear to
be a good way to spend money, up front.)



cgd