From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8740 invoked by alias); 28 Nov 2001 00:13:18 -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 8719 invoked from network); 28 Nov 2001 00:13:18 -0000 Received: from unknown (HELO kiruna.synopsys.com) (204.176.20.18) by hostedprojects.ges.redhat.com with SMTP; 28 Nov 2001 00:13:18 -0000 Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170]) by kiruna.synopsys.com (Postfix) with ESMTP id C78C3F3D4; Tue, 27 Nov 2001 16:13:17 -0800 (PST) Received: from atrus.synopsys.com (localhost [127.0.0.1]) by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id QAA08667; Tue, 27 Nov 2001 16:13:39 -0800 (PST) From: Joe Buck Received: (from jbuck@localhost) by atrus.synopsys.com (8.9.3+Sun/8.9.1) id QAA06039; Tue, 27 Nov 2001 16:13:16 -0800 (PST) Message-Id: <200111280013.QAA06039@atrus.synopsys.com> Subject: Re: Target-specific Front-Ends? (Was: front end changes for To: mark@codesourcery.com (Mark Mitchell) Date: Mon, 19 Nov 2001 14:46:00 -0000 Cc: jbuck@synopsys.COM (Joe Buck), zlaski@apple.com (Ziemowit Laski), jsm28@cam.ac.uk (Joseph S. Myers), gcc@gcc.gnu.org (gcc@gcc.gnu.org) In-Reply-To: <32170000.1006903600@gandalf.codesourcery.com> from "Mark Mitchell" at Nov 27, 2001 03:26:40 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00921.txt.bz2 I wrote: > > Consider a preprocessor that takes current Altivec C code and produces > > either standard or extended C code (GNU extensions). If adopting the > > existing Altivec syntax is too painful, a second choice might be to figure > > out syntax choices that would make such a preprocessor very easy to write. > > Then we don't have to ask existing users to rewrite their code. Mark writes: > Yup, I thought about this too. It's plausible, but a pretty substantial > effort, and not easy to do robustly with the tools we've got. It wouldn't necessarily be up to the gcc team to deliver the preprocessor. A 100% correct version would be substantial, as it would have to be a full parser, but a more limited Perl or Python whack-job might handle almost all the existing code. The proposal is really only meant as an answer to those who say that we cannot change the syntax at all because users won't want to change their code. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: mark@codesourcery.com (Mark Mitchell) Cc: jbuck@synopsys.COM (Joe Buck), zlaski@apple.com (Ziemowit Laski), jsm28@cam.ac.uk (Joseph S. Myers), gcc@gcc.gnu.org (gcc@gcc.gnu.org) Subject: Re: Target-specific Front-Ends? (Was: front end changes for Date: Tue, 27 Nov 2001 16:13:00 -0000 Message-ID: <200111280013.QAA06039@atrus.synopsys.com> References: <32170000.1006903600@gandalf.codesourcery.com> X-SW-Source: 2001-11/msg01422.html Message-ID: <20011127161300.0NPgeDaqbeNBRLw-Qr3RG8I8bLU_MykCU7Bq7K1hcp0@z> I wrote: > > Consider a preprocessor that takes current Altivec C code and produces > > either standard or extended C code (GNU extensions). If adopting the > > existing Altivec syntax is too painful, a second choice might be to figure > > out syntax choices that would make such a preprocessor very easy to write. > > Then we don't have to ask existing users to rewrite their code. Mark writes: > Yup, I thought about this too. It's plausible, but a pretty substantial > effort, and not easy to do robustly with the tools we've got. It wouldn't necessarily be up to the gcc team to deliver the preprocessor. A 100% correct version would be substantial, as it would have to be a full parser, but a more limited Perl or Python whack-job might handle almost all the existing code. The proposal is really only meant as an answer to those who say that we cannot change the syntax at all because users won't want to change their code.