cc65: Getting large programs to fit.

[damosan]

I've been working on getting Mini-Scheme to compile using CC65 - it is a traditional not-8bit program in that is leverages a rather complex union and many getter/setter/istrue/isfalse/etc. macros.  On any 16bit processor this wouldn't be a problem.  On the 6502 on the other hand...

 

A few CC65 observations when trying to cram code into the Atari - they are, of course, variations on previous themes.  The difference in this case is an leveraging existing code vs. building something from scratch.

 

• Replace getter/setter/pseudo-function macros with traditional functions where possible.  Focus on the getter/setting/pseudo-function macros that are used throughout the code base first.  In one case I shaved ~2k from the binary by replacing a widely used macro with a function.  Average savings  was ~200 bytes for each macro.
• Replace *s++ = *c; with *s = *c; ++s; - requires less assembly to do the work.  It's not idiomatic C by any stretch but when you're trying to shave bytes from the binary...
• Don't forget to move critical globals to Page 0 - for performance.  Doing so will shave a byte each time the variable is accessed and increase performance.
• Disable select features.  In the case of Mini-Scheme it was was neat to see basic threading with call/cc work on an 8bit it was so slow that removal was the real answer.

[sanny]

So, does it fit now? If not, by how much?

[tebe]

or 

https://github.com/drmortalwombat/oscar64

 

Supported target machines
c64 : Commodore C64, (0x0800..0xa000)
c128 : Commodore C128, memory range (0x1c00..0xfc00)
c128b : Commodore C128, first 16KB only (0x1c00..0x4000)
plus4 : Commodore PLUS4, (0x1000..0xfc00)
vic20: Commodore VIC20, no extra memory (0x1000..0x1e00)
vic20+3 : Commodore VIC20, 3K RAM expansion (0x0400..0x1e00)
vic20+8 : Commodore VIC20, 8K RAM expansion (0x1200..0x4000)
vic20+16 : Commodore VIC20, 16K RAM expansion (0x1200..0x6000)
vic20+24 : Commodore VIC20, 24K RAM expansion (0x1200..0x8000)
pet: Commodore PET, 8K RAM (0x0400..0x2000)
pet16 : Commodore PET, 16K RAM (0x0400..0x4000)
pet32 : Commodore PET, 32K RAM (0x0400..0x8000)
nes : Nintendo entertainment system, NROM 32 K ROM, no mirror
nes_nrom_h : Nintendo entertainment system, NROM 32 K ROM, h mirror
nes_nrom_v : Nintendo entertainment system, NROM 32 K ROM, v mirror
nes_mmc1 : Nintendo entertainment system, MMC1, 256K PROM, 128K CROM
nes_mmc3 : Nintendo entertainment system, MMC3, 512K PROM, 256K CROM
atari : Atari 8bit systems, (0x2000..0xbc00)
x16 : Commander X16, (0x0800..0x9f00)

 

[Wrathchild]

what optimisation parameters are you passing? 

[TGB1718]

Try not passing parameters to functions, make as many variables global, even return values, I just tried

a simple call and saved 30 bytes by not passing a variable and not returning a value.

 

Use char instead of int where possible.

Edited January 29 by TGB1718

[damosan]

5 hours ago, sanny said:

So, does it fit now? If not, by how much?

Yes!

[damosan]

2 hours ago, Wrathchild said:

what optimisation parameters are you passing? 

Just -O

[Wrathchild]

45 minutes ago, damosan said:

Just -O

do try the 'i', 's', 'r' options (and combinations off)

 

-O, -Oi, -Or, -Os

Enable an optimizer run over the produced code.

Using -Oi, the code generator will inline some code where otherwise a runtime functions would have been called, even if the generated code is larger. This will not only remove the overhead for a function call, but will make the code visible for the optimizer. -Oi is an alias for -O --codesize 200.

-Or will make the compiler honor the register keyword. Local variables may be placed in registers (which are actually zero page locations). See also the --register-vars command line option, and the discussion of register variables below.

Using -Os will allow the compiler to inline some standard functions from the C library like strlen. This will not only remove the overhead for a function call, but will make the code visible for the optimizer. See also the --inline-stdfuncs command line option.

It is possible to concatenate the modifiers for -O. For example, to enable register variables and inlining of standard functions, you may use -Ors.

[damosan]

14 hours ago, Wrathchild said:

do try the 'i', 's', 'r' options (and combinations off)

 

-O, -Oi, -Or, -Os

Enable an optimizer run over the produced code.

Using -Oi, the code generator will inline some code where otherwise a runtime functions would have been called, even if the generated code is larger. This will not only remove the overhead for a function call, but will make the code visible for the optimizer. -Oi is an alias for -O --codesize 200.

-Or will make the compiler honor the register keyword. Local variables may be placed in registers (which are actually zero page locations). See also the --register-vars command line option, and the discussion of register variables below.

Using -Os will allow the compiler to inline some standard functions from the C library like strlen. This will not only remove the overhead for a function call, but will make the code visible for the optimizer. See also the --inline-stdfuncs command line option.

It is possible to concatenate the modifiers for -O. For example, to enable register variables and inlining of standard functions, you may use -Ors.

 

I believe -O optimizes for space while the other options are for speed via inlining.

[damosan]

16 hours ago, TGB1718 said:

Try not passing parameters to functions, make as many variables global, even return values, I just tried

a simple call and saved 30 bytes by not passing a variable and not returning a value.

 

Use char instead of int where possible.

 

Unsigned chars to be specific - same applies to words (or unsigned ints).  Sign extension is spendy from a time/space perspective.

[baktra]

Some standard library functions can be surprisingly "bulky" too, e.g. printf().