From: Ziemowit Laski <zlaski@apple.com>
To: Stan Shebs <shebs@apple.com>
Cc: Ira Ruben <ira@apple.com>, gcc@gcc.gnu.org
Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec)
Date: Mon, 19 Nov 2001 06:19:00 -0000 [thread overview]
Message-ID: <CB35D7B2-E374-11D5-AE62-0030658361CA@apple.com> (raw)
In-Reply-To: <3C03D1CD.CE56AD7@apple.com>
On Tuesday, November 27, 2001, at 09:47 , Stan Shebs wrote:
> I wasn't going to mention your name, but if you want to take
> credit I can't stop you... :-)
I likewise held my peace, but now that the cat is out of the bag... :) :)
>
>> For MrC[pp] is was easy to do. And it was based on
>> feedback from our internal (Apple) AltiVec users (the *only* users at
>> that time other than Moto). They didn't want to write __vector and
>> they certainly couldn't tolerate "vector" being a macro that expanded
>> to __vector (which Moto was proposing). And "vector" couldn't be
>> treated as an unconditional reserved word either.
>
> Nevertheless, I still think it was a mistake. When it comes to
> messing with the language, we often need to say "no" to users, who
I agree that Ira's 'vector' (as opposed to '__vector') was not the
cleanest way to approach this (although not nearly as nefarious as
'#pragma poison'), but THIS IS TOTALLY BESIDE THE POINT!
My point (or, perhaps, points) were:
1. GCC is used on a variety of real-world platforms
2. In that same real world, people have invented tons of
target-specific extensions to C and C++ to get extra mileage
out of their particular hardware/OS setup.
3. Ergo, we should be able to come up with a 'configure'-based
mechanism for enabling selected extensions for selected target
WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.
How could we go about step 3? I'm sure there are a million ways,
but let me illustrate one possible scenario (for AltiVec):
1. We create a file called gcc/config/rs6000/c-parse.in.diff
(and something analogous for C++)
2. At build time, this diff will be used to patch up
gcc/c-parse.in if needed.
The foregoing approach has two immediate consequences:
1. The mainline grammar/lexical analyzer remains unchanged
2. It will be the sole responsibility of the users of AltiVec
extensions to maintain the diff so that it can be applied
cleanly; mainline developers need not and SHOULD NOT be
forced to deal with this.
> the world? Ironically, this extension makes our internal version of
> GCC more complicated and time-consuming to merge with FSF sources, so
> our imports take longer and have more problems, which means that your
> own daily work today has been made more difficult by the expedient
> choice of several years ago.
True, but I suspect that we (i.e., Apple) are far from the only ones
in this situation, which is why it is so desirable, IMHO, to be
able to put all such target-specific stuff in the FSF tree to begin
with! Of course, we already do this for back-end/codegen stuff -- we
just need to generalize this model.
--Zem
--------------------------------------------------------------
Ziemowit Laski Apple Computer, Inc.
zlaski@apple.com 2 Infinite Loop, MS 302-4SN
+1.408.974.6229 Fax .1344 Cupertino, CA 95014-2085
WARNING: multiple messages have this Message-ID
From: Ziemowit Laski <zlaski@apple.com>
To: Stan Shebs <shebs@apple.com>
Cc: Ira Ruben <ira@apple.com>, gcc@gcc.gnu.org
Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec)
Date: Tue, 27 Nov 2001 12:24:00 -0000 [thread overview]
Message-ID: <CB35D7B2-E374-11D5-AE62-0030658361CA@apple.com> (raw)
Message-ID: <20011127122400.WQfvgLvvFRyDs5y8pUd75Nn2WWnO-JwbVSYE8Gr86e4@z> (raw)
In-Reply-To: <3C03D1CD.CE56AD7@apple.com>
On Tuesday, November 27, 2001, at 09:47 , Stan Shebs wrote:
> I wasn't going to mention your name, but if you want to take
> credit I can't stop you... :-)
I likewise held my peace, but now that the cat is out of the bag... :) :)
>
>> For MrC[pp] is was easy to do. And it was based on
>> feedback from our internal (Apple) AltiVec users (the *only* users at
>> that time other than Moto). They didn't want to write __vector and
>> they certainly couldn't tolerate "vector" being a macro that expanded
>> to __vector (which Moto was proposing). And "vector" couldn't be
>> treated as an unconditional reserved word either.
>
> Nevertheless, I still think it was a mistake. When it comes to
> messing with the language, we often need to say "no" to users, who
I agree that Ira's 'vector' (as opposed to '__vector') was not the
cleanest way to approach this (although not nearly as nefarious as
'#pragma poison'), but THIS IS TOTALLY BESIDE THE POINT!
My point (or, perhaps, points) were:
1. GCC is used on a variety of real-world platforms
2. In that same real world, people have invented tons of
target-specific extensions to C and C++ to get extra mileage
out of their particular hardware/OS setup.
3. Ergo, we should be able to come up with a 'configure'-based
mechanism for enabling selected extensions for selected target
WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS.
How could we go about step 3? I'm sure there are a million ways,
but let me illustrate one possible scenario (for AltiVec):
1. We create a file called gcc/config/rs6000/c-parse.in.diff
(and something analogous for C++)
2. At build time, this diff will be used to patch up
gcc/c-parse.in if needed.
The foregoing approach has two immediate consequences:
1. The mainline grammar/lexical analyzer remains unchanged
2. It will be the sole responsibility of the users of AltiVec
extensions to maintain the diff so that it can be applied
cleanly; mainline developers need not and SHOULD NOT be
forced to deal with this.
> the world? Ironically, this extension makes our internal version of
> GCC more complicated and time-consuming to merge with FSF sources, so
> our imports take longer and have more problems, which means that your
> own daily work today has been made more difficult by the expedient
> choice of several years ago.
True, but I suspect that we (i.e., Apple) are far from the only ones
in this situation, which is why it is so desirable, IMHO, to be
able to put all such target-specific stuff in the FSF tree to begin
with! Of course, we already do this for back-end/codegen stuff -- we
just need to generalize this model.
--Zem
--------------------------------------------------------------
Ziemowit Laski Apple Computer, Inc.
zlaski@apple.com 2 Infinite Loop, MS 302-4SN
+1.408.974.6229 Fax .1344 Cupertino, CA 95014-2085
next prev parent reply other threads:[~2001-11-27 20:24 UTC|newest]
Thread overview: 237+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-16 9:10 front end changes for altivec Aldy Hernandez
2001-11-16 9:25 ` Andreas Jaeger
2001-11-26 2:55 ` Andreas Jaeger
2001-11-18 3:56 ` Joseph S. Myers
2001-11-18 4:24 ` Aldy Hernandez
2001-11-18 5:09 ` Joseph S. Myers
2001-11-18 6:10 ` Aldy Hernandez
2001-11-18 7:35 ` Richard Henderson
2001-11-26 19:50 ` Richard Henderson
2001-11-26 18:19 ` Aldy Hernandez
2001-11-18 12:41 ` Aldy Hernandez
2001-11-18 13:38 ` Andreas Jaeger
2001-11-18 15:32 ` Aldy Hernandez
2001-11-18 16:49 ` Bernd Schmidt
2001-11-18 17:06 ` Aldy Hernandez
2001-11-27 8:29 ` Aldy Hernandez
2001-11-27 8:00 ` Bernd Schmidt
2001-11-27 7:55 ` Aldy Hernandez
2001-11-27 7:50 ` Andreas Jaeger
2001-11-19 8:02 ` Richard Henderson
2001-11-19 8:35 ` Aldy Hernandez
2001-11-19 9:19 ` Richard Henderson
2001-11-19 11:51 ` Stan Shebs
2001-11-19 13:41 ` Richard Henderson
2001-11-19 16:13 ` Aldy Hernandez
2001-11-19 17:51 ` Richard Henderson
2001-11-19 19:15 ` Aldy Hernandez
2001-11-19 20:50 ` Richard Henderson
2001-11-27 17:14 ` Richard Henderson
2001-11-27 17:10 ` Aldy Hernandez
2001-11-21 13:08 ` Alexandre Oliva
2001-11-21 13:12 ` Daniel Berlin
2001-11-21 13:29 ` Alexandre Oliva
2001-11-21 13:31 ` Daniel Berlin
2001-11-21 13:41 ` Jack Lloyd
2001-11-28 23:44 ` Jack Lloyd
2001-11-28 23:00 ` Daniel Berlin
2001-11-28 22:34 ` Alexandre Oliva
2001-11-21 13:33 ` Richard Henderson
2001-11-21 13:49 ` Daniel Berlin
2001-11-29 4:45 ` Daniel Berlin
2001-11-28 23:16 ` Richard Henderson
2001-11-28 22:21 ` Daniel Berlin
2001-11-21 13:24 ` Per Bothner
2001-11-28 22:25 ` Per Bothner
2001-11-28 21:07 ` Alexandre Oliva
2001-11-27 17:03 ` Richard Henderson
2001-11-27 16:57 ` Aldy Hernandez
2001-11-27 15:16 ` Richard Henderson
2001-11-27 14:50 ` Stan Shebs
2001-11-19 15:25 ` Aldy Hernandez
2001-11-19 17:46 ` Richard Henderson
2001-11-19 21:39 ` Aldy Hernandez
2001-11-20 1:05 ` Dale Johannesen
2001-11-20 2:23 ` Richard Henderson
2001-11-27 17:45 ` Richard Henderson
2001-11-27 17:40 ` Dale Johannesen
2001-11-20 2:46 ` Richard Henderson
2001-11-20 2:56 ` front end changes for altivec-- conclusion Aldy Hernandez
2001-11-27 18:00 ` Aldy Hernandez
2001-11-27 17:50 ` front end changes for altivec Richard Henderson
2001-11-27 17:24 ` Aldy Hernandez
2001-11-27 17:02 ` Richard Henderson
2001-11-27 16:50 ` Aldy Hernandez
2001-11-27 14:01 ` Richard Henderson
2001-11-27 13:52 ` Aldy Hernandez
2001-11-27 13:40 ` Richard Henderson
2001-11-27 7:24 ` Aldy Hernandez
2001-11-26 17:04 ` Joseph S. Myers
2001-11-26 16:39 ` Aldy Hernandez
2001-11-18 6:40 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski
2001-11-18 6:33 ` Aldy Hernandez
2001-11-26 18:46 ` Aldy Hernandez
2001-11-18 8:19 ` Stan Shebs
2001-11-18 9:13 ` Ira Ruben
2001-11-18 12:26 ` Aldy Hernandez
2001-11-19 4:45 ` Ira Ruben
2001-11-19 6:04 ` Geoff Keating
2001-11-19 7:28 ` Ira Ruben
2001-11-19 12:04 ` Phil Edwards
2001-11-27 14:58 ` Phil Edwards
2001-11-27 12:47 ` Ira Ruben
2001-11-27 12:10 ` Geoff Keating
2001-11-19 7:50 ` Aldy Hernandez
2001-11-27 13:12 ` Aldy Hernandez
2001-11-27 10:53 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben
2001-11-19 6:26 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski
2001-11-19 7:53 ` Aldy Hernandez
2001-11-19 7:56 ` Ziemowit Laski
2001-11-27 13:21 ` Ziemowit Laski
2001-11-27 13:13 ` Aldy Hernandez
2001-11-27 12:41 ` Ziemowit Laski
2001-11-27 6:46 ` Aldy Hernandez
2001-11-18 18:51 ` Per Bothner
2001-11-27 9:20 ` Per Bothner
2001-11-18 23:55 ` Stan Shebs
2001-11-19 4:18 ` Ira Ruben
2001-11-19 4:48 ` Per Bothner
2001-11-19 5:28 ` Daniel Berlin
2001-11-27 11:35 ` Daniel Berlin
2001-11-19 6:26 ` Ziemowit Laski
2001-11-20 0:33 ` Per Bothner
2001-11-20 3:16 ` Ziemowit Laski
2001-11-20 6:33 ` Per Bothner
2001-11-27 18:27 ` Per Bothner
2001-11-20 11:05 ` Stan Shebs
2001-11-27 18:35 ` Stan Shebs
2001-11-27 18:06 ` Ziemowit Laski
2001-11-20 3:19 ` Stan Shebs
2001-11-20 5:25 ` Joseph S. Myers
2001-11-27 18:24 ` Joseph S. Myers
2001-11-20 11:27 ` Per Bothner
2001-11-27 19:59 ` Per Bothner
2001-11-20 11:37 ` Mark Mitchell
2001-11-20 17:03 ` Aldy Hernandez
2001-11-20 18:25 ` Mark Mitchell
2001-11-28 9:45 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell
2001-11-28 7:11 ` Target-specific Front-Ends? (Was: front end changes for altivec) Aldy Hernandez
2001-11-20 19:20 ` Stan Shebs
2001-11-20 20:24 ` Mark Mitchell
2001-11-20 23:47 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck
2001-11-28 12:43 ` Joe Buck
2001-11-28 11:31 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell
2001-11-20 20:27 ` Target-specific Front-Ends? (Was: front end changes for altivec) Dale Johannesen
2001-11-20 20:38 ` Stan Shebs
2001-11-21 4:47 ` Syd Polk
2001-11-21 12:31 ` Tim Hollebeek
2001-11-28 16:15 ` Tim Hollebeek
2001-11-28 14:12 ` Syd Polk
2001-11-28 11:55 ` Stan Shebs
2001-11-28 11:44 ` Dale Johannesen
2001-11-28 11:19 ` Stan Shebs
2001-11-27 20:40 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell
2001-11-27 18:09 ` Target-specific Front-Ends? (Was: front end changes for altivec) Stan Shebs
2001-11-27 17:35 ` Per Bothner
2001-11-27 12:34 ` Ziemowit Laski
2001-11-27 11:16 ` Per Bothner
2001-11-27 10:47 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben
2001-11-19 6:19 ` Ziemowit Laski [this message]
2001-11-19 7:13 ` Target-specific Front-Ends? (Was: front end changes for altivec) Joseph S. Myers
2001-11-19 7:34 ` Stan Shebs
2001-11-19 8:01 ` Joseph S. Myers
2001-11-19 9:18 ` Aldy Hernandez
2001-11-19 11:23 ` Dale Johannesen
2001-11-27 14:46 ` Dale Johannesen
2001-11-27 13:56 ` Aldy Hernandez
2001-11-27 13:27 ` Joseph S. Myers
2001-11-27 12:57 ` Stan Shebs
2001-11-19 7:56 ` Ziemowit Laski
2001-11-19 8:31 ` Richard Henderson
2001-11-27 13:44 ` Richard Henderson
2001-11-19 10:23 ` Mark Mitchell
2001-11-19 11:55 ` Target-specific Front-Ends? (Was: front end changes for Joe Buck
2001-11-19 14:03 ` Mark Mitchell
2001-11-19 14:46 ` Joe Buck
2001-11-27 16:13 ` Joe Buck
2001-11-20 0:56 ` Devang Patel
2001-11-27 17:37 ` Devang Patel
2001-11-20 5:17 ` Aldy Hernandez
2001-11-20 11:15 ` Ziemowit Laski
2001-11-20 17:09 ` Aldy Hernandez
2001-11-20 17:26 ` Joe Buck
2001-11-20 17:57 ` Aldy Hernandez
2001-11-20 19:16 ` Neil Booth
2001-11-20 21:10 ` Input Stream Rewriting (Was: Target-specific Front-Ends?) Ziemowit Laski
2001-11-21 0:24 ` Neil Booth
2001-11-21 1:05 ` Ziemowit Laski
2001-11-21 4:38 ` Neil Booth
2001-11-28 13:57 ` Neil Booth
2001-11-28 13:25 ` Ziemowit Laski
2001-11-28 12:45 ` Neil Booth
2001-11-28 12:01 ` Ziemowit Laski
2001-11-28 11:06 ` Target-specific Front-Ends? (Was: front end changes for Neil Booth
2001-11-28 9:16 ` Aldy Hernandez
2001-11-28 9:11 ` Joe Buck
2001-11-20 20:53 ` Ziemowit Laski
2001-11-20 22:08 ` Joe Buck
2001-11-28 12:26 ` Joe Buck
2001-11-20 23:37 ` Per Bothner
2001-11-21 3:14 ` Ziemowit Laski
2001-11-21 12:32 ` David Edelsohn
2001-11-21 12:44 ` Ziemowit Laski
2001-11-28 18:40 ` Ziemowit Laski
2001-11-28 18:29 ` David Edelsohn
2001-11-28 13:36 ` Ziemowit Laski
2001-11-28 12:36 ` Per Bothner
2001-11-28 11:55 ` Ziemowit Laski
2001-11-28 7:33 ` Aldy Hernandez
2001-11-27 19:40 ` Ziemowit Laski
2001-11-20 19:17 ` Devang Patel
2001-11-28 11:09 ` Devang Patel
2001-11-27 18:21 ` Aldy Hernandez
2001-11-27 15:32 ` Mark Mitchell
2001-12-04 0:14 ` Alex Rosenberg
2001-12-04 0:33 ` Mark Mitchell
2001-12-04 11:25 ` Aldy Hernandez
2001-11-27 14:53 ` Joe Buck
2001-11-27 14:36 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Mark Mitchell
2001-11-27 13:19 ` Target-specific Front-Ends? (Was: front end changes for altivec) Ziemowit Laski
2001-11-27 12:44 ` Joseph S. Myers
2001-11-19 8:34 ` Aldy Hernandez
2001-11-19 12:54 ` Stan Shebs
2001-11-19 15:41 ` Aldy Hernandez
2001-11-19 19:08 ` Dale Johannesen
2001-11-19 19:15 ` Aldy Hernandez
2001-11-27 17:10 ` Aldy Hernandez
2001-11-27 17:06 ` Dale Johannesen
2001-11-27 16:56 ` Aldy Hernandez
2001-11-27 15:06 ` Stan Shebs
2001-11-27 13:44 ` Aldy Hernandez
2001-11-19 9:26 ` Bernd Schmidt
2001-11-19 9:53 ` Ziemowit Laski
2001-11-19 10:59 ` Bernd Schmidt
2001-11-19 14:12 ` Ziemowit Laski
2001-11-27 15:37 ` Ziemowit Laski
2001-11-27 14:41 ` Bernd Schmidt
2001-11-27 14:30 ` Ziemowit Laski
2001-11-27 14:13 ` Bernd Schmidt
2001-11-19 9:40 ` Stan Shebs
2001-11-19 11:27 ` Ziemowit Laski
2001-11-27 14:50 ` Ziemowit Laski
2001-11-27 14:20 ` Stan Shebs
2001-11-27 12:24 ` Ziemowit Laski
2001-11-27 9:48 ` Stan Shebs
2001-11-26 23:45 ` Target-specific Front-Ends? (Was: front end changes foraltivec) Ira Ruben
2001-11-26 22:22 ` Target-specific Front-Ends? (Was: front end changes for altivec) Stan Shebs
2001-11-26 18:47 ` Ziemowit Laski
2001-11-26 15:45 ` front end changes for altivec Joseph S. Myers
2001-11-26 2:51 ` Aldy Hernandez
2001-11-18 8:02 Target-specific Front-Ends? (Was: front end changes for altivec) mike stump
2001-11-26 19:52 ` mike stump
[not found] <CB35D7B2-E374-11D5-AE62-0030658361CA@apple.com.suse.lists.egcs>
[not found] ` <m3r8qjvqd1.fsf@litecycle.cc.andrews.edu.suse.lists.egcs>
[not found] ` <p73bshnss5x.fsf@amdsim2.suse.de>
2001-11-19 17:20 ` Aldy Hernandez
2001-11-27 16:58 ` Aldy Hernandez
2001-11-20 4:44 mike stump
2001-11-20 10:10 ` Aldy Hernandez
2001-11-27 18:28 ` Aldy Hernandez
2001-11-27 18:12 ` mike stump
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CB35D7B2-E374-11D5-AE62-0030658361CA@apple.com \
--to=zlaski@apple.com \
--cc=gcc@gcc.gnu.org \
--cc=ira@apple.com \
--cc=shebs@apple.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).