Open Source EC++ Implementation?

David Brown wrote:>
> 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).

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


--Himanshu

Himanshu Chauhan wrote:
> John Devereux wrote:
>> Himanshu Chauhan <hs.chauhan@gmail.com> writes:
>>
>>> Chris Hills wrote:
>>>>> You are more
>>>>> experienced guys. So I would crap my idea of using EC++ or C++ for that
>>>>> matter because I need to run on 8-bitters.
>>>> 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.
>>>>
>>> Thanks! I would go for C. Would have been happier, had EC++ been the
>>> answer :D
>> You never actually said *which* "8 bitters". It is feasible on some,
>> e.g. gcc with AVR, possibly with hc12 too.
> 
> Yes, AVR is the first choice.
> 
>> 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.
>>
> 
> 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

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: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus

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).

> 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)
> 

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.

> #include <stdio.h> //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

>
> > 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)
>
> 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.

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

>
> 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.
>

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

Himanshu Chauhan <hs.chauhan@gmail.com> writes:

>>
>> > 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)
>>
>> 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.
>
> Agree. I will try it again with avr-g++.
>
>>
>> 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.
>>
>
> If you are linking against an AVR library (procyone) for example, they
> are having their minimalistic implementation.

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

> #---------------- 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?

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 <1k
for ARM.

It is more flexible than printf since I can pass it an output function
so it can be used with e.g. graphical output routines. So I can do

  gdiPrintf(lcd, "Hello, World!\n");

etc.

-- 

John Devereux

Himanshu Chauhan wrote:
>>> 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)
>> 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.
> 
> Agree. I will try it again with avr-g++.
> 
>> 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.
>>
> 
> 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?
> 

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.

CBFalconer <cbfalconer@yahoo.com> writes:

>
> [snip] 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.

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   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadowrobot.com/hand/overview.shtml

In article <46AD6592.83D8414D@yahoo.com>, CBFalconer 
<cbfalconer@yahoo.com> writes
>Himanshu Chauhan wrote:
>> Chris Hills wrote:
>>
>... snip ...
>>>
>>>> Full C++ is very complicated. So they invented "embedded
>>>> C++", which is C++ with all the difficult bits taken out.
>>>
>>> Not exactly.
>>
>> How does the Mac OS X use EC++ for their driver model. I know
>> they use GCC.
>>
>>>> If it has to run on an 8 bit micro at a few MHz, I personally
>>>> would use C.
>>>
>>> We agree.
>>
>> Wouldn't a sane EC++ compiler be as good as plain C? EC++, as I
>> read, has left out major bulky areas (RTTI, Exceptions, etc). It
>> should then be same as plain C + modularity of C++. Why couldn't
>> it be a good choice then? Am I missing out something?
>
>C and C++ are ISO defined.

Which is largely irrelevant

>  EC++ is a funny mix.

Of what? It is a subset of C++

> C and C++ are NOT
>the same language,

What about c/c++? :-)

> and C has many built in advantages, especially
>in the embedded world.  With C you should always know where you
>stand, as long as you don't use (or isolate) extensions.

I agree.
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/