This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Some syntactic sugar for machine descriptions
- To: Michael Meissner <meissner at cygnus dot com>
- Subject: Re: Some syntactic sugar for machine descriptions
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Tue, 26 Jun 2001 16:29:20 -0700
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
On Tue, Jun 26, 2001 at 07:17:35PM -0400, Michael Meissner wrote:
> On Tue, Jun 26, 2001 at 03:12:35PM -0700, Richard Henderson wrote:
> > On Tue, Jun 26, 2001 at 03:09:48PM -0700, Zack Weinberg wrote:
> > > Another possibility occurred to me: teach genoutput that if the first
> > > character of the output template of a define_insn is a '{' that means
> > > the same thing as if it's an '*'. But I think that might cause
> > > problems with alternative assembly syntaxes.
> >
> > Definitely it would.
> >
> > > Maybe if the first two characters are '{' and white space... ?
> >
> > Um... I'm not especially pleased about that notion...
>
> I don't see what is so hard about an initial '*'. If we are doing away with
> the initial '*', I would prefer that the { be on column 1 of the next line.
The difficulty is that { ... } strings include the outermost pair of
braces in the string constant. The first character of {* ... } is
not '*', it's '{'.
I am currently testing an approach where read_rtx knows which slots of
which RTXes are strings that contain C code if their first character
is an *. Then read_string can auto-insert the * when it is given a
braced string for those slots. This avoids mucking with the template
letters.
--
zw But then one day I came up with a radical new paradigm for my business...
I decided that from now on I would only sell boring stuff that people
actually need.
-- Garry Trudeau, _Doonesbury_