Open Source EC++ Implementation?

It is implemented in a lot of embedded C++ compilers

If you need to run on 8 bitter then C++ is a non starter because there are very few C++ implementations for 8 bits and those that there are get out performed by the C compilers.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills
Loading thread data ...

Thanks! I would go for C. Would have been happier, had EC++ been the answer :D

--Himanshu

Reply to
Himanshu Chauhan

You never actually said *which* "8 bitters". It is feasible on some, e.g. gcc with AVR, possibly with hc12 too.

There is no inherent reason why EC++ (or C++) would be any less efficient than C, you just need to avoid inefficient constructs (in either language). For gcc the languages all share pretty much the same compiler anyway, so optimisation will be very similar. In fact I think in principle C++ can be optimised even better than C.

But there are some 8 bit chips for which EC++ is simply not available (like PICs and I imagine the basic 8051). So a statement like "I need to run on 8 bitters" may be restricting your choice unnecessarily.

--

John Devereux
Reply to
John Devereux

However good C compilers will out perform on both targets.

On Gcc possibly however up against decent compilers the GCC will loose out badly on the 8 and 16 bit areas

Not at all. If the spec is to run on 8 bit HW then the language choices change compared to running only on 32 bit systems

You choose the language that is appropriate for the project. You don't usually change the project to suite a preference for programing language.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

You mean "good" C compilers will outperform "good" EC++ ones on those targets?

I think the question was does EC++ perform worse than C.

But we don't have a spec! If the "spec" is to run on *all* 8 bit HW, then you have to use assembler. (For example some have no RAM).

--

John Devereux
Reply to
John Devereux

... snip ...

You need to learn that the gcc compilers, for 8, 16, 32, 64 bit etc., are all the same. The difference lies in the code generator phase. If you don't like that, you can write your own, together with the code generator subject portion of the optimizers.

--
 
 
 Click to see the full signature
Reply to
CBFalconer

Perhaps they use gcc with the "-fno-rtti" and "-fno-exceptions" options, which will remove any overhead that support of these features might have added to code even if it does not specifically use exceptions or RTTI. As for avoiding multiple inheritance and templates, it's just a matter of not using them in your code (although properly used templates have no overhead).

Reply to
David Brown

