Tips and Tricks to reduce code size (unused code)

Comments

• Mike Green Posts: 23,101

  2013-06-18 21:58 edited 2013-06-18 21:58

  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 Posts: 386

  2013-06-18 22:01 edited 2013-06-18 22:01

  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 Posts: 23,101

  2013-06-18 22:14 edited 2013-06-18 22:14

  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 Posts: 11,803

  2013-06-18 22:17 edited 2013-06-18 22:17

  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 Posts: 386

  2013-06-18 22:17 edited 2013-06-18 22:17

  @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 Posts: 4,313

  2013-06-21 07:13 edited 2013-06-21 07:13

  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 Posts: 23,101

  2013-06-21 07:35 edited 2013-06-21 07:35

  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.