Shop OBEX P1 Docs P2 Docs Learn Events
Overflowing hub memory--suspect Prune feature in SimpleIDE isn't working as expected — Parallax Forums

Overflowing hub memory--suspect Prune feature in SimpleIDE isn't working as expected

I've poked through my code and tested things for a couple of hours with not much progress. I've been iterating on a program for some time (unfortunately, I can't post it here as it's for work), and the last revision used about 21k. Most of the code remains the same, but I did overhaul some parts, which only change how some of the function calls are being used, but there's no new libraries or anything like that.

The project uses several files and include guarded headers for each (both *.c and *.h files are in the project), and with All Warnings enabled and c99 in use, there's only a couple unused variable warnings.

I've already done a sanity check for possible memory allocation issues or oversized variables, but there don't seem to be any.

As a sanity check, to see if it's just me making a mistake somewhere, or something else, I had the main method do just one thing: call a function in a source file (the biggest file, that handles all the other files and uses them, partly so I can keep my main source file tidy) that returns an integer.
int ripPrune() {
    return -5;
 }

My main() method looks something like this right now:
int main() {
  printf("%d",ripPrune()); }

Even with just this, it overflows main memory by several KB. Turning prune off sees a ~400 byte increase. There aren't any other function calls, and if you account for all the static variables (only declared in headers, and only in cases where the variable use seems to mandate it) there's still only ~50 bytes between them. This is with -Os turned on, naturally, and using CMM Main RAM Compact. (It's for a custom board, so SD cards or XMM-type memory are out of the question).

I looked at the SimpleIDE manual, but it seems to predate the Prune feature being added. Really not sure how to explain this code behavior, especially the behavior of Prune. Any ideas?

Comments

  • Most of the libaries in SimpleIDE have been separated out so that it only includes that one function you are calling and if you don't call the other pieces of the library they are left out.

    Most of the time the floating point and print functions eat most of the memory.

    Have you tried compiling with FlexProp. I found that the code generated by this compiler is smaller.

    Mike
  • z80jon wrote: »
    My main() method looks something like this right now:
    int main() {
      printf("%d",ripPrune()); }
    

    Even with just this, it overflows main memory by several KB. Turning prune off sees a ~400 byte increase. There aren't any other function calls, and if you account for all the static variables (only declared in headers, and only in cases where the variable use seems to mandate it) there's still only ~50 bytes between them. This is with -Os turned on, naturally, and using CMM Main RAM Compact. (It's for a custom board, so SD cards or XMM-type memory are out of the question).

    I looked at the SimpleIDE manual, but it seems to predate the Prune feature being added. Really not sure how to explain this code behavior, especially the behavior of Prune. Any ideas?

    I don't know what the prune feature do or should do, however, to remove unused functions and data there are some things to consider: the linker granularity is limited to a whole source file so unused functions are not removed if the source has at least one used function, that's why most libraries are built with one function per file. To overcome that limitation, if separating the sources is too much hassle, there are command line switches to add to the compiler: -fdata-sections -ffunction-sections, these automatically generate a new section for each function and data objects, then add the switch -Wl,--gc-sections to the linker stage that will remove all unused sections (== functions).

    Hope this helps.
  • macca wrote: »
    z80jon wrote: »
    My main() method looks something like this right now:
    int main() {
      printf("%d",ripPrune()); }
    

    Even with just this, it overflows main memory by several KB. Turning prune off sees a ~400 byte increase. There aren't any other function calls, and if you account for all the static variables (only declared in headers, and only in cases where the variable use seems to mandate it) there's still only ~50 bytes between them. This is with -Os turned on, naturally, and using CMM Main RAM Compact. (It's for a custom board, so SD cards or XMM-type memory are out of the question).

    I looked at the SimpleIDE manual, but it seems to predate the Prune feature being added. Really not sure how to explain this code behavior, especially the behavior of Prune. Any ideas?

    I don't know what the prune feature do or should do, however, to remove unused functions and data there are some things to consider: the linker granularity is limited to a whole source file so unused functions are not removed if the source has at least one used function, that's why most libraries are built with one function per file. To overcome that limitation, if separating the sources is too much hassle, there are command line switches to add to the compiler: -fdata-sections -ffunction-sections, these automatically generate a new section for each function and data objects, then add the switch -Wl,--gc-sections to the linker stage that will remove all unused sections (== functions).

    Hope this helps.

    Whoa. This is invaluable. My code has a lot of code in each source file that I don't use, as I'm basically writing libraries of sorts. Once I'm more satisfied with codes' function, I'll definitely move to that, but for testing and such this is a lifesaver!

    Despite taking a couple of classes related to C in university, we never covered compiler/linker options like those. Thank you!
  • iseries wrote: »
    Most of the libaries in SimpleIDE have been separated out so that it only includes that one function you are calling and if you don't call the other pieces of the library they are left out.

    Most of the time the floating point and print functions eat most of the memory.

    Have you tried compiling with FlexProp. I found that the code generated by this compiler is smaller.

    Mike

    Hmm... I'll try that at some point. I've already used FlexProp with the PropII, so I'm at least somewhat familiar with it. Right now, I'm quite close to hitting my head on the memory ceiling (pushing almost 31k. But I don't malloc at all and all variables are predetermined in size (by design), so I'm not too concerned about that) if I use too many of my library features at once (which, given the nature of my project, isn't necessary), but I'll definitely keep that in mind.
Sign In or Register to comment.