Re: [cc65] Optimizations needed!

From: Agent Friday <64subnet1gmail.com>
Date: 2010-11-27 09:32:15
What does your memory map look like?  If you haven't already played
with your config file, you might try some of these...

 1.  Find a way to use the    RAM under Kernal ROM
 2.  Use RAM under the I/O area.
 3.  Make any init code only needed at startup disposable.  Note
   that the standard startup and init are to blame for 200+ bytes of
   code that could be discarded, but the default configurations
   leave it all in memory.  You'll need to play with what you can
   throw out and how to make it happen.  (I haven't experimented
   with this yet.)
 4.  Make use of the cassette buffer for something.  It's only 192
   bytes, but a byte is a byte.

1 and 2 give you another 12K, which is more than you'll gain from
any of the other things suggested (I think), and with less effort
and less performance issues.  Just as with overlays, you'll have to
experiment with what code can go there most easily.  Any code that
is rather isolated from I/O and Kernal calls will avoid the need for
a lot of stubs to bank RAM in & out around function calls.  Core
parsing logic might be a good candidate.  Also beware of interrupts
that assume I/O and Kernal are banked in; you may need to SEI/CLI
around the hidden code.

> 9. Never use printf. The library code to handle it is huge. Write
>   your own functions

Perhaps this is slightly exaggerated.  Some details might help put it
into perspective.  I just compiled a number of test programs for
the C64...
  a)  A bare-bones "Hello World" program is smaller than 400 bytes.
  b)  Add a single /trivial/ printf( ""); and you incur a hit of
    just over 2K increase in code size.
  c)  That's it.  No matter how much you use the printf features,
    you've already paid for the library code.  Any additional size
    increase will be from the actual calls you add.

2K is not insignificant, but considering what you get, it seems like
a bargain to me.  It might be a good candidate to go under I/O,
since all you would need to have accessible at all times would be
the outer printf function, modified to bank in RAM before calling
the internal (non-variadic) function.

// Agent Friday
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sat Nov 27 09:32:22 2010

This archive was generated by hypermail 2.1.8 : 2010-11-27 09:32:26 CET