Related articles |
---|
[10 earlier articles] |
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) |
From: | Martin.Ward@durham.ac.uk (Martin Ward) |
Newsgroups: | comp.compilers |
Date: | 26 Mar 2001 13:42:15 -0500 |
Organization: | Compilers Central |
Keywords: | optimize, assembler |
Posted-Date: | 26 Mar 2001 13:42:15 EST |
Tom Payne <thp@hill.cs.ucr.edu> writes:
> 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?
Self-modifying code, branch to register (eg: read some characters
from the keyboard, do some arithmetic, treat the result as an address
and branch to it...).
See http://www.dur.ac.uk/martin.ward/martin/papers/icsm99-t.ps.gz
for a few more problems with analysing assembler (and our solution...)
Martin
Martin.Ward@durham.ac.uk http://www.dur.ac.uk/martin.ward/ Erdos number: 4
Return to the
comp.compilers page.
Search the
comp.compilers archives again.