From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-12-09 21:06:57
Hi!
On Tue, Dec 09, 2003 at 07:10:19PM +0100, Spiro Trikaliotis wrote:
> Ok, I have not though about inline assembly.
It's not only inline assembly. Other optimization stages may generate such
code. Look at this:
ldx foobar+1
tax
sta charvar
lda foobar
ldx foobar+1 ; #1: Get argument
jsr _some_function ; Call a fastcall C function
As you can easily see, the second load of foobar+1 is unnecessary. Since a
call to a C function follows immediately, it is easy for the compiler to spot
this, so it may remove the instruction labeled #1. If a later step changes the
first three instructions and remove the load of X, you get into trouble. So
even if such code is never generated by the user or higher stages of the
compiler, the optimizer must know how to handle it.
> >From your statement, I assume that cc65 optimizes on the assembly code
> itself, not on any type of intermediate code?
Yes. The cc65 compiler is derived from Small C which generates assembly output
in one, direct step. A lot has changed since these days, but this is still as
it was. JRD had added a very simple peep hole optimizer as a separate program,
replacing known patterns of two or three consecutive lines (mostly subroutine
calls). When starting to extend the compiler I replaced this by an integrated
peep hole optimizer, but for a quite some time, this optimizer did pattern
matching on text lines, which prooved to be a nightmare to extend and
maintain. So I replaced the backend by an abstraction of 65C02 code. Each
instruction and each label is now a data structure, containing lots of
information about the context. This is not perfect but it made many things
possible that were not possible before. It would still be nice to have
optimizations also on a higher level, since some of the information available
there is lost when generating output.
> From my rememberings of
> compiler writing, a coverage analysis (which was told as being always
> done) tells me when a value is surely not needed anymore, and such an
> analysis would be done even for register contents in the optimization
> state (well, I must admit that I think this was told in university, but
> I'm not sure 100%). This information would be sufficient, but from your
> statement, I assume this information is not available, is it?
The optimizer can tell when a register value is not needed any more. It does
even some flow analysis, so it can tell if a register has a specific value at
a branch label. I didn't say that the register information is not available in
my last mail, I just tried to give a reason why the issue is not as simple as
it looks. The optimization can be done, and in fact the compiler does lots of
more difficult optimizations, but it's not as simple as exchanging three lines
of code by two others.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-12-09 21:07:21 CET