Re: multiple unary operators problem

Chris F Clark <cfc@shell01.TheWorld.com>
14 Oct 2005 17:22:52 -0400

          From comp.compilers

Related articles
multiple unary operators problem zaharije.pasalic@pmf.unsa.ba (2005-10-13)
Re: multiple unary operators problem jatin.bhateja@amdocs.com (Jatin Bhateja) (2005-10-14)
Re: multiple unary operators problem cfc@shell01.TheWorld.com (Chris F Clark) (2005-10-14)
Re: multiple unary operators problem kenrose@tfb.com (Ken Rose) (2005-10-20)
| List of all articles for this month |

From: Chris F Clark <cfc@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: 14 Oct 2005 17:22:52 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 05-10-076
Keywords: design, practice
Posted-Date: 14 Oct 2005 17:22:52 EDT

Zaharije Pasalic wrote:
> Now I want to build optimization for p-code.


I would recommend finding Frederick Chow's Stanford Thesis, "A
Portable Machine-Independent Global Optimizer -- Design and
Measurements". He attacked exactly the problem you would like to play
with (building an optimizer for pcode) and came up with an elegant
solution that became the basis of a whole suite of compilers for
numerous companies.


You also might want to read Bob Morgan's book, *Building* *an*
*Optimizing* *Compiler*. He was there when we built on Chow's work to
do optimization for the DEC Alpha with the Unix group, and then did
the same thing in the Gem group. As I recall, his book gives a lot of
insight into exactly how one fits the parts together to make a
coherent whole. If I were to teach a [2nd] course in compiler
construction, I would probably select that book as the text.


BTW, the short answer to your question is that when I build a
compiler, I build the basic block structures in a separate pass from
parsing, so that each pass is simpler. Simplicity tends to breed
correctness. The Verilog compiler I recently wrote has probably 6-10
phases between the parsing and the IL which is used for generating
code and it doesn't do any significant optimization. That number of
phases has reached the point of diminishing returns for the problems
attempted by the compiler in question, so don't go overboard in making
separate phases either. However, many folks have discovered, that
buliding separate phases (especially with human readable input/output
forms) allows one to tinker quite effectively with the tool--just look
at the success of SUIF.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------


Post a followup to this message

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