Re: Optimizing in assembly language

Tom Payne <thp@hill.cs.ucr.edu>
22 Mar 2001 01:19:45 -0500

          From comp.compilers

Related articles
[7 earlier articles]
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)
Re: Optimizing in assembly language sunni@speakeasy.net (Shankar Unni) (2001-03-26)
Re: Optimizing in assembly language rhyde@transdimension.com (Randall Hyde) (2001-03-27)
| List of all articles for this month |

From: Tom Payne <thp@hill.cs.ucr.edu>
Newsgroups: comp.compilers
Date: 22 Mar 2001 01:19:45 -0500
Organization: University of California, Riverside
References: 01-03-006 01-03-085 01-03-092
Keywords: optimize, assembler
Posted-Date: 22 Mar 2001 01:19:45 EST

Randall Hyde <rhyde@transdimension.com> wrote:
: "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 amend
: my claim to "the typical case".


Since we are talking about programs for some given finite
architecture, every real-world program has an optimum equivalent. For
resource-constrained program optimization, the current situation is is
similar to man-vs.-machine chess of say 20 years ago. Each year,
however, it becomes more difficult for humans to continue winning, and
it is not clear to me that even the best humans will always be able to
win in chess or program optimization.


[...]
: Clearly to pull off an optimizer in assembly language, the assembly
: must be made a little richer than the traditional variety.


Also, some restrictions would help, e.g., preventing self modification
and unrestricted indirect jumps.


[...]
: 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,


VirtualPC and FX32!


: 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).


Once the flow graph of an assembly language program has been
determined, I would assume that the usual optimization tricks can be
applied. So, what are the special difficulties in determining the
flow graph of an assembly langauge program?


Tom Payne


Post a followup to this message

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