This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: %print
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Akim Demaille <akim at epita dot fr>
- Cc: GCC Patches <gcc-patches at gnu dot org>,Bison Patches <bison-patches at gnu dot org>
- Date: Fri, 30 Aug 2002 22:49:00 -0700
- Subject: Re: %print
- References: <mv4bsajyz9f.fsf@nostromo.lrde.epita.fr> <mv4lm9mryx6.fsf@nostromo.lrde.epita.fr> <mv41ybckaom.fsf_-_@nostromo.lrde.epita.fr> <mv4elf85rxa.fsf@nostromo.lrde.epita.fr> <20020615191348.GB6252@codesourcery.com> <mv41yb62q6s.fsf@nostromo.lrde.epita.fr> <20020618074948.GA30892@codesourcery.com> <mv4znxtne5e.fsf@nostromo.lrde.epita.fr> <20020618194844.GE30892@codesourcery.com> <mv4r8j3iu2p.fsf_-_@nostromo.lrde.epita.fr>
On Wed, Jun 19, 2002 at 09:52:30AM +0200, Akim Demaille wrote:
> Zack> I'm pretty sure that a lot of bison's internal tables could
> Zack> become smaller and/or unnecessary with this feature.
>
> I'm not sure I understand your point here. It is not very costly to
> have a 256 items table to tell what chars are and are not valid
> tokens. I don't believe there is much to be gained with this, do you?
> That's the only place where you will find some cost to related to this
> (yytranslate). Removing this, in addition, seems to be quite
> dangerous.
Suppose yylex() makes an ironclad guarantee that it will return a
specific set of token codes and *only* those token codes. The size of
that set is less than 256. If bison could use those codes directly to
index its state transition tables, I believe it would be both faster
and smaller (since some of the tables could be 'char' instead of
'short', and a number of internal checks would be unnecessary).
zw