Abnormal flash space consumption for trivial code

Post here first, or if you can't find a relevant section!
Violet Giraffe
Posts: 10
Joined: Sun Mar 19, 2017 4:22 pm

Abnormal flash space consumption for trivial code

Postby Violet Giraffe » Sun Mar 19, 2017 9:37 pm

I'm very new to STM32 Arduino so pardon me if I did something silly there, but I don't understand what's going on. When compiled for the STM32F3 Discovery board, the following code occupies 71960 bytes (66%) of program storage space. 7248 bytes of dynamic memory seems too much, too (versus 4008 for an empty .ino).

Code: Select all

class A
{
public:
  A() {}

  static A& inst()
  {
    static A a;
    return a;
  }
};


void setup() {
  A::inst(); 
}

void loop() {}


Ideas?

Note that this is the minimal example. Removing the constructor of A (using the default compiler-generated one) removes the issue. Either a constructor or destructor is required, doesn't matter which. The singleton part is also required, that's what somehow triggers the issue.

User avatar
Rick Kimball
Posts: 771
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Abnormal flash space consumption for trivial code

Postby Rick Kimball » Sun Mar 19, 2017 11:48 pm

I noticed this, but I've not tried it:

http://stackoverflow.com/questions/2298 ... pplication

<edit
I tried it, it reduces the size to 13184 bytes and 2816 bytes of dynamic

You need to modify the platform.txt and add the -fno-threadsafe-statics on the cpp.flags:
$ git diff -w platform.txt
diff --git a/STM32F1/platform.txt b/STM32F1/platform.txt
index 3ffde2e..d56f700 100644
--- a/STM32F1/platform.txt
+++ b/STM32F1/platform.txt
@@ -22,7 +22,7 @@ compiler.c.elf.flags=-Os -Wl,--gc-sections
compiler.S.cmd=arm-none-eabi-gcc
compiler.S.flags=-c -g -x assembler-with-cpp -MMD
compiler.cpp.cmd=arm-none-eabi-g++
-compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -MMD -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_{build.variant} -D{build.vect} -DERROR_LED_PORT={build.error_led_port} -DERROR_LED_PIN={build.error_led_pin}
+compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -MMD -fno-threadsafe-statics -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_{build.variant} -D{build.vect} -DERROR_LED_PORT={build.error_led_port} -DERROR_LED_PIN={build.error_led_pin}
compiler.ar.cmd=arm-none-eabi-ar
compiler.ar.flags=rcs
compiler.objcopy.cmd=arm-none-eabi-objcopy

</edit

<edit 2
There is a discussion of the issue here:
https://arobenko.gitbooks.io/bare_metal ... tatic.html
</edit 2
-rick

Violet Giraffe
Posts: 10
Joined: Sun Mar 19, 2017 4:22 pm

Re: Abnormal flash space consumption for trivial code

Postby Violet Giraffe » Mon Mar 20, 2017 6:27 am

Wow, good find, thanks a lot! Apparently, your Google kung-fu is stronger than mine. That solves the problem.

User avatar
Rick Kimball
Posts: 771
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Abnormal flash space consumption for trivial code

Postby Rick Kimball » Mon Mar 20, 2017 3:16 pm

I too like the singleton pattern. It seems useful to deal with order of initialization issues. I had also previously encountered this problem. However at that time, I didn't search around to find the right answer. I took the lazy way out and just moved to a different approach. That other solution that can be applied to this problem is to use a "placement new" and get the same result.

Code: Select all

class A {
...
static A& instance() {
   static char memory[sizeof(A)];
   static A *a;
   if ( !a ) {
      void *place = memory;
      a = new(place) A();
   }
   return *a;
}
...


This is useful if you have non-trivial constructors and they depend on some other hardware or class to be properly instanced and initialized.
-rick

Violet Giraffe
Posts: 10
Joined: Sun Mar 19, 2017 4:22 pm

Re: Abnormal flash space consumption for trivial code

Postby Violet Giraffe » Mon Mar 20, 2017 5:39 pm

Neat! I mean, the code isn't very neat compared to the proper static object, but it does solve the problem nicely. Thanks.


Return to “General discussion”

Who is online

Users browsing this forum: No registered users and 2 guests