The RODATA size savings would have to be at least as much as the size of the decompression code needed to expand it to be worthwhile. Also, of course, your target platform has to have RAM to put the RODATA segment into. If your platform is one that loads the entire program into RAM anyway, why not just compress the whole program and add a decompressing stub. There are utilites that did this on a lot of platforms, turning a binary executable into a smaller one. If you can find such a utility it would probably do a better job of making your binary smaller (and be simpler to use) than trying to compress only the RODATA automatically as a linker step. -- Brad Smith On Tue, Jan 8, 2013 at 12:02 AM, Payton Byrd <plbyrd@gmail.com> wrote: > It would be nice if there was an option to tell LD65 to compress the RODATA > segment and then write it to a RAM segment on initialization. Since gzip is > already part of the CC65 toolset, wouldn't it be reasonable to have the data > compressed with gzip and then written out using the gzip library? ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Tue Jan 8 06:39:45 2013
This archive was generated by hypermail 2.1.8 : 2013-01-08 06:39:48 CET