On Mon, 2020-05-11 at 17:14 +0200, Moritz Strübe wrote: > I just wanted to point out that Herbceptions do not only fix > performance > issues, but also code-size problems. While anything below 4GB of RAM > is > considered under-powered for a PC, typical deep embedded > environments > have something around 32k of program memory and 2K of ram. And even > those running Linux often have around 32MB program memory and 8MB of > RAM. Also most of these systems are very cost sensitive, so each > byte > matters. Therefore RTTI and exceptions are one of the main reasons > why > parts of the embedded community consider C++ unusable: They do some > experiments using C++ and the code size explodes. And even if you > know > what you are doing and turn interrupts and RTTI off, adding a > std::nothrow to every "new" to do decent error handling is pretty > annoying. Not mentioning the parts of the C++ library that don't > provide > exception-free error-handling. > > So yes, improving the performance is nice, but ISO C++ will still be > unusable for most computer systems: There are way more emdedded > systems > with less than 32MB program memory out there than PCs, Servers and > mobile phones together.
Very nice that Moritz finally mentioned it (; The world of deep embedded is usually forgotten by all the language committees and people who are in charge. That's why the proposal by Herb is a real surprise and I really hope it could be implemented someday. The numbers above are maybe a bit too strict. A typical ARM Cortex-M chip can have up to 2 MB of ROM and 512 kB of RAM, but I would say that usually it has around 128-256 kB of ROM and somewhere around 16-64 kB of RAM. The problem with C++ exceptions is that even in the most trivial of the programs and even if you don't explicitly use/catch/throw them, they instantly eat around 60 kB of ROM and quite a lot of RAM. With some hacking you can get down to about 20 kB of ROM (by overriding a lot of string formatting code and overriding std::terminate()), but this is still too much for a feature you actually don't use. I actually have to build my own toolchain instead of the one provided by ARM, because to really NOT use C++ exceptions, you have to recompile the whole libstdc++ with `-fno-exceptions -fno-rtti` (yes, I know they provide the "nano" libraries, but I the options they used for newlib don't suit my needs - this is "too minimized"). If you pass these two flags during compilation and linking of your own application, this disables these features only in your code. As libstdc++ is compiled with exceptions and RTTI enabled, they get pulled during link anyway, bloating the binary size with a functionality you don't use and can't use - every throw from the library ends up as std::teminate() anyway. That's why the statement by Herb that C++ exceptions are never zero- cost when not used is perfectly true. The performance is also an issue. Article I've read sometime ago mentioned that a trivial throw out of a single function takes about 7000-10000 clock cycles until it is catched, which is unacceptable for any real-time solution (normal return with error handling would take at most a few dozen). But the size issue is a blocker for deep embedded, then the performance and deterministic behaviour are only secondary issues in such environment. Regards, FCh
