Minimizing RAM usage

I am running into the limits of propeller RAM for my code and data and am looking at how to reduce it. I have a LCD display library which is rather large and I only use a small fraction of the methods available in it. Does the SPIN interpreter load the entire library into RAM or only the methods that are used? If the former, I could simply delete the unused methods and reduce my RAM usage. Thanks.


  • 14 Comments sorted by Date Added Votes
  • T ChapT Chap Posts: 3,635
    edited April 13 Vote Up0Vote Down
    What are you compiling with. BST will allow some optimization which is a life saver for me.
  • It's not down to the Spin interpreter. The interpreter can only run through whatever is loaded.

    As far as I understand the original Propeller Tool will include everything into the binary for download, even unused methods.

    Tools made by others do not. I think BST is one of them. Perhaps PropellerIDE. You might like to try those tools.

    You could indeed manually delete any methods from any objects that you know you are not using in your program. It's messy but would work.

  • I'm just using the standard Propeller editor tool. Based on the following comment at the BST site it sounds like the answer to my question is that the unused methods will consume RAM when you use the standard Propeller tool.

    The bst compiler has a number of optimisations built in to enhance SPIN interpretation speed (where possible), make smaller code and intelligently remove unused portions of the codebase. One of the advantages of the Propeller is the proliferation of "off-the-shelf" objects that you can simply plug and go.
    One of the downsides of simply bolting objects together is there are often parts of each object that are not used by your code. Traditionally thse are included in your resulting binary regardless. The unused code optimiser in bst looks at the code paths and leaves out methods that are never called, often resulting in significant size savings in generic objects.
  • That is right.

    BST is great for trimming away the fat. It's great for being a cross platform solution.

    Sadly it's not maintained anymore but as far as I can tell it still works perfectly well.
  • I just ran my code through BST with the "remove unused methods" optimization and my free stack size increased by a factor of 10.
  • JonnyMacJonnyMac Posts: 5,857
    edited April 15 Vote Up0Vote Down
    BST and PropellerIDE both remove unused methods. I just finished a program today that was down to 97 free longs in Propeller Tool. Recompiling in PropellerIDE increased that up to 918 longs.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • Cluso99Cluso99 Posts: 12,970
    edited April 14 Vote Up0Vote Down
    There is nothing wrong with using bst as there haven't been any bugs reported as far as I know, despite being used for years.

    I believe PropellerIDE uses PropSpin (think that's its name - written by Roy from Chip's PropTool Code). It removes unused methods, as Jon said. As this is newer, and the compiler is supported, then provided you can use PropellerIDE (platform???) this would likely be the better way to go. Otherwise, just use bst.

    When you next get to running out of hub space, there are a few other things we can help you with, such as reclaiming the hub space occupied by any pasm code that has been loaded into cog(s) and not required any more.

    FWIW heater was meaning that the spin interpreter itself is loaded into the cog, and there is no easy way to remove bits from it. It is loaded from ROM.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 12,970
    edited April 14 Vote Up0Vote Down
    Just noticed your tag line -- please don't call me "Jonny"

    Sorry, I have often called you Jonny from your handle. Shame its not possible to change your handle.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Also, check to make sure that the VAR and DAT variables you've defined are the minimum size necessary to hold the data that they need to. It's so easy to allocate a long array when a word or byte array will do.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Thanks all. I am looking at everything now to see what reductions I can do. I need to optimize my stack usage for the cogs so I will be running some stack tests.
  • I just tried the PropellerIDE tool and for some reason when I open the file with my main method, it shows nothing in the details pane under the open file. No methods, etc. When I request a memory map, it shows a map with no usage of resources. When I build via F9 it does seem to go through the project files. BST works great, no issues with it so far except a syntax error that is not a real error.
  • With bst you can get a listing too. There is also homespun and it has a listing output too.

    As for your syntax problem, why not post the offending piece of code. If your code snippet is small put it between (code) ... (/code) tags to preserve the indentation. Note replace the () with the square brackets.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Well, it's an entire file which is not really small but it's attached here.
  • For now, I just decided to comment out unused LCD graphics library methods and I regained nearly a thousand longs. That should give me all the headroom I need for the future. I'm now reaching a limit on cogs. I used 7 for my production code, and all 8 if have debug messaging turned on. In the future I want to add support for CAN bus and that will probably require at least another cog.
Sign In or Register to comment.