Tips and Tricks to reduce code size (unused code)

ags

I'm running into memory limits and am looking for ways to reduce code size. One obvious thought is to remove unused code. At the same time, I would like to create "packages" - i.e. SPIN objects - to promote reuse. Whenever an element in an object (PUB) is used more than once that's saving memory. However, after running a simple test case comparing the complied size of a SPIN file with and without an unused (uncalled) PUB method, it appears that the method is included in the compiled code.

Other than having to manually trim out any unused methods, what tips and/or tricks are there to address this challenge?

Thanks.

Mike Green

BST and Homespun are 3rd party Spin compilers that have options to eliminate the code for methods that are not used in the program. The Propeller Tool does not eliminate individual methods in objects

ags

So if I'm using SimpleIDE (which I'm not at the moment), which uses bstc for SPIN files, then this is the behavior I'd expect?

Mike Green

If you use the appropriate option, BSTC will do the optimization as well. I think the option is "-Or", but check the manual for details.

jazzed

ags wrote: »

So if I'm using SimpleIDE (which I'm not at the moment), which uses bstc for SPIN files, then this is the behavior I'd expect?

In the Project Manager panel click the Compiler tab.

Add this to Other Compiler Options: -Ogcrux


This is the bstc options help.

sh-3.1$ bstc
Brads Spin Tool Compiler v0.15.4-pre3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 19:57:58 on 2010/01/15
Program Usage :- bstc (Options) Filename[.spin]
 -a            - Create Propeller object archive zipfile
 -b            - Write .binary file
 -c            - Write .dat file for C-Compiler (Drops a <filename.dat> file)
 -d <device>   - Device to load to (Default : )
 -D <define>   - Define a pre-processor symbol (may be used multiple times)
 -e            - Write .eeprom file
 -f            - Double download baud rate
 -h            - Display this help information
 -l[sm]        - Generate listfile (s) For source code / (m) for Machine readable - Debugger style listing
 -L <Lib Path> - Add a library path or file holding library path(s) to the searchpath (may be used multiple times)
 -o <filename> - Output [.list/.eeprom/.binary/.zip] Filename (Defaults to input Filename without .spin)
 -O <options>  - Optimise Binary (HIGHLY EXPERIMENTAL!!!!!)
    a          - Enable all optmisations (Be careful! No, really)
    b          - Bigger constants (should be slightly faster at the expense of code size)
    c          - Fold Constants
    g          - Generic "safe" size optimisations for smaller/faster code, however not what the Parallax compiler will
generate
    r          - Remove unused Spin Methods
    u          - Fold Unary "-" Operations on Constants if it will make the code smaller
    x          - Non-Parallax compatible extensions
 -p[012]       - Program Chip on device (-d)
    0          - Load Ram and run
    1          - Load EEProm and shutdown
    2          - Load EEProm and run
 -w[012]       - Error/Warning level - 0 - Errors only / 1 - Error/Warning / 2 - Error/Warning/Information (Default 0)
 -q            - Be silent except for GCC style errors and warnings
 -v            - Get program version information

ags

@Mike Green: Particularly with the memory limitations of the Propeller, I'm surprised this isn't supported by the Propeller Tool. It may be speculation, but any insight into why this isn't default behavior?

Are the only other alternatives that come to mind: a) create objects that have few methods (or methods that are always used together) or b) manually prune for each usage?

@jazzed: I'll give this a try when I get to my "other" machine. Thanks.

prof_braino

ags wrote: »

other alternatives

If you are open to other alternatives, there is at least one that works quite well but is not spin code per se.

If you can use forth, propforth has a simple solution.

Using the SD kernel, the propforth kernel runs on the prop, and has the ability to call "files" from the SD. The SD "files" can be scripts of forth words, and need not include additional definitions. The scripts can be loaded from SD and executed on the fly. Each cog can load and execute scripts. Each cog can execute any sequence of scripts. A well crafted application could exist as a series of calls to SD script files, and you can go as big as you please. If you create your log or other output file last, it can be as big as the remaining SD. Otherwise just reserve space the max size you need.

Since script loading and execution happens on the fly, the transfer time for the SD is not a bottleneck (at least its been negligible so far). SD transfer time only becomes an issue if you create huge log files (greater than many megagbytes) then you have to wait when you transfer these to the PC, as the propforth files are not directly compatible with FAT file system. A logfile of 180 megs took like a day to transfer to the PC. Of course you could write a PC side driver program to speed this up, but that has not been needed so far.

Mike Green

The Propeller Tool was developed first. It was smart enough to eliminate the code for multiple instances of a complete object. The authors of the subsequent compilers had the benefit of experience in seeing the value of eliminating the code for unused methods within an object. They also saw the benefit of adding a macro preprocessor. It's always tough to be first with a chip design, language design, compiler design, etc. Everybody, with the benefit of experience with the results, asks "why didn't he ...". Sometimes it's a matter of saying "that's enough ... this thing has to get out the door". Sometimes the task looks a little too hard to do at the time, maybe too much would have to be tweeked, who knows.