Re: [cc65] RODATA strings

From: Groepaz <groepaz1gmx.net>
Date: 2009-12-06 06:39:16
On Samstag 05 Dezember 2009, Ullrich von Bassewitz wrote:
> On Tue, Dec 01, 2009 at 10:42:20PM -0800, Shawn Jefferson wrote:
> >    I was looking at an app I wrote trying to reduce size and I noticed I
> > have quite a few strings that are the same in cputs (press any key type
> > messages) calls.  Does cc65 already remove redundancy with these
> > read-only strings?
>
> Ok, I've used this as a motivation to add the changes to the literal string
> handling I had in mind for a long time (actually, it was a complete
> rewrite).
>
> String literals are now stored together with other function data and merged
> if possible at the end of the compile run.
>
> Visible differences to 2.13 are:
>
>   * String literals from static functions that aren't used are now removed
>     together with the function. In 2.13, the function code and data was
>     removed, but literal strings remained in the literal pool.
>
>   * Readonly string literals are merged if possible. This is also true for
>     partial strings, which means "world" is merged with "hello world".
>
>   * New #pragma writable-strings allows fine grained control of literal
> string storage.
>
> So if your program uses more than just a few strings, chances are that the
> binary is now smaller than before.

i recently stumbled about that after

#pragma rodata-name (push,"MENUOVLRODATA")
...
cputs("foo");

the "foo" string would not actually end up in the rodata segment i defined, 
but in the regular one. could that be fixed too ? :)

-- 

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ftp.pokefinder.org

A 'hacker' is any person who derives joy from discovering ways to circumvent 
limitations. 
<Robert Bickford>

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sun Dec 6 06:38:50 2009

This archive was generated by hypermail 2.1.8 : 2009-12-06 06:38:53 CET