|[20 earlier articles]|
|Re: Intermediate Representation email@example.com (1990-08-18)|
|Re: Intermediate Representation firstname.lastname@example.org.OZ.AU (1990-08-20)|
|intermediate representation email@example.com (1991-02-20)|
|Re: intermediate representation firstname.lastname@example.org (1991-02-22)|
|Re: intermediate representation email@example.com (1991-02-23)|
|Re: intermediate representation firstname.lastname@example.org (1991-02-26)|
|Re: intermediate representation email@example.com (1991-02-27)|
|Re: intermediate representation firstname.lastname@example.org (1991-03-04)|
|From:||email@example.com (Dave Jones)|
|Organization:||Megatest Corporation, San Jose, Ca|
|Date:||27 Feb 91 20:12:26 GMT|
As you know, there are lots of optimizations that can be described in a
machine-independent way as correctness-preserving algorithm-transformations.
You really want to work those optimizations on the machine-independent
intermediate representation, but whether or not they really win or lose is
machine-dependent. It looks like a sitch where the "front end" and "back end"
need to collaborate, rather than run one after the other. I recently wrote a
special-purpose Pascal compiler on that principle, and I've started my second
"back end" for it (SPARC). But alas, the application does not warrant
investing much in optimization at this time, because the Pascal layers of
these application programs account for a very small percentage of the
execution-time. So I don't have any war stories to tell re. optimization. A
really nifty implementation of the scheme might use coroutines.
Return to the
Search the comp.compilers archives again.