Open Source EC++ Implementation?

Dear all,

Is there any opensource EC++ implementation available? All I found was
from IARs and others. I think Mac OS X uses EC++ for their kernel mode
driver framework and they use GCC as their compiler. But I can't find
any EC++ implementation (library). Neither does GCC support EC++. Any
pointers for information?

Also, I quick question for dear veterans. Given an option option of
choosing C/C++ (EC++) for an embedded application that might run on
32-bit hundreds of MHz to 8-bit some MHz, what would you choose? You
guesed it! I am thinking of EC++. Whats your opinion?

Thanks

Warm regards
--Himanshu

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

> Dear all,
>
> Is there any opensource EC++ implementation available? All I found was
> from IARs and others. I think Mac OS X uses EC++ for their kernel mode
> driver framework and they use GCC as their compiler. But I can't find
> any EC++ implementation (library). Neither does GCC support EC++. Any
> pointers for information?
>
> Also, I quick question for dear veterans. Given an option option of
> choosing C/C++ (EC++) for an embedded application that might run on
> 32-bit hundreds of MHz to 8-bit some MHz, what would you choose? You
> guesed it! I am thinking of EC++. Whats your opinion?

For a long time the embedded compiler vendors were unable to catch up
with GCC. Full C++ is very complicated. So they invented "embedded
C++", which is C++ with all the difficult bits taken out.

If it has to run on an 8 bit micro at a few MHz, I personally would
use C. But C++ is also an option, for example g++ (GCC in c++ mode)
can target 8 bit AVRs and 68HC12s as well as 32 bit machines.

You can write inefficient code in any language.

-- 

John Devereux

Himanshu Chauhan wrote:
>Is there any opensource EC++ implementation available? All I found was
>from IARs and others. I think Mac OS X uses EC++ for their kernel mode
>driver framework and they use GCC as their compiler. But I can't find
>any EC++ implementation (library). Neither does GCC support EC++. Any
>pointers for information?

As far as I know, every C++ compiler supports EC++, since EC++ is a
proper subset of C++.  Use GCC, do not use templates, exceptions,
RTTI, namespaces, etc. 
You may have to create your own customized versions of the run-time
libraries if you want a "pure" EC++ subset. (For examples, even if you
do not use your own namespaces the GCC libraries will use std::)

>Also, I quick question for dear veterans. Given an option option of
>choosing C/C++ (EC++) for an embedded application that might run on
>32-bit hundreds of MHz to 8-bit some MHz, what would you choose? You
>guesed it! I am thinking of EC++. Whats your opinion?

Yes, no, maybe. Every project is different. 

Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

In article <f8f5g9$6cm$1@aioe.org>, Himanshu Chauhan 
<hs.chauhan@gmail.com> writes
>Dear all,
>
>Is there any opensource EC++ implementation available? All I found was
>from IARs and others. I think Mac OS X uses EC++ for their kernel mode
>driver framework and they use GCC as their compiler. But I can't find
>any EC++ implementation (library). Neither does GCC support EC++. Any
>pointers for information?
>
>Also, I quick question for dear veterans. Given an option option of
>choosing C/C++ (EC++) for an embedded application that might run on
>32-bit hundreds of MHz to 8-bit some MHz, what would you choose? You
>guesed it! I am thinking of EC++. Whats your opinion?

The answer is C.

To work across 8-32 bit systems you will find that C++ and EC++ will 
have restrictions on all of the 8 bit systems.

You will find that most C compilers will implement most or all of C90+ 
(ie C95)

So for maximum portability use well designed C

I know many will say C++ (or EC++) is as effective/efficent as C. Well 
this can be true in many cases BUT there are still many 8 bit 
architectures (and some 16 bit systems) that do not support EC++ let 
alone full C++

IF your targets are 32 bit with some 16 then go for EC++ (if it is 
availible for the 16 bit platforms)

As your target is 8-32 bit you should use C (carefully)


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

