Re: Project on Compiler

alluri@utdallas.edu (Sridhar Alluri) writes:
>We are supposed to write a compiler for a subset of Pascal. I would like
>to know how complex the project is going to be. ...


samiam@netcom.com (Scott Moore) writes:
>I've done two Pascal compilers now. Writing a full compiler from scratch
>to date of passing test suites seems to be about 1 year minimum.


I'm working on a PASCAL for OS/2 as a sides spin of my research, and the
writting of the frontend alone took me almost a year. Partially due to
the fact that I had to get used to the Cocktail compiler tools. But this
investment is starting to pay off. I find very few programming bugs in the
code. Usually they are ommissions of "features" I decided to add later.


Doing a backend in Beg is taking me again already 6 months. Mostly because
I'm doing it my evening hours. That's a i{3,4}86 which ain't too much fun
to generate efficient code for. But I'm working on it :-)


> However, I think that the project could be cut down to size quite easily.
> First (as is usual for college projects), you output only pseudocode for
> interpretation. Skipping the "real world" coding aspects saves a lot of
> time. Second, you will save a good deal by implementing only elementry or
> no error recovery (ie., simply terminate on error). Of course, you'll miss
> an important subject by not doing this, and it may not be admissable to
> your teacher. However, implementing a minimum error recovery scheme (such
> as simple symbol set skipping) will probally do what you need. As
> mentioned, the fastest way to do the parser is with a tool and a
> predefined grammar, but a parser for full pascal can be finished in 2
> weeks to 1 month in normal C or Pascal code. People are going to yell at
> me for being old fashioned, but I prefer "hardcoding" it to yacc. If you
> are a beginner, yacc is one more thing to learn, but if you are an expert,
> you get more control in straight code.


Doing a parser and scanner was not what I found to be the hard part. And
since you're on the topic of errors. Cocktail already default to a fairly
good error recover. There are ways to get it to mess up real bad, but on
average it is very useable.


Doing it the "hard" way is sort of fun for a small toy-language. But I
found that I did not learn much from it. Or at least it didn't stick.
Doing error revocery in something like recursive descent is a standard
technique, and as such the first few items to implement are fun. But after
that routine strikes and it gets borring rather fast.


Most of my effort was spent in doing Semantic Analysis, and generating in
formative messages. Al lot of this can be skipped for a "toy" compiler.
As long as you derive a minimum set of attributes to guide the code
generation.


> I suspect that you will find that your subset has been chosen to eliminate
> most of the really nasty sections of the language, so your job will not be
> as complex as it sounds.


The most complex part I found was to efficiently code sets which aren't
restricted to 0-255 elements. Currently I'm looking at doing set which
range from -32K to 32k, but haven't found the uptimum implementation.


> Finally, there are several examples of exactly what you are trying to do
> already in print. See for instance, the Pascal-s compiler [wirth] and
> Brinch Hansen's stuff.


Also note that some code is available:
ftp.eb.ele.tue.nl:/pub/src/pascal




Willem Jan
--
Digital Information Systems Group, Tel: +31-40-473401, Fax: +31-40-433066
Room EH 10.35 Eindhoven University of Technology
P.O. 513, 5600 MB Eindhoven, The Netherlands
Internet:wjw@eb.ele.tue.nl,
X400:C=nl;A=400net;P=surf;O=tue;OU=ele;OU=eb;S=WJW;
--

Return to the comp.compilers page.
Search the comp.compilers archives again.