Open Source EC++ Implementation?

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.

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

Yes, no, maybe. Every project is different.

Roberto Waltman

In article , Himanshu Chauhan writes

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)

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

Not exactly.

We agree.

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

Very true.

... snip ...

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.

How does the Mac OS X use EC++ for their driver model. I know they use GCC.

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

... snip ...

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.

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

C++ isn't modular but C is.

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.

AFAIK they don't use EC++, but I/O Kit drivers are prohibited from using exceptions or RTTI. See

and the rest of the I/O Kit documentation.

-a

They use EC++. Please check this:

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

How they do it with GCC, I don't know!

--Himanshu

I've never seen it named in the documentation, though.

-a

I hope you'll forgive me, but will you please elaborate on this claim?

-- Michael N. Moran (h) 770 516 7918

"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

I suspect that it is done by a combination of convention and using some flags to the compiler:

-fno-exceptions

-fno-rtti

This is what I do with my embedded C++ code, though I allow templates and MI at the interface level. OTOH, I don't use STL and delete/free.

You use EC++ in your embedded code? Which processors? At least vote count reached to one. :) I have still not decided which way to go. Whats you opinion on EC++?

Could you please elaborate on the usage of GCC on the EC++ respect? I don't expect code to be optimized but should be at least equivalent to plain C. I want to use power of C and modular, not structural, pattern of C++.

--Himanshu

I have also read in some documentation but I don't know which one, so I can't quote. It was 2 years back when I was learning about I/O kit drivers.

--Himanshu

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.

Correction: I use C++ in my embedded code. I limit the C++ features that I use to those that I believe are appropriate to the embedded system that I am implementing.

Mostly PowerPC, ARM and MIPS.

EC++ is an obsolete crutch. For example, the exclusion of templates is, IMHO, an arbitrary rule. Templates (like many other features) are a tool that can be used appropriately or abused.

There is no substitute for knowing/understanding the purpose and effects of a tool, and then using the appropriate tool for the job.

What else do I need to say?

Why would you not expect optimization?

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.

This is a step in understanding your tools.

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

--Himanshu

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?

I meant I wanted to use basic OOPs features like classes and inheritance etc. with the flexibility and portability of C.

--Himanshu