Green Hills vs. Freescale CodeWarrior for ColdFire development

In article , Dave Rahardja writes

Perhaps you should look at EC++

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

We did look at EC++, but decided that it's too restrictive. We are relying heavily on templates, namespaces, virtual base classes, etc.

-dr

Is gcc (g++) no good for you? I don't know anything about its c++ conformance. But it *might* actually be better in this respect than a commercial compiler that only targets the Coldfire. (Because all gcc's many targets share the same front-end, work done there benefits all of them).

--

John Devereux

I love g++! The thing I like about CW (and GHS) is their project management IDE, configuration management, and built-in debugger. I wouldn't mind going to g++ at all if that's what it takes.

By the way, both GHS and CW target a wide variety of processors. You just have to buy licenses to run the various back ends.

-dr

Not bad apparently though code density and optimisation etc are another matter.

:-) So how is that different to a lot of the commercial compilers?

They use the same front end across many targets. In fact many of the higher end compiler systems use the same front end.....

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

EC++ or Embedded C++ was developed for Embedded systems.

Various things were removed from C++ for safety. This is why the majority of embedded C++ compilers implement EC++ not full C++.

Perhaps you should think on *WHY* they did this. I know that some of the embedded C++ compilers use a front end that has full C++ compliance so you can assume that it was probably not because they did not want to implement full C++ . There are plenty of desktop compilers that do a full implementation.

Perhaps you should reassess how you write your software. You seem to have it back to front.

You are *planning* on developing an embedded application that will use Coldfire and C++. How do you know you will use all those features? Unless you are porting the code from somewhere else?

If you are not porting the code then you have jumped the gun by writung the code first.

I suggest you get one of the good compilers for Coldfire Either GHS or Codewarrior and write your app according to the language features they support.

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

So perhaps what you're looking for is an IDE that works well with gcc. The biggie that springs to mind is Eclipse, but there are others that might be worth looking at (I haven't tried these much - if you think you've found something ideal, let us know):

There are other linux IDEs, such as KDevelop, which which work with cross-compilers. There are also a number of good editors and gdb front-ends (such as DDD and Insight) if you don't need the integration. And of course, there is always emacs :-)

EC++ is not without its critics, and I happen to be one of them. Features removed from C++ can ADD safety to the software if used correctly, and I intend to use those features to enhance code correctness.

I don't know why you assume that I have not thought about the pros and cons of EC++ versus C++, given what I said in the post before yours. I understand the motivation behind EC++; I just don't agree with it.

Thank you for that generous critique on my software engineering approach. Rest assured that my choice of ColdFire and the full C++ language was based on specific issues that made it the most appropriate solution for our project.

And we end up back at the original question: Which of the compilers would support the largest subset of the C++ specification?

-dr

Hey now, that's interesting!

-dr

Well you always say that :)

Sure, I thought that might be the case.

The reason I mentioned it with respect to gcc. is that perhaps gcc might be *expected* to be weak on the "back-end" for a particular CPU. Especially if not one of the more popular ones, or an awkward architecture. Because it would only be of interest to that subset of users that actually develop for that target, so it might not get as much attention from the gcc developers.

Work put into the C++ front end, on the other hand, immediately and automatically benefits *all* targets. So even something like perhaps the AVR, that is probably not at all really suited for c++, might actually end up with surprisingly good c++ conformance.

The coldfire is a nice regular 32 bit von-neumann architecture, just gcc's cup of tea. So I would be optimistic here that the even the back-end would be efficient also.

--

John Devereux

I have no experience with the two compilers you mention, but if your (main?) concern is conformance with the C++ standard, I would consider Comeau C++. (C++ to C translator) It uses the Edison Design Group front end, and gets consistently good reviews with regards to standards compliance. They can provide a custom port for an existing C compiler if necessary. See

Comeau C++ with one of the IDEs mentioned elsethread would be good option for your needs.

OK, well it sounds to me like you have your answer! If you are already happy with g++ as a compiler, there are various ide's out there.

--

John Devereux

Fair enough it is not perfect.

:-) It is the "if used correctly" that is the problem.

Fair enough. However the number of people who come on here and make statements similar to your first post and then say "wot's EC++?" is far greater than those who know about it.

It was based on the comments you made. It is not uncommon in this NG to see people who write the code before choosing a compiler, hardware or in fact anything. They just start writing code.

Fair enough however you did not fill in any of the blanks so assumptions had to be made based on past experience of questions of the type you posted.

It depends... and mot just on the level of C++ that they support. email me direct.

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

This is an intriguing solution! It's additional cost, though, and I don't know if we can afford it (we have 11 developers slated for the project) IN ADDITION to the compiler licenses and debuggers that we're buying.

g++ sounds like a good option. I'm going to look at some IDEs, and also figure out which emulators the gdb ports work with.

-dr

Green Hills C++ also uses the EDG frontend.

Its standards conformance should be pretty good. At least I haven't found any language problem serious enough that I remember it. Our group uses quite many C++ features (including namespaces, templates, all sorts of class hierarchies, STL, etc.).

Stefan

For general purpose code, that's certainly true. However, gcc does not have support for automatically making use of the MAC or EMAC units, and it might not make the best possible ordering judgements for some of the newer and more heavily pipelined Coldfire cores - the backend is not (as far as I have heard) getting much development.

For the majority of code, on a v2 core, I would not believe any commercial compiler can repeatedly produce significantly smaller and faster code than gcc without being shown concrete examples.

If you hit any problems while testing gcc, the money you save on commercial licenses could go a long way towards making gcc even better.

There are many hardware debuggers that will work with gdb and the ColdFire BDM, ranging from cheap parallel port dongles (work well, but slow), up to high-end systems like Abatron (I've heard many nice things about them, but they're not the cheapest solution). A nice thing about gdb is that you can even make your own debuggers and write a gdb backend to suit.