In short, no - they are (in my experience) part of the same compiler. There may be separate front-ends for C and C++ (in particular, the plain C front-end can be made faster if it doesn't have to handle C++), but the rest of the compiler is the same.

Depending on the target and the compiler, there can be some overhead in compiling code that appears as plain C but is compiled as C++ (as well as there being a few differences in the language - C++ is not a pure superset of C). In particular, there may be overhead for the RTTI support and for exceptions - hence the use of flags like "-fno-rtti" and "-fno-exceptions" in gcc. There will also be some differences in the default libraries and startup code.

But outside of that, a typical C function will normally compile to the same code when compiled as C or C++.

Reply to
David Brown

As another data point, David's explanation is very good and matches my experience as well.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

Yes, AVR is the first choice.

I thought the same when I was thinking about EC++. But hadn't had any proof to support my thought. In this thread Mr. Michael Moran says about the use of two GCC flags:

-fno-rtti

-fno-exceptions

My idea is if I use these two flags, then the size of generated code should be less than the size that will be generated without the use of these flags. May be because, no extra exception handlers etc. will be defined by the compiler? I have never done such kind of benchmarking. But I think it should be so. Sorry for this very lame piece of code, I have used simple class declaration. The code size is same in both the cases: 8.0 K (Mobile AMD Sempron, GCC 4.0.3, libstdc++.so.6.0.7)

#include //for printf. std::cout increases the code size to

12.0 KB with and without flags.

class foo { public: void print() { printf("%s\n", "Hello"); } //When I used std::cout streams, the code size was 12.0K };

int main(int argc, char *argv[]) { foo bar;

bar.print();

return 0; }

Anything wrong with the code or my idea of smaller foot print?

--Himanshu

Reply to
Himanshu Chauhan

David Brown wrote:>

yes, but they have their own RTTI to support dynamic loading of the kext modules.

--Himanshu

Reply to
Himanshu Chauhan

No "extra exception handlers" should be introduced by any C++ compiler. But exception *propagation* can require overhead in the generated code

- a function that calls another function must be able to pass exceptions back up the chain, even if it does not use exceptions itself. The "-fno-exceptions" flag will avoid that overhead.

There will still be some issues with exceptions - standard library functions such as for "new" have exceptions. It can often be worth fiddling a bit, such as using your own minimal functions for new, delete, malloc, free, and the like (on a small embedded system, you should avoid using dynamic memory - thus there is no need for "free" to do anything, for example).

Fortunately, libstdc++ is not currently supported with avrgcc last time I looked:

formatting link

Thus you have one less problem to worry about there (assuming you use avrgcc - I don't know how things stand with something like IAR's AVR C++ compiler).

These tests are utterly useless. First off, you've used the *native* compiler, which will lead to all sorts of inaccuracies for this sort of thing. Get yourself a copy of avrgcc and try it out with the appropriate compiler, linker, and library.

Secondly, functions like printf() and classes like std::cout are almost never appropriate for a small embedded system - they are far too big and slow. As someone pointed out in this thread, it's easy to write bad code in any language - printf() in C, std::cout in C++. The code from these functions will totally swamp any effects you might see from the two compiler flags.

Reply to
David Brown

Agree. I will try it again with avr-g++.

If you are linking against an AVR library (procyone) for example, they are having their minimalistic implementation.

#---------------- Library Options ---------------- # Minimalistic printf version PRINTF_LIB_MIN = -Wl,-u,vfprintf -lprintf_min

Isn't that supposed to be proper low foot print version. Obviously while writing the application you won't think about implementing the printfs rather you would be linking to some library avrlibc or others. Wouldn't you?

--Himanshu

Reply to
Himanshu Chauhan

Never heard of it - the AVR library for gcc is called avr-libc.

In the past I have used the one in avr-libc, which works well and can be configured for several different sizes. But for most new code I now use a stripped down version originally based on public domain sources. It is integer-only, but compiles down to ~1.5k on AVR and

Reply to
John Devereux

I wouldn't normally use printf at all - for most embedded systems, it is a completely inappropriate waste of resources. Printf is effectively a run-time interpreted little language, with support for large numbers of options, and passes everything through the C library's file access functions. It is far more flexible and abstract than you normally need. For many C compilers, it is also inherently unsafe - there is no type checking for the arguments (gcc, however, can check your arguments as long as the format string is a compile-time constant). When I have a system with a screen for displaying a user interface, I have functions with names like "writeString" and "writeInt" that do exactly one thing, and do it efficiently.

There are occasions when I've found snprintf() to be useful for more flexible displays on larger systems, despite the code size and run time, and with a little macro and inline function magic, you can put together a convenient output function. But that's the exception, not the rule for small systems. And even the smallest printf() implementation is totally inappropriate for benchmarking and testing the overhead and generated code for C++ handling - you should have nothing more advanced than adding and subtracting integers in your test code, so that you can examine the resulting assembly code and do meaningful comparisons.

Reply to
David Brown

Presumably, also, you could make GCC into a CFront-like system, that would take any of a large number of languages & dialects, and convert them all into very plain ISO C99, which can then be run through the embedded-compiler-du-jour?

Which might make a lot of sense for people producing embedded compilers with high quality code generation for difficult microcontrollers - they could collectively support one code-generation backend for GCC, which a customer could use to feed their products with whichever language they wanted.

Hey presto - your favourite embedded compiler now supports C, C++, EC++, F90, F77, Pascal, Ada, and probably a few others...

cheers, Rich.

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
 Click to see the full signature
Reply to
Rich Walker

Which is largely irrelevant

Of what? It is a subset of C++

What about c/c++? :-)

I agree.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.