Shop OBEX P1 Docs P2 Docs Learn Events
Object Exceeds Runtime memory limit by x longs — Parallax Forums

Object Exceeds Runtime memory limit by x longs

JDJD Posts: 570
edited 2017-10-26 09:30 in Propeller 1
Hello All, hope all is well :cool:

I have run into a strange issue compiling with my latest project. As the program grew in size, I had to save some space so it would compile. I thought moving all the variables (offset, offset2, offset3) from the local level and use 3 global bytes would save space. It went from some 60 bytes to 3, how could it not right? Nope, something with a miss... haha

The image below is a screenshot of when I try to compile for each version of code. One doesn't use global vars and one that trys to. The one without compile with 718 longs in change, and the other using global variables does not compile. Anyone have an idea? I saw the other thread but didn't get an answer or perhaps just missed it thinking it was something else.

variable%20difference.png?dl=1

The code Im working on is private sensative so sorry I can't upload it to have others to try to compile to make sure there isn't some comma or something I missed. I believe I found a strange thing; I am oddly good at these. haha :thumb:

Thanks for the help,

JD

Comments

  • Heater.Heater. Posts: 21,230
    Clearly if you move variables from method local to object level you end up using more RAM. Locals are kept on the stack and that space is reused by all your methods. Object level variables need space assigned statically to them.

    I'm not sure if the actual generated code for the methods gets bigger if it has to access object level variables rather than locals which are on the stack.

    Without being able to see your code it's going to be tough to diagnose.

    You could build your programs with the BST compiler. That can produce a listing of all the generated code and data and in that you can see where everything is put in memory.

    Aside: I'm not sure "global" is the right term. The vars are only available to methods of the same object instance. There are no actual globals in Spin.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-10-26 10:27
    Global variables get allocated in hub RAM. Local variables exist only in the stack when a method is called, so no static allocation.

    -Phil
  • JonnyMacJonnyMac Posts: 9,104
    edited 2017-10-26 12:14
    I have two recent client programs that are too big to compile with Propeller Tool. You can use BST or Propeller IDE to compile your program. These tools have a dead code removal feature that won't compile code that doesn't run. BST also analyzes variable declarations and will point out variables that do not appear to be used.

    BTW... I have a better pixel driver than the one you're using.
    -- http://obex.parallax.com/object/868
  • JDJD Posts: 570
    Excellent, I totally get why local variables get calculated differently than global variables; I was thinking once it got compiled it was all treated the same. Thanks for all the fast responses.

    @JonnyMac - I will check out the new driver later today, im about go get some sleep. haha

  • T ChapT Chap Posts: 4,223
    Local variables are always Longs. If you define variables under VAR you will set its length and use the smallest size to suit the requirement for that variable. This can help you save some space in some cases. In BST you check the optimaize and remove unused this will make a big difference when you are run out out of RAM
  • JDJD Posts: 570
    @T Chap, thanks I was able to get it. I was thinking once it was everything was compiled a byte was treated as byte regardless of how I assigned it, but that was the question.

    I was just getting clarification before moving in a direction on making things more effecient to add more features; everything works but I knew you all would know immidately so I didn't have to look it up. :)
  • msrobotsmsrobots Posts: 3,709
    edited 2017-10-29 06:17
    @JD

    there are big differences where you define variables. Especially if you have multiples of one object in your code, say two serial driver or two TVs or two SD-cards.

    The simplest to understand are HUB variables in the DAT section. The DAT section can contain a initial value for the variables.

    There whatever you define is ONCE in the resulting program image.

    If you define a variable in the VAR section it has no predefined value. usually 0 but you can not be sure.

    A variable in the VAR section of a (sub)-object occurs per object, so with 2 serial objects they will share their CODE, share the DAT section, but each of them has its own VAR section.

    All of this is done at compile time, when the finally image is build.

    Now you have local variables, they end up on the stack, and do just exist as long as your PRI/PUB procedure/method is running. Created at the start and released at the end of your call.

    The result is that you can use the same memory area multiple times without conflict.

    TLDR

    Use as much as possible local variables and parameters, avoid global ones in VAR or DAT as long as you do not have a reason to save them there.

    Enjoy!

    Mike
  • JDJD Posts: 570
    Totally, and this is an example of a extreme compile size difference; 60 vars < 3 vars :nerd:
Sign In or Register to comment.