Re: Optimizing in assembly language

"Randall Hyde" <rhyde@transdimension.com>
14 Mar 2001 00:11:54 -0500

          From comp.compilers

Related articles
[5 earlier articles]
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)
Re: Optimizing in assembly language thp@hill.cs.ucr.edu (Tom Payne) (2001-03-22)
Re: Optimizing in assembly language Eric.Boon@ICT.nl (Eric Boon) (2001-03-22)
Re: Optimizing in assembly language uabbwat@uab.ericsson.se (Barry Watson) (2001-03-26)
Re: Optimizing in assembly language Martin.Ward@durham.ac.uk (2001-03-26)
Re: Optimizing in assembly language joachim_d@gmx.de (Joachim Durchholz) (2001-03-26)
[2 later articles]
| List of all articles for this month |

From: "Randall Hyde" <rhyde@transdimension.com>
Newsgroups: comp.compilers
Date: 14 Mar 2001 00:11:54 -0500
Organization: Posted via Supernews, http://www.supernews.com
References: 01-03-006 01-03-085
Keywords: optimize, assembler
Posted-Date: 14 Mar 2001 00:11:54 EST

"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


Post a followup to this message

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