Re: [cc65] Optimization ideas

From: Dan <opendtv1yahoo.com>
Date: 2007-06-22 02:39:22
--- Ullrich von Bassewitz <uz@musoftware.de> wrote:
> On Thu, Jun 21, 2007 at 12:16:54AM -0700, Dan wrote:
> > 1. Save/restore "register" (zero page) variables
> with
> > a JSR to a subroutine, such as:
> 
> That will not work, since the offset in the register
> bank is not always 0..n,
> but may also be 3..5 or something else.

It would still work, but there would be unnecessary
saves/restores in that case. What causes this, by the
way? I know that register saving may be interleaved
with initialization, but why wouldn't the registers
always be allocated starting at 0?

> > 2. Implement a second "register" area in zero page
> > that would only be used by leaf functions (i.e.
> > functions that don't call other functions). These
> > would not need to be saved/restored.
> 
> No way with the current compiler. There is no
> immediate representation, so the
> save code is generated *before* the compiler knows
> it's a leaf function.

There are a couple ways to do it. You could make two
passes through the function source code (only when
needed), or you could do it at the assembly level. The
two pass method is probably much easier.

> Besides that, the current zeropage footprint is
> already a problem for some
> systems. Increasing zero page usage will limit the
> number of target systems.

Well, it would be an optional feature.

> > 3. Automatically assign local pointer/char/int
> > "register" status, and increase the default
> maximum
> > (only 6 bytes?)
> 
> See answer for 2.

Again, optional.

Dan



       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Jun 22 02:39:29 2007

This archive was generated by hypermail 2.1.8 : 2007-06-22 02:39:33 CEST