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.