Re: Compiler Optimizing assembler

Werner Strydom <wstryd@ilink.nis.za> writes:


> In the mainframe environment there is many millions of code written in
> assembler, mostly the programmers have no previous high level language
> experience, so mostly it is unstructured. It can be assumed that
> "for" loops will look different depending on the programmer and
> situation.
>
> Has any reaserch been done optimizing (code duplication, dead code,
> speed optimitization) assembler programs? Where can I find it? All the
> papers I have regarding optimatiztion applies to high level languages.


Well, yes and no... actually, the vast majority of optimization
performed by compilers is done at an intermediate-language level
(e.g., "quads") which is _close_ to that of assembler language... but
this intermediate-level language level has enough implicit structural
information to make it far easier to optimize.


Our moderator commented that:


> [[optimization is] a big chunk of what "lower CASE" tools do,
> though I don't know how many of them work on assembler source. -John]


Unfortunately, the basic structural information needed to "lower"
COBOL to an intermediate language level is freely available even in
the worst of COBOL programs.


However, there has been some research in a closely related
area... many of the algorithms developed to perform more sophisticated
kinds of binary translation analyze object files and recreate some of
this extra intermediate-language level information, and it would seem
to me that these algorithms would also be usable for assembler
language source [a fair amount of work in this area was done by people
at Digital's Western Research Lab (WRL), including David Wall, who is
now at Silicon Graphics].


A few of the special problems involved in analyzing both assembler
language source and binary object files:


1. Determining branch targets (assembler programs can branch
_anywhere_... even unstructured GOTO-laden higher-level code can only
jump to the beginnings of statements, and usually only to those which
have explicit labels).


2. Tracing the lifetimes of scalar values in their passage through
various registers and in and out of storage.


3. Dealing with self-modifying code (an abomination in x86
land... thankfully, it is much less common in other architectures).
--
John R. Grout Center for Supercomputing R & D j-grout@uiuc.edu
Coordinated Science Laboratory University of Illinois at Urbana-Champaign
--

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