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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

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.

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

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

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

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

David Brown wrote:
> Himanshu Chauhan wrote:
>> By optimized code I meant the code that would be produced by a C
>> compiler rather than C++ compiler. Wouldn't there be any difference
>> between the two?
>>
> 
> 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++.

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
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1

Himanshu Chauhan wrote:
> Michael N. Moran wrote:
>> Himanshu Chauhan wrote:
> 
>>> Could you please elaborate on the usage of GCC on the
>>> EC++ respect?
>> What else do I need to say?
>>
>>> I don't expect code to be optimized but should be at
>>> least equivalent to plain C.
>> Why would you not expect optimization?
>>
> 
> By optimized code I meant the code that would be produced by a C
> compiler rather than C++ compiler. Wouldn't there be any difference
> between the two?
> 

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

>>> I want to use power of C and modular, not structural,
>>> pattern of C++.
>> I honestly don't understand what you are asking.
>> Probably your best teacher here would be to code
>> an equivalent application in each language using
>> the features that you require and study the
>> resulting output of the toolchain.
>>
> 
> I meant I wanted to use basic OOPs features like classes and inheritance
> etc. with the flexibility and portability of C.
> 
> --Himanshu