Dave Rahardja wrote:
> On Wed, 24 May 2006 10:07:34 -0400, Roberto Waltman <usenet@rwaltman.net>
> wrote:
> 
>> Dave Rahardja <ask@me.com> wrote:
>>> And we end up back at the original question: Which of the compilers would
>>> support the largest subset of the C++ specification?
>> 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 http://www.comeaucomputing.com/custom.html
>> Comeau C++ with one of the IDEs mentioned elsethread would be good
>> option for your needs.
> 
> 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.
> 

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.

> 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

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.

John Devereux wrote:
> Chris Hills <chris@phaedsys.org> writes:
> 
>> In article <87zmh7k2y6.fsf@cordelia.devereux.me.uk>, John Devereux
>> <jdREMOVE@THISdevereux.me.uk> writes
>>> Dave Rahardja <ask@me.com> writes:
>>>
>>>> We did look at EC++, but decided that it's too restrictive. We are relying
>>>> heavily on templates, namespaces, virtual base classes, etc.
>>> Is gcc (g++) no good for you? I don't know anything about its c++
>>> conformance.
>> Not bad apparently though code density and optimisation etc are another
>> matter.
> 
> Well you always say that :)
> 
>>> 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).
>> :-)  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.....
> 
> 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.
> 

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.

Roberto Waltman wrote:
> Dave Rahardja <ask@me.com> wrote:
> 
>>And we end up back at the original question: Which of the compilers would
>>support the largest subset of the C++ specification?
> 
> 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,

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

On Wed, 24 May 2006 10:07:34 -0400, Roberto Waltman <usenet@rwaltman.net>
wrote:

>Dave Rahardja <ask@me.com> wrote:
>>And we end up back at the original question: Which of the compilers would
>>support the largest subset of the C++ specification?
>
>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 http://www.comeaucomputing.com/custom.html
>Comeau C++ with one of the IDEs mentioned elsethread would be good
>option for your needs.

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

In article <s8o872lbhb16ncvc2fso96rnln9iadv9mm@4ax.com>, Dave Rahardja
<ask@me.com> writes
>On Wed, 24 May 2006 14:27:22 +0100, Chris Hills <chris@phaedsys.org> wrote:
>
>>>>Perhaps you should look at EC++ 
>>>
>>>We did look at EC++, but decided that it's too restrictive. We are relying
>>>heavily on templates, namespaces, virtual base classes, etc.
>>
>>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.
>
>EC++ is not without its critics, and I happen to be one of them. 

Fair enough it is not perfect. 

>Features
>removed from C++ can ADD safety to the software if used correctly, and I
>intend to use those features to enhance code correctness.

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

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

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. 

>>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. 
>
>Thank you for that generous critique on my software engineering approach.

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. 

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

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.

>>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. 
>
>And we end up back at the original question: Which of the compilers would
>support the largest subset of the C++ specification?
>-dr

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

Dave Rahardja <ask@me.com> writes:

> On Wed, 24 May 2006 13:44:01 +0100, John Devereux
> <jdREMOVE@THISdevereux.me.uk> wrote:
>
>>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).
>
> 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.

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

Dave Rahardja <ask@me.com> wrote:
>And we end up back at the original question: Which of the compilers would
>support the largest subset of the C++ specification?

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 http://www.comeaucomputing.com/custom.html
Comeau C++ with one of the IDEs mentioned elsethread would be good
option for your needs.

Chris Hills <chris@phaedsys.org> writes:

> In article <87zmh7k2y6.fsf@cordelia.devereux.me.uk>, John Devereux
> <jdREMOVE@THISdevereux.me.uk> writes
>>Dave Rahardja <ask@me.com> writes:
>>
>>>
>>> We did look at EC++, but decided that it's too restrictive. We are relying
>>> heavily on templates, namespaces, virtual base classes, etc.
>>
>>Is gcc (g++) no good for you? I don't know anything about its c++
>>conformance.
>
> Not bad apparently though code density and optimisation etc are another
> matter.

Well you always say that :)

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

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

On 24 May 2006 15:40:57 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:

>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):
>
>https://libre2.adacore.com/gps/
>www.jedit.org
>http://bvrde.sourceforge.net/index.htm
>
>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 :-)

Hey now, that's interesting!

-dr

On Wed, 24 May 2006 14:27:22 +0100, Chris Hills <chris@phaedsys.org> wrote:

>>>Perhaps you should look at EC++ 
>>
>>We did look at EC++, but decided that it's too restrictive. We are relying
>>heavily on templates, namespaces, virtual base classes, etc.
>
>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.

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.


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

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.


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

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

-dr