|
From: | Tim Josling |
Subject: | Re: bison patch to help gcc? |
Date: | Thu, 27 Mar 2003 21:16:34 +1100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 |
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 fly3) 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
[Prev in Thread] | Current Thread | [Next in Thread] |