Re: bison patch to help gcc?

[Tim Josling <tej at melbpc dot org dot au>]

Neil Booth wrote:
> Tim Josling wrote:-
>
>
> > There are three problems here
> >
> > 1. Bison gets a bad name.
> > 2. A lot of time is wasted with proposals to rewrite the parser to get 
> > rid of 'inefficient' bison.
> > 3. In some cases people actually hand coded the parsers.
>
>
> Don't forget there is correlation: it would also be unfair to those
> anti-bison to state that the actions are independent of bison.  Our
> actions are currently cack-handed, a large part of it working around bison
> issues.
>
> A hand-coded parser doesn't have this problem.
>
> Neil.

It depends how you do it. There are many more hacks needed for COBOL 
than for C, but the CPU involved in the hacks is so low it is not 
measurable. With the COBOL compiler I just build a tree out of the 
parser. The back end interface is done elsewhere.

I agree that c-parse.in is a bit of a mess. This seems to result from 
doing three things at once within the actions

1) LALRizing hacks
2) Build parse tree on the fly
3) Generate code (some is as you go like static variables, others get 
saved up for a while).

There are advantages of using bison. For example the parse structure is 
more visible (have a look at the C++ parser in contrast). You can easily 
add metrics, parser-trace etc. It points out problems in the grammar. 
The number of lines of code is less.

The Ada compiler is hand coded. They argue that you get better 
performance and better diagnostics out of it. Maybe this is true though 
I have never seen evidence about the performance. However it is 
undoubtedly huge.

Tim Josling