Objective Modula-2 wrote:
Kevan Hashemi hashemi@brandeis.edu wrote:
From here, we continue to enhance the compiler in steps. Each step requires defining a new feature without the use of the new feature. Frank says he does not like that, but I'm fine with it.
I like it in theory, I just don't think it will work in practice, given the available manpower, in a reasonable amount of time.
However, if you want your compiler front end to be written in Pascal, I would recommend against bison. The most natural way to write a Pascal compiler would be to write an RD parser by hand. RD parsers have the advantage that it is possible to understand what they do by reading the source code. For each rule in the grammar there is a corresponding Pascal function/procedure. Table driven parsers have their logic in data tables and therefore it is very difficult to figure out what is happening by reading the code, you really need a debugger to get an understanding.
Maybe you misunderstand how parser generators are used. You don't read and debug the generated tables. Instead you read and write the grammar rules whose syntax is similar to BNF, i.e. what you find in standard documents and such. To debug problems in your grammar, you look e.g. at Bison's verbose output. To debug problems when Bison mis-translates your rules -- well, I've yet to encounter that ...
I've given reasons and examples why I'm convinced a manually written parser is not a good idea. You ignored them. Now, I don't want to sound smart-assed, but I'm actually talking from a few years of experience. Of course, you're allowed to repeat others' mistakes if you prefer.
I would recommend a book by Per Brinch Hansen titled "Brinch Hansen on Pascal Compilers". It handles RD parsing of Pascal and includes source code and commentary for a Pascal-subset compiler.
Oh look, another subset compiler ...
The problem with subset implementations is that they usually leave of the tricky parts. Sure, for a new project you might want to go for a subset. It's just not a project I'm interested in. Any project useful to me would have to be backward-compatible to the current GPC, which does not handle a subset, but actually a large superset of various Pascal dialects, many of them less clean in themselves than the original language. Good look parsing that manually.
samiam@moorecad.com wrote:
P5 is a much better basis for a compiler front end, being 40 years old, very well documented, and completely ISO 7185 compliant (not a subset), and completely free of copyright or license encumberments.
Where is the copyright/license/public domain statement from its authors? I didn't find them in p5.zip from your web site. Note that "no copyright notice" doesn't mean "no copyright", but in fact the opposite "all rights reserved" is the default. Like it or not, that's the legal situation.
Marrying the GCC front end to the backend as a single program was a classically bad design decision that I have always suspected was made for the goals that others here have described.
I don't think so. In the 1980s, when it started, writing and reading an extra file would have caused notable performance loss (and extra coding effort, of course -- I suppose they didn't have unlimited resources then either). If you're brave, look at the cpp (preprocessor) sources of old gcc versions sometime to see which horrible hacks they did just to squeeze some cycles.
Frank