This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc compile-time performance
- From: Hans Aberg <haberg at matematik dot su dot se>
- To: dewar at gnat dot com (Robert Dewar)
- Cc: gcc at gcc dot gnu dot org, help-bison at gnu dot org
- Date: Mon, 20 May 2002 17:32:46 +0200
- Subject: Re: gcc compile-time performance
At 09:12 -0400 2002/05/20, Robert Dewar wrote:
>Well the point is that in a hand written parser, you can do intelligent
>backtracking which can never be done by any automatic tool.
This is no stranger than that one can do better writing in assembler than
using say a C/C++ compiler. In the past, computer time was expensive
relative programming time, but the equation is increasingly turned over,
making increasingly prudent spill computer over human cycles.
>This kind of error detection and correction is trivial. The hard thing is
>to do structural repair, e.g. when {} brackets do not match up, or when
>semicolons present or missing derail the structure.
As noted by Paul Hilfinger in the Bug Bison list, widespread access to
interactive computing makes it more prudent with a "compile to the first
syntax error, fix, and repeat" approach.
Also, modern languages (like say C++) making use of lot of context
information, which are better for humans, are difficult for computers to
make sensible error recovery: Typically some semantic information (like a
declaration) is lost, and the rest of the compile becomes unrecoverable and
nonsensical. That is, unless one is trying to capture that semantic
information, which is a computer language current research topic.
Hans Aberg