avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: static class member as interrupt handler works, but not if class is


From: Trampas Stern
Subject: Re: static class member as interrupt handler works, but not if class is templated
Date: Sun, 11 Apr 2021 08:20:53 -0400

"The man who grasps principles can successfully handle his own methods. The man who tries methods, ignoring principles, is sure to have trouble." -Ralph Waldo Emerson

When you understand your requirements, processor, and tools (compiler) then you can pick the best method to optimize for desired results.  Blanket statements like "Don't use C++"  or that is "Slow and lots of bloat." might be true based on how you would use the tools. 


I agree C is a great programming language, it does has problems and every year I learn new things I did not know in C. I also learned C++ and was in the camp of no embedded C++ ever.  Then I did some testing and read more, for example: 
https://www.embedded.com/modern-c-in-embedded-systems-part-1-myth-and-reality/
https://bitvolatile.com/?p=326

I found that C++ was not evil if you knew how to use it.  So I started doing some tests and found that in many cases the higher level abstraction was worth it on larger projects. Plus I learned what was free in C++ and what caused bloat and slowness. 
 
For example here is the lines of code count for one of my last embedded projects: 
-------------------------------------------------------------------------------
Language                files          blank        comment           code
-------------------------------------------------------------------------------
C/C++ Header            246          20651        33660         89579
C++                             51           3977           3362          36695
C                                 20           3545           6605          12705
DOS Batch                   1              0              0                      2
-------------------------------------------------------------------------------
SUM:                           318          28173       43627       138981
-------------------------------------------------------------------------------

The code is large enough where the abstraction that C++ provides helps us manage the project better.  This may have resulting performance and code size hits on the processor, but it is worth it for the benefits. 

Trampas

On Sat, Apr 10, 2021 at 11:40 PM Anton Staaf <anton@socialhacker.com> wrote:
For those that care, and ignoring the flame war, I believe that your (Klaus) problem likely stems from the following GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70435

Sadly, support for C++ in AVR GCC is not a priority, so I wouldn't expect it to be fixed.  I've been able to work around this myself using explicit template instantiation, because I'm relying on a slightly different attribute that isn't propgated correctly.  I'm tagging an object as living in the .vectors section, and making its memory layout match the vector table layout for AVR processors.  This lets me generate only the vectors that are required using template meta programming based on the interrupts that are listened for.  I've built my avr-gcc with "--with-avrlibc=no" and "--without-newlib" to suppress the misspelled ISR warning.

-Anton

On Sat, Apr 10, 2021 at 8:19 PM Russell Shaw <rjshaw@netspace.net.au> wrote:
On 11/4/21 8:36 am, Trampas Stern wrote:
> Actually C++ is not slower or more bloat than C, depending on the features used.
>
> For example I do not use RTTI or exceptions, so that makes it about the same as
> C for size. Yes you have to turn these features off in your compiler (-fno-rtti,
> -fno-exceptions).  Sure you have trampolines or jump tables for function
> overloading but you have to do the same in C. If you do not use inheritance or
> function overloading you do not have the penalty.

Function overloading is a compile-time concept, but the result after name scope
flattening are simple function names that are called without any extra pointer
indirections (ie, no different than C).

C++ is as efficient as C only if what is written translates to the equivalent
form. This is easy to do, but only after a large hurdle of understanding how C++
compilers work.

The biggest shortcoming in the C++ "industry" is that there is no literature i
have seen that explains in a compact way how you can look at a piece of C++ code
and see how it would translate to the equivalent assembly, which is the main
advantage of C.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]