Re: How hard is it to write a compiler ?

vbdis@aol.com (VBDis)
23 Oct 2000 22:17:06 -0400

          From comp.compilers

Related articles
How hard is it to write a compiler ? pradeeptumati@excite.com (Pradeep Tumati) (2000-10-22)
Re: How hard is it to write a compiler ? rbenedik@fsmat.htu.tuwien.ac.at (Ronald Benedik) (2000-10-23)
Re: How hard is it to write a compiler ? chase@naturalbridge.com (David Chase) (2000-10-23)
Re: How hard is it to write a compiler ? lionelp@worldonline.co.za (Lionel Pinkhard) (2000-10-23)
Re: How hard is it to write a compiler ? vbdis@aol.com (2000-10-23)
Re: How hard is it to write a compiler ? dlindauer@notifier-is.net (david lindauer) (2000-10-26)
Re: How hard is it to write a compiler ? jason@pattosoft.com.au (Jason Patterson) (2000-10-26)
| List of all articles for this month |
From: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 23 Oct 2000 22:17:06 -0400
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 00-10-170
Keywords: practice

Pradeep Tumati <pradeeptumati@excite.com> schreibt:


>Also, what is the time required to complete
>these two compilers with all the available tools.


First you should specify the tasks and their priorities.


Every compiler should:
- have a correct parser, with regards to the grammar
- create working executable code, without bugs
- create usable output files (object file format...)


But the quality of a compiler manifests in other areas:


- how good is recovery from syntactical and semantical errors in source code?
- how efficient is the generated code, with regards to comparable compilers?


Error reporting and recovery IMO is one of the most time consuming
parts of every compiler implementation. It's of really no help to the
user, when the compiler aborts with a message of "error in source
code". Instead the parser must roll back the not yet processed tokens,
until it finds the begin of the problem in the source code. And from
that place it should skip the source code until it reaches another
starting point, and resume parsing the source code there.


Efficient code requires many optimizations, and here AFAIK gcc only
implements a peephole optimizer, limited to very few instructions. A
good optimizer must start at a much more global view of the source
code, and must detect common subexpressions, dead code, and many other
syntactical constructs, which are subject to possible optimization.


Often different compilers are used, one to debug the source code, and
another to create the final executable code. The developer needs an
compiler with best error diagnostics, whereas the final executable
deserves an compiler with the best available optimization. Not all
compilers do a good job in both areas of interest, but every usable
compiler must be good in at least one of these areas.


DoDi


Post a followup to this message

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