Open Source EC++ Implementation?

In article <f8l2md$gk0$1@aioe.org>, Himanshu Chauhan 
<hs.chauhan@gmail.com> writes
>Chris Hills wrote:
>> In article <GGmri.10446$ae7.3602@bignews7.bellsouth.net>, Michael N.
>> Moran <mnmoran@bellsouth.net> writes
>>> Chris Hills wrote:
>>>> C++ isn't modular but C is.
>>>
>>> I hope you'll forgive me, but will you
>>> please elaborate on this claim?
>>
>> A little facetious but C is modular and C++ OO :-)
>>
>> You can do quite good OO programming in C too though both quite the same
>> as there is no inheritance.
>>
>> It seemed the OP had the answer before asking the question.   He had
>> chosen C++ regardless of how appropriate it was and would damned well
>> make it fit.
>>
>>
>
>No, I didn't have the answer. EC++ was on my mind but I was looking for
>good arguments to deny its use. Everybody has its own arguments but I
>found that nobody actually uses the standards of EC++.

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

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



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

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

--Himanshu

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.

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

In article <87ps29ras4.fsf@cordelia.devereux.me.uk>, John Devereux 
<jdREMOVE@THISdevereux.me.uk> writes
>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.

However good C compilers will out perform on both targets.

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

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

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

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     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills <chris@phaedsys.org> writes:

> In article <87ps29ras4.fsf@cordelia.devereux.me.uk>, John Devereux
> <jdREMOVE@THISdevereux.me.uk> writes
>>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.
>
> However good C compilers will out perform on both targets.
>

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

>>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.
>
> On Gcc possibly however up against decent compilers the GCC will loose
> out badly on the 8 and 16 bit areas

I think the question was does EC++ perform worse 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.
>
> 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

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

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

-- 

John Devereux

Chris Hills wrote:
> 
... snip ...
> 
> On Gcc possibly however up against decent compilers the GCC will
> loose out badly on the 8 and 16 bit areas

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.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

Himanshu Chauhan wrote:
> ammonton@cc.full.stop.helsinki.fi wrote:
>> Himanshu Chauhan <hs.chauhan@gmail.com> wrote:
>>
>>> How does the Mac OS X use EC++ for their driver model. I know they use GCC.
>> AFAIK they don't use EC++, but I/O Kit drivers are prohibited from using
>> exceptions or RTTI. See
>> <http://developer.apple.com/documentation/devicedrivers/Conceptual/IOKitFu........./doc/uid/TP0000013-TPXREF104>
>> and the rest of the I/O Kit documentation.
>>
>> -a
> 
> They use EC++.  Please check this:
> 
> http://www.kernelthread.com/mac/osx/arch_xnu.html
> 
> <excerpt>
> I/O Kit, the object-oriented device driver framework of the XNU kernel
> is radically different from that on traditional systems.
> 
> I/O Kit uses a restricted subset of C++ (based on Embedded C++) as its
> programming language. This system is implemented by the libkern library.
> Features of C++ that are not allowed in this subset include:
> 
>     * exceptions
>     * multiple inheritance
>     * templates
>     * RTTI (run-time type information), although I/O Kit has its own
> run-time typing system
> </excerpt>
> 
> How they do it with GCC, I don't know!
> 
> --Himanshu

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

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

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

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