Related articles |
---|
Optimizing in assembly language rhyde@transdimension.com (Randall Hyde) (2001-03-01) |
Re: Optimizing in assembly language jim.granville@designtools.co.nz (Jim Granville) (2001-03-04) |
Re: Optimizing in assembly language sunni@speakeasy.net (Shankar Unni) (2001-03-04) |
Re: Optimizing in assembly language ts3@ukc.ac.uk (T.Shackell) (2001-03-08) |
Re: Optimizing in assembly language jguthrie@brokersys.com (Jonathan Guthrie) (2001-03-08) |
Re: Optimizing in assembly language l-desnogues@ti.com (Laurent Desnogues) (2001-03-08) |
Re: Optimizing in assembly language ceco@jupiter.com (Tzvetan Mikov) (2001-03-08) |
Re: Optimizing in assembly language adrian@sartre.cs.rhbnc.ac.uk (A Johnstone) (2001-03-08) |
Re: Optimizing in assembly language rhyde@transdimension.com (Randall Hyde) (2001-03-10) |
Re: Optimizing in assembly language me@nospam.net (Scottie) (2001-03-10) |
Re: Optimizing in assembly language thp@hill.cs.ucr.edu (Tom Payne) (2001-03-12) |
Re: Optimizing in assembly language rhyde@transdimension.com (Randall Hyde) (2001-03-14) |
Re: Optimizing in assembly language bonzini@gnu.org (2001-03-22) |
[7 later articles] |
From: | "Tzvetan Mikov" <ceco@jupiter.com> |
Newsgroups: | comp.compilers |
Date: | 8 Mar 2001 12:31:59 -0500 |
Organization: | @Work Internet powered by @Home Network |
References: | 01-03-006 |
Keywords: | optimize, assembler |
Posted-Date: | 08 Mar 2001 12:31:58 EST |
Randall Hyde <rhyde@transdimension.com> wrote in message
> So here's my question: why can't we write an "optimizing assembler"
> that lets the programmer specify machine sequences and the assembler
> does the same kinds of "book keeping" that a HLL compiler would do.
I did something similar in an experimental version of a 8051 C
compiler which I had developed as a student. It was a very simple
design, practically no register allocation, only ad-hoc optimizations
in the code generator. In order to produce at least somewhat nice code
I had implemented some simple optimizations on the generated assembler
instructions - remove chained jumps, convert long jumps to short ones,
replace jump to a ret with ret, eliminate the basic cases of
unreachable code (only the cases when the code doesn't jump to
itself), eliminate immediately obvious redundant loads to the
accumulator. Not much, but at least distinguished it from SmallC and
the likes ...
To do anything reasonable with my compiler one had to use really *a
lot of* inline assembler, had to manually pass function parameters in
registers, etc. In the end it was being used like a convenient macro
processor around the inline assembler ... :-)
A few years ago I had to revamp the compiler which meanwhile had been
used for a few projects. So, I added value numbering within basic
blocks. Because of the (ridiculously) bad design of the rest of the
compiler the optimizer couldn't use any high-level information (like
the location of temporaries on the stack, etc). It had to operate only
with machine registers and byte-sized memory locations, so it was
practically independent from anything else and able to work on
arbitrary 8051 assembler code. The interesting part was allowing it to
optimize the inline assembly statements (which actually happened by
mistake) - I got very encouraging results. The most improvements in
the output came from better "gluing" the assembler code with the
surrounding C code - the redundant stores putting things in
temporaries just to load them in a register in the assembler could be
removed without having to complicate the inline assembly syntax like
GCC or Watcom C does. In a few cases the optimizer actually managed to
remove instructions within the inline assembler - that naturally made
me enormously proud (although I had written the sub-optimal assembler
code on the first place:-).
I am not aware of any other compiler performing such optimizations,
but I think it could be very useful and not terribly hard to
implement.
-tzvetan
Return to the
comp.compilers page.
Search the
comp.compilers archives again.