All you anti-C++ guys -- just hold it in. You won't convince me and I won't convince you. I made a comment in Pozz's thread on avoiding malloc that I had tried C++ on a processor with 8k of memory and couldn't make it fit. The experiment, as I remember it, was to write a basic hollow shell, build it in C and in C++, and see that it used something like 6k more flash with C++ than with C (it may not be 6k -- it was a lot with respect to 8k, and not much with respect to 64k). It was the gnu toolchain with newlib (it's the arm-none-eabi toolchain). In theory, if you're thrifty with your C++, you shouldn't pull in any more junk than you would in C. Obviously it's different in practice. Has anyone managed to really trim this down? It's kind of immaterial anyway, because if you're doing something that will reasonably fit into 8kB of flash then you don't need all of the features of C++ that make it easier to author big programs. But I'm curious. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Trimming fat in g++ and newlib
Started by ●December 21, 2016
Reply by ●December 21, 20162016-12-21
Op 21-Dec-16 om 8:13 PM schreef Tim Wescott:> All you anti-C++ guys -- just hold it in. You won't convince me and I > won't convince you. > > I made a comment in Pozz's thread on avoiding malloc that I had tried C++ > on a processor with 8k of memory and couldn't make it fit. > > The experiment, as I remember it, was to write a basic hollow shell, > build it in C and in C++, and see that it used something like 6k more > flash with C++ than with C (it may not be 6k -- it was a lot with respect > to 8k, and not much with respect to 64k). > > It was the gnu toolchain with newlib (it's the arm-none-eabi toolchain). > > In theory, if you're thrifty with your C++, you shouldn't pull in any > more junk than you would in C. Obviously it's different in practice. > > Has anyone managed to really trim this down? It's kind of immaterial > anyway, because if you're doing something that will reasonably fit into > 8kB of flash then you don't need all of the features of C++ that make it > easier to author big programs. But I'm curious.IMO that is a nonsense argument, but that's not the point of your question. But (as a strong C++ proponent) I am very interested in the example. I have no idea what a hollow shell is, but can I find the source code of both versions somewhere? I'd be very interested to repeat the experiment. wouter "Objects? No Thanks!" van Ooijen>
Reply by ●December 21, 20162016-12-21
On Wed, 21 Dec 2016 22:44:28 +0100, Wouter van Ooijen wrote:> Op 21-Dec-16 om 8:13 PM schreef Tim Wescott: >> All you anti-C++ guys -- just hold it in. You won't convince me and I >> won't convince you. >> >> I made a comment in Pozz's thread on avoiding malloc that I had tried >> C++ >> on a processor with 8k of memory and couldn't make it fit. >> >> The experiment, as I remember it, was to write a basic hollow shell, >> build it in C and in C++, and see that it used something like 6k more >> flash with C++ than with C (it may not be 6k -- it was a lot with >> respect to 8k, and not much with respect to 64k). >> >> It was the gnu toolchain with newlib (it's the arm-none-eabi >> toolchain). >> >> In theory, if you're thrifty with your C++, you shouldn't pull in any >> more junk than you would in C. Obviously it's different in practice. >> >> Has anyone managed to really trim this down? It's kind of immaterial >> anyway, because if you're doing something that will reasonably fit into >> 8kB of flash then you don't need all of the features of C++ that make >> it easier to author big programs. But I'm curious. > > IMO that is a nonsense argument, but that's not the point of your > question. > > But (as a strong C++ proponent) I am very interested in the example. I > have no idea what a hollow shell is, but can I find the source code of > both versions somewhere? I'd be very interested to repeat the > experiment. > > wouter "Objects? No Thanks!" van Ooijen > >It doesn't exist anymore -- I wrote it as throwaway code to verify the tool chain and didn't keep it. Sorry about that. But, you should be able to come pretty close if you just write a main.c that blinks an LED, with a linker file and whatnot to make it load onto a processor and work. Then, just change the name to main.cpp and build again. Here's the compiler flags that I use: -mthumb -g -mcpu=cortex-m0 -nostdlib -ffunction-sections -fdata-sections - Wl,--gc-sections -ffast-math -I. -I.. -I../st -fno-exceptions -fno-rtti If things haven't changed, the footprint on both RAM and flash will be significantly greater when you use C++. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●December 21, 20162016-12-21
On 12/21/2016 11:13 AM, Tim Wescott wrote:> All you anti-C++ guys -- just hold it in. You won't convince me and I > won't convince you. > > I made a comment in Pozz's thread on avoiding malloc that I had tried C++ > on a processor with 8k of memory and couldn't make it fit. > > The experiment, as I remember it, was to write a basic hollow shell, > build it in C and in C++, and see that it used something like 6k more > flash with C++ than with C (it may not be 6k -- it was a lot with respect > to 8k, and not much with respect to 64k). > > It was the gnu toolchain with newlib (it's the arm-none-eabi toolchain). > > In theory, if you're thrifty with your C++, you shouldn't pull in any > more junk than you would in C. Obviously it's different in practice. > > Has anyone managed to really trim this down? It's kind of immaterial > anyway, because if you're doing something that will reasonably fit into > 8kB of flash then you don't need all of the features of C++ that make it > easier to author big programs. But I'm curious. >I can believe you'll see such a problem with gnu. I suspect gnu is a mish-mash of things we really have no control over. I call it the hidden cost of free. I ran your GPIO toggler experiment with IAR Embedded Workbench for ARM. I found very small and believable output footprint sizes when I wrote and compared output from C and C++ code. The C++ code used a class that toggles a bit, very simple. The code growth was tiny. The max footprint was 190 code bytes from C++ and 140 bytes from C. Then I used new() to instantiate my toggle class in the C++ project. The footprint rose to 740 bytes, which I believe is a plausible growth that comes with the addition of new() and not much more. The map files showed new and its subordinates included and nothing else. My conclusion is beware of gnu. JJS
Reply by ●December 22, 20162016-12-22
John Speth <johnspeth@yahoo.com> writes:> Then I used new() to instantiate my toggle class in the C++ > project. The footprint rose to 740 bytesIs that not expected? new() basically pulls in the system malloc/free machinery.
Reply by ●December 22, 20162016-12-22
Tim Wescott <seemywebsite@myfooter.really> writes:> All you anti-C++ guys -- just hold it in. You won't convince me and I > won't convince you. > > I made a comment in Pozz's thread on avoiding malloc that I had tried C++ > on a processor with 8k of memory and couldn't make it fit. > > The experiment, as I remember it, was to write a basic hollow shell, > build it in C and in C++, and see that it used something like 6k more > flash with C++ than with C (it may not be 6k -- it was a lot with respect > to 8k, and not much with respect to 64k).Have you looked at the GNU ARM Eclipse "framework"? The minimal c++ "blinky" project is 1.2k flash on an M0. Adding some c++ strings made it ~2k. This was using the "GNU ARM Embedded" toolchain (which perhaps you are already using). https://launchpad.net/gcc-arm-embedded> > It was the gnu toolchain with newlib (it's the arm-none-eabi toolchain). > > In theory, if you're thrifty with your C++, you shouldn't pull in any > more junk than you would in C. Obviously it's different in practice. > > Has anyone managed to really trim this down? It's kind of immaterial > anyway, because if you're doing something that will reasonably fit into > 8kB of flash then you don't need all of the features of C++ that make it > easier to author big programs. But I'm curious.-- John Devereux
Reply by ●December 22, 20162016-12-22
On 21/12/16 20:13, Tim Wescott wrote:> All you anti-C++ guys -- just hold it in. You won't convince me and I > won't convince you. > > I made a comment in Pozz's thread on avoiding malloc that I had tried C++ > on a processor with 8k of memory and couldn't make it fit. > > The experiment, as I remember it, was to write a basic hollow shell, > build it in C and in C++, and see that it used something like 6k more > flash with C++ than with C (it may not be 6k -- it was a lot with respect > to 8k, and not much with respect to 64k). > > It was the gnu toolchain with newlib (it's the arm-none-eabi toolchain). > > In theory, if you're thrifty with your C++, you shouldn't pull in any > more junk than you would in C. Obviously it's different in practice. > > Has anyone managed to really trim this down? It's kind of immaterial > anyway, because if you're doing something that will reasonably fit into > 8kB of flash then you don't need all of the features of C++ that make it > easier to author big programs. But I'm curious. >Have you made sure you are using newlib nano? The standard newlib is big and complete, while the newlib nano version cuts a lot of features that are rarely used in embedded systems (such as wide character support), has a much smaller malloc implementation, more limited printf, etc.
Reply by ●December 22, 20162016-12-22
Am 21.12.2016 um 20:13 schrieb Tim Wescott:> The experiment, as I remember it, was to write a basic hollow shell, > build it in C and in C++, and see that it used something like 6k more > flash with C++ than with C (it may not be 6k -- it was a lot with respect > to 8k, and not much with respect to 64k). > > It was the gnu toolchain with newlib (it's the arm-none-eabi toolchain). > > In theory, if you're thrifty with your C++, you shouldn't pull in any > more junk than you would in C. Obviously it's different in practice. > > Has anyone managed to really trim this down? It's kind of immaterial > anyway, because if you're doing something that will reasonably fit into > 8kB of flash then you don't need all of the features of C++ that make it > easier to author big programs. But I'm curious.This totally depends on what your C++ program is doing. If you're using 'new', you're indirectly using 'malloc'. If you're using destructors, you're indirectly using exception handling (unless you find all knobs required to turn it off). If you start by compiling your C code with a C++ compiler, you should receive comparable object code. Then you can start using some of C++'s easier functionality, such as classes-with-member-functions, specific casts, templates, namespaces for grouping stuff, etc. I have written device drivers and (parts of) boot loaders in C++. In the case of device drivers, I even got better code than the C version: C++ makes it easy to put all attributes of a driver into a class, giving the ability of multiple instances for free as well as more efficient object code than with global variables, and allows generic re-usable data structures ("queue of interrupt events"). Sure, this can also be done in C, but it is more cumbersome, and the drivers I had been given to start with didn't do any of that. Of course I had to avoid C++ features. In addition to destructors and 'new', I also had to avoid constructors because constructors for static objects also require runtime support which isn't available in a boot loader. That alone could be a few k of code. Stefan
Reply by ●December 22, 20162016-12-22
Op 21-Dec-16 om 11:44 PM schreef John Speth:> On 12/21/2016 11:13 AM, Tim Wescott wrote: >> All you anti-C++ guys -- just hold it in. You won't convince me and I >> won't convince you. >> >> I made a comment in Pozz's thread on avoiding malloc that I had tried C++ >> on a processor with 8k of memory and couldn't make it fit. >> >> The experiment, as I remember it, was to write a basic hollow shell, >> build it in C and in C++, and see that it used something like 6k more >> flash with C++ than with C (it may not be 6k -- it was a lot with respect >> to 8k, and not much with respect to 64k). >> >> It was the gnu toolchain with newlib (it's the arm-none-eabi toolchain). >> >> In theory, if you're thrifty with your C++, you shouldn't pull in any >> more junk than you would in C. Obviously it's different in practice. >> >> Has anyone managed to really trim this down? It's kind of immaterial >> anyway, because if you're doing something that will reasonably fit into >> 8kB of flash then you don't need all of the features of C++ that make it >> easier to author big programs. But I'm curious. >> > > I can believe you'll see such a problem with gnu. I suspect gnu is a > mish-mash of things we really have no control over. I call it the > hidden cost of free. > > I ran your GPIO toggler experiment with IAR Embedded Workbench for ARM. > I found very small and believable output footprint sizes when I wrote > and compared output from C and C++ code. The C++ code used a class that > toggles a bit, very simple. The code growth was tiny. The max > footprint was 190 code bytes from C++ and 140 bytes from C. > > Then I used new() to instantiate my toggle class in the C++ project. The > footprint rose to 740 bytes, which I believe is a plausible growth that > comes with the addition of new() and not much more. The map files > showed new and its subordinates included and nothing else. > > My conclusion is beware of gnu.Why that conclusion? If you want to use the heap, you pay a price (in code and probably also in data-overhead). But why use the heap in a small embedded system? Wouter "Objects? No Thanks!" van Ooijen
Reply by ●December 22, 20162016-12-22
Op 21-Dec-16 om 11:11 PM schreef Tim Wescott:> On Wed, 21 Dec 2016 22:44:28 +0100, Wouter van Ooijen wrote: > >> Op 21-Dec-16 om 8:13 PM schreef Tim Wescott: >>> All you anti-C++ guys -- just hold it in. You won't convince me and I >>> won't convince you. >>> >>> I made a comment in Pozz's thread on avoiding malloc that I had tried >>> C++ >>> on a processor with 8k of memory and couldn't make it fit. >>> >>> The experiment, as I remember it, was to write a basic hollow shell, >>> build it in C and in C++, and see that it used something like 6k more >>> flash with C++ than with C (it may not be 6k -- it was a lot with >>> respect to 8k, and not much with respect to 64k). >>> >>> It was the gnu toolchain with newlib (it's the arm-none-eabi >>> toolchain). >>> >>> In theory, if you're thrifty with your C++, you shouldn't pull in any >>> more junk than you would in C. Obviously it's different in practice. >>> >>> Has anyone managed to really trim this down? It's kind of immaterial >>> anyway, because if you're doing something that will reasonably fit into >>> 8kB of flash then you don't need all of the features of C++ that make >>> it easier to author big programs. But I'm curious. >> >> IMO that is a nonsense argument, but that's not the point of your >> question. >> >> But (as a strong C++ proponent) I am very interested in the example. I >> have no idea what a hollow shell is, but can I find the source code of >> both versions somewhere? I'd be very interested to repeat the >> experiment. >> >> wouter "Objects? No Thanks!" van Ooijen >> >> > > It doesn't exist anymore -- I wrote it as throwaway code to verify the > tool chain and didn't keep it. Sorry about that. > > But, you should be able to come pretty close if you just write a main.c > that blinks an LED, with a linker file and whatnot to make it load onto a > processor and work. Then, just change the name to main.cpp and build > again. > > Here's the compiler flags that I use: > > -mthumb -g -mcpu=cortex-m0 -nostdlib -ffunction-sections -fdata-sections - > Wl,--gc-sections -ffast-math -I. -I.. -I../st -fno-exceptions -fno-rtti > > If things haven't changed, the footprint on both RAM and flash will be > significantly greater when you use C++.Just as important as the compiler flags: which linker script did you use? The ARM-GCC I use (https://launchpad.net/gcc-arm-embedded) doesn't provide any. And which startup script? (For small programs the size of the vector table at ORG 0 can be lager than the code itself...) Wouter "Objects? No Thanks!" van Ooijen
