From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21035 invoked by alias); 31 Jul 2003 16:41:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21016 invoked from network); 31 Jul 2003 16:41:14 -0000 Received: from unknown (HELO mms3.broadcom.com) (63.70.210.38) by sources.redhat.com with SMTP; 31 Jul 2003 16:41:14 -0000 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Thu, 31 Jul 2003 09:41:15 -0700 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id JAA19300; Thu, 31 Jul 2003 09:40:39 -0700 (PDT) Received: from ldt-sj3-010.sj.broadcom.com (ldt-sj3-010 [10.21.64.10]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id h6VGf4ov029238; Thu, 31 Jul 2003 09:41:04 -0700 (PDT) Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com ( 8.11.6/8.9.3) id h6VGf4q17943; Thu, 31 Jul 2003 09:41:04 -0700 X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to cgd@broadcom.com using -f To: s.bosscher@student.tudelft.nl cc: gcc@gcc.gnu.org Subject: Re: GCC References: <1059633859.3637.8.camel@steven.lr-s.tudelft.nl> From: cgd@broadcom.com Date: Thu, 31 Jul 2003 19:38:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-WSS-ID: 13379921574192-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg02322.txt.bz2 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5400 invoked by alias); 31 Jul 2003 16:53:27 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5167 invoked from network); 31 Jul 2003 16:53:16 -0000 Received: from unknown (HELO epita.fr) (163.5.255.10) by sources.redhat.com with SMTP; 31 Jul 2003 16:53:17 -0000 Received: from kualalumpur.lrde.epita.fr (mail@kualalumpur.lrde.epita.fr [10.223.13.1]) by epita.fr id h6VGrF425722 for EPITA Paris France Thu, 31 Jul 2003 18:53:15 +0200 (CEST) Received: from babylon.lrde.epita.fr ([10.223.13.55] ident=mail) by kualalumpur.lrde.epita.fr with esmtp (Exim 3.35 #1 (Debian)) id 19iGfm-0007Kx-00 for ; Thu, 31 Jul 2003 18:53:02 +0200 Received: from news by babylon.lrde.epita.fr with local (Exim 3.36 #1 (Debian)) id 19iGVI-0008MW-00 for ; Thu, 31 Jul 2003 18:42:12 +0200 From: cgd@broadcom.com X-Newsgroups: lrde.list.gcc Subject: Re: GCC Date: Thu, 31 Jul 2003 19:45:00 -0000 Organization: EPITA / LRDE http://www.lrde.epita.fr Distribution: lrde Message-ID: References: <1059633859.3637.8.camel@steven.lr-s.tudelft.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@lrde.epita.fr X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to cgd@broadcom.com using -f X-WSS-ID: 13379921574192-01-01 To: gcc@gcc.gnu.org X-SW-Source: 2003-07/txt/msg02323.txt.bz2 Message-ID: <20030731194500.0cezr2pwk4w6rpfwQPvhBjVCX9pvt7PRxF9ocbXf6KY@z> 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