Re: Optimizing in assembly language

"Tom Payne" <thp@hill.cs.ucr.edu> wrote in message
> Randall Hyde <rhyde@transdimension.com> wrote:
> [...]
>: Clearly, given the necessary resources (time, skill, etc.), an expert
>: assembly program *can* beat a compiler for a given *instance* of the
>: program.
>
> It's not clear to me. For a finite machine, given sufficient
> resources, a programmer and a compiler could each find an optimum
> (i.e., unbeatable) "instance" of the program.


Touche.
However, very real world programs are optimal. So I must ammend
my claim to "the typical case".


> AFIK, all low-level language translators (attempt to) decompile
> decompile programs in their source language into some sort of
> intermediate code that can be optimized and code-generated into the
> target language. AFIK, such systems don't handle self-modifying code
> and tend to have problems with indirect jumps.


These same problems exist in HLLs (yes, people do write self-modifying
code in HLLs, I've helped many a person do this).


Clearly to pull off an optimizer in assembly language, the assembly
must be made a little richer than the traditional variety. You need
the ability to declare "volatile" locations (so the critical region
"optimization" mentioned earlier in this thread doesn't occur)
and it would help if one could provide hints in the language
about the addresses a pointer may contain. Other hints,
like "pure" functions, etc., would be quite useful.


As to the intermediate language, I *have* seen research that attempts
to reduce machine code to a set of basic micro-operations in an
attempt to translate the machine code to a different processor. While
this research has yet to produce anything practical, clearly this is
an optimization problem and the same techniques could be applied to an
optimizing assembler (in which case the target processor would be the
same as the source processor).


Randy Hyde

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