Re: Jack W. Crenshaw - Any clues how to optimize ?

David Whitten <whitten@netcom.com>
18 Apr 1999 02:01:03 -0400

          From comp.compilers

Related articles
Jack W. Crenshaw - Any clues how to optimize ? prinz@c2i.net (XlatB) (1999-04-09)
Re: Jack W. Crenshaw - Any clues how to optimize ? torbenm@diku.dk (Torben Mogensen) (1999-04-18)
Re: Jack W. Crenshaw - Any clues how to optimize ? whitten@netcom.com (David Whitten) (1999-04-18)
Re: Jack W. Crenshaw - Any clues how to optimize ? mallors@ips1.msfc.nasa.gov (1999-04-19)
Re: Jack W. Crenshaw - Any clues how to optimize ? bill@megahits.com (Bill A.) (1999-04-22)
Re: Jack W. Crenshaw - Any clues how to optimize ? andersh@maths.lth.se (Anders Holtsberg) (1999-05-03)
Re: Jack W. Crenshaw - Any clues how to optimize ? mikee@cetasoft.cog (1999-05-07)
| List of all articles for this month |

From: David Whitten <whitten@netcom.com>
Newsgroups: comp.compilers
Date: 18 Apr 1999 02:01:03 -0400
Organization: ICGNetcom
References: 99-04-034
Keywords: optimize

XlatB <prinz@c2i.net> wrote:
: I am working on simple compiler (currently only a "basic" to x86 asm
: converter). It is based on the model by Jack W. Crenshaw. (Author of
: "Let's build a compiler" or something very similar). I am having
: problems to accept the inefficiency on the expression calculations.
: The code output is way below acceptable. Now i was wondering, how do i
: optimize this to be any better?


Well, generally if I have no idea what your code output looks like, my
first impression is that you need to explore a peep-hole optimizer.
This is a program that looks for patterns in your generated code and
replaces fragements of code that it recognizes with 'better' code that
does the same thing.


In an ideal world, you can make the peep-hole optimizer look for the
patterns to match in a table and get the 'translation' from the table
as well. Generally, you may have to get the translation from a
function call that looks at the pattern and the code that matched it
and generates a 'translation' that fills in the blanks in the
generated code from looking at the sequence/data that filled those
blanks in the original code.


The sophistication of your matching algorithm can affect how big the
table of patterns and translations is.


: I was thinking about a postfix
: solution, but since this compiler is going to a singleparse, i have to
: do this exclusivly for expressions.


I'm not sure what postfix has to do with this, unless you mean a pass
that traverses the code after it is generated. (which is what a
peep-hole optimizer does).


:I havent been able to write a good
: solution for this problem, as if often tend to "fixing" the postfix
: routine. Could someone help me with this?


I hope this helps, perhaps you mean that the postfix routien is the
one which back-patches your generated code (to substitute jump
addresses and other things that can't be 'resolved' in a single pass ?


: And also, i have problems
: on designing the string allocation system. The target mode is Windows
: Protected mode. Could someone give me some clues to this, as i am
: still a bit off.


I would guess there are public domain code libraries (like GNU malloc)
that would provide a system to do string allocation. Could you use them?


David


Post a followup to this message

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