In article <871weslnpy.fsf@cordelia.devereux.me.uk>, John Devereux 
<jdREMOVE@THISdevereux.me.uk> writes
>Himanshu Chauhan <hs.chauhan@gmail.com> writes:
>
>> Dear all,
>>
>> Is there any opensource EC++ implementation available? All I found was
>> from IARs and others. I think Mac OS X uses EC++ for their kernel mode
>> driver framework and they use GCC as their compiler. But I can't find
>> any EC++ implementation (library). Neither does GCC support EC++. Any
>> pointers for information?
>>
>> Also, I quick question for dear veterans. Given an option option of
>> choosing C/C++ (EC++) for an embedded application that might run on
>> 32-bit hundreds of MHz to 8-bit some MHz, what would you choose? You
>> guesed it! I am thinking of EC++. Whats your opinion?
>
>For a long time the embedded compiler vendors were unable to catch up
>with GCC.

That has never been the case and GCC is at least 5 years behind 
commercial compilers. It is not bad compared to 32 bit compilers but 
looses out badly in the 8 and 16 bit areas

> Full C++ is very complicated. So they invented "embedded
>C++", which is C++ with all the difficult bits taken out.

Not exactly.

>If it has to run on an 8 bit micro at a few MHz, I personally would
>use C.

We agree.

>But C++ is also an option, for example g++ (GCC in c++ mode)
>can target 8 bit AVRs and 68HC12s as well as 32 bit machines.

C++ is available for *SOME* 8 anf 16 bit parts but not many. Given that 
GCC is a lot less efficient than most commercial compilers at 8 and 16 
bits it is a waste of time using GCC C++ for 8 bit systems

>You can write inefficient code in any language.

Very true.

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

Chris Hills wrote:
> Himanshu Chauhan <hs.chauhan@gmail.com> writes
>
... snip ...
>>
>> Also, I quick question for dear veterans. Given an option option
>> of choosing C/C++ (EC++) for an embedded application that might
>> run on 32-bit hundreds of MHz to 8-bit some MHz, what would you
>> choose? You guesed it! I am thinking of EC++. Whats your opinion?
> 
> The answer is C.  To work across 8-32 bit systems you will find
> that C++ and EC++ will have restrictions on all of the 8 bit
> systems.
> 
> You will find that most C compilers will implement most or all of
> C90+ (ie C95).  So for maximum portability use well designed C

This is accurate, and free of anti-open-source bias.  In general,
the simpler the better.  You expect to use your own code, not a
system library for everything under the sun.

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

Chris Hills wrote:
>>
>> For a long time the embedded compiler vendors were unable to catch up
>> with GCC.
> 
> That has never been the case and GCC is at least 5 years behind
> commercial compilers. It is not bad compared to 32 bit compilers but
> looses out badly in the 8 and 16 bit areas
> 
>> 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?

-- Himanshu

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.  EC++ is a funny mix.  C and C++ are NOT
the same language, 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.

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

In article <f8jhq9$qa0$1@aioe.org>, Himanshu Chauhan 
<hs.chauhan@gmail.com> writes
>Chris Hills wrote:
>>>
>>> For a long time the embedded compiler vendors were unable to catch up
>>> with GCC.
>>
>> That has never been the case and GCC is at least 5 years behind
>> commercial compilers. It is not bad compared to 32 bit compilers but
>> looses out badly in the 8 and 16 bit areas
>>
>>> 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?

Yes but for many targets no sane E/C++ compiler exists.

>EC++, as I read,
>has left out major bulky areas (RTTI, Exceptions, etc). It should then
>be same as plain C + modularity of C++.

C++ isn't modular but C is.

> Why couldn't it be a good choice
>then? Am I missing out something?

Yes. Good C compilers for  8 bit micros are well in advance of the C++ 
compilers. In many places the C++ compilers do not exist.

So to write E/C++  that is portable  from 8-32 bits you will have to use 
EC++ that is virtually C and where the C compilers are more efficient 
than the E/C++ compilers.

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

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/IOKitFundamentals/ArchitectOverview/chapter_3_section_6.html#//apple_ref/doc/uid/TP0000013-TPXREF104>
and the rest of the I/O Kit documentation.

-a