Re: [cc65] Memory impact of Atari library compile time defines

From: Ullrich von Bassewitz <>
Date: 2009-11-20 09:39:05
Good morning!

On Thu, Nov 19, 2009 at 11:59:54PM +0100, Christian Grössler wrote:
>> I cannot really comment on these two. But uppercasing file name string
>> literals in the source code is not really a problem.
> Hmm, yes, of course. But what about user input of filenames? If the C
> code would have to deal with this I think it would have a bigger memory
> impact.

If the program reads a filename from the user, it does also need some sort of
input processing that distinguishes between valid and invalid file name
characters. There's absolutely no problem in doing a toupper or strupper()
here. The toupper routine has 16 bytes, plus the call = 19 bytes. This is much
cheaper than ucase_fn.

> I've invented these customizable defines in the Atari library makefile
> in order to provide a default configuration which works out of the box
> for most users. ("users" are in this case the developers using cc65,
> not the "end users" running the program.)
> But give advanced users a way to do some adjustments.

Is there anybody who has tweaked these settings before?

>> And, browsing through
>> crt0.s and ucase_fn.s, I can see a few places where it is possible to save a
>> few bytes of code.
> Please tell me where. 4 eyes see more than 2 eyes :-)

        lda     #0
        sta     LMARGN
        lda     #$FF
        sta     CH

        ldy     #0
        sty     LMARGN
        sty     CH

str_end:iny                     ; room for terminating zero
        cpy     #128            ; we only can handle lenght < 128
        bcs     toolong
str_end:iny                     ; room for terminating zero
        bmi     toolong         ; we only can handle lenght < 128

This is what I found without much searching. I assume there's more.

I would also remove the check for ATEOL as string terminator. It's a C
environment, and I cannot think of a case where someone terminates his strings
with ATEOL.

In crt0.s: Setting sp in a constructor needs three additional bytes. Since the
constructor is always executed, I cannot see a real need for using it. If you
want to have code only used once in the INIT segment, you can use a subroutine
call and move most of the other startup code there.

> Simpler or smaller? I've tried to make it optimal for any ".if" case.

I haven't tried it, but always allocating 128 bytes on the stack and combining
the check & copy loops should save a few bytes. When doing so, you can also
try to do the uppercasing in the loop and save the call to strupr.

> Old memory usage (copied from my previous mail):
> default configuration:
> -rw-r--r-- 1 chris chris  557 Nov 15 16:23 empty
> -rw-r--r-- 1 chris chris 3277 Nov 15 16:23 hello
> -rw-r--r-- 1 chris chris 2055 Nov 15 16:33 open
> New memory consumption (current svn):
> default configuration:
> -rw-r-----  1 chris  wheel   291 19 Nov 23:09
> -rw-r-----  1 chris  wheel  3150 19 Nov 23:09
> -rw-r-----  1 chris  wheel  2054 19 Nov 23:09

Now, that's an achievement! Removing the file name uppercasing will save half
a KB. I would really think about that :-)



Ullrich von Bassewitz                        
To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Nov 20 09:39:16 2009

This archive was generated by hypermail 2.1.8 : 2009-11-20 09:39:18 CET