[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Faster token table lookups
From: |
Hans Aberg |
Subject: |
Re: Faster token table lookups |
Date: |
Tue, 19 Dec 2000 16:45:46 +0100 |
At 14:42 +0100 0-12-19, Akim Demaille wrote:
>> Token table lookups in the parser that Bison generates (cf. the
>> manual, the %token_table option & sec 4.2.1) can be speeded up
>> if Bison writes a token table with the names sorted
>> alphabetically
...
>I don't understand your point. AFAIK we never lookup for anything in
>this table. It's used the other way round: we have the token numbers,
>we want to know their `human' names, and that a simple matter of
>reading a cell of an array.
>
>So I don't know what you are talking about.
It would merely be a convenience to those that want to make a lot of name
table lookups. I think there is a suggestion one can implement it in the
lexer function yylex: instead of returning a macro number directly, it
makes a table lookup, and returns that number to Bison.
For example,
int lookup(const char*); // Make a string lookup & return the Bison macro
// number
%token implies "=>"
and instead of
yylex() {
...
return implies;
...
}
one writes
yylex() {
...
return lookup("=>");
...
}
This makes the macro name "implies" unnecessary, and one oculd have skipped
it, if
%token "=>"
would have been legal.
This could be convenient if speed isn't crucial, if one does not want to
invent a lot of macro names.
-- I haven't used that setup myself. This is how I figure it might be used
though.
-- Normally, this table would not be used at all, and it should be either
an option to have it written out, or one could let the linker remove it.
Hans Aberg
- Faster token table lookups, Hans Aberg, 2000/12/15
- Re: Faster token table lookups, Akim Demaille, 2000/12/19
- Re: Faster token table lookups,
Hans Aberg <=
- Re: Faster token table lookups, Akim Demaille, 2000/12/20
- Re: Faster token table lookups, Hans Aberg, 2000/12/20
- Re: Faster token table lookups, Hans Aberg, 2000/12/22
- Re: Faster token table lookups, Akim Demaille, 2000/12/22
- Re: Faster token table lookups, Hans Aberg, 2000/12/22
- Re: Faster token table lookups, Hans Aberg, 2000/12/22