Post by thread:[PIC] Wanted: good C++ compiler for 24H/33F

Quoting Vitaliy <spam_OUTspamTakeThisOuTmaksimov.org>: > Doesn't need to be free or even cheap. Any suggestions/comments? IAR? > I'm > especially interested to know whether there is a significant performance hit > as opposed to using plain C. Shouldn't be much different for standard C constructs, beyond that, I guess comparison isn't so easy. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" .....s...KILLspam@spam@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com

Spehro Pefhany wrote: >> Doesn't need to be free or even cheap. Any suggestions/comments? > > IAR? They are the only ones I was able to find on Google. Do you have experience w/ IAR compilers? How much does it cost, per license? >> I'm >> especially interested to know whether there is a significant performance >> hit >> as opposed to using plain C. > > Shouldn't be much different for standard C constructs, beyond that, I > guess > comparison isn't so easy. True, you have to balance human readability vs performance. Vitaliy

On May 27, 2008, at 11:46 AM, Vitaliy wrote: > I'm especially interested to know whether there is a significant > performance hit as opposed to using plain C. Well, that depends on what you do. The rhetoric here is that it can be very easy in C++ to use a construct that has a very high performance impact without it being at all obvious at the sorce level, not that the C++ compiler is inherently less efficient on simply programs... BillW

William "Chops" Westfield wrote: > Well, that depends on what you do. The rhetoric here is that it can > be very easy in C++ to use a construct that has a very high > performance impact without it being at all obvious at the sorce > level, not that the C++ compiler is inherently less efficient on > simply programs... Bill, do you have experience with C++ on PICs? It seems to me that the dsPICs and the new PIC32s have enough umph to make the tradeoff worthwhile... Vitaliy

On May 28, 2008, at 9:48 AM, Vitaliy wrote: >> he rhetoric here is that it can be very easy in C++ to use a >> construct that has a very high performance impact without it being >> at all obvious > > Bill, do you have experience with C++ on PICs? It seems to me that > the dsPICs and the new PIC32s have enough umph to make the tradeoff > worthwhile... Actually, this is the rhetoric used to try (not entirely successfully) to keep C++ code out of cisco's IOS operating system running on high-end MIPS, PPC, and 68K CPUs, and I'm generally on the "no C++" side of the argument. I was going to say that those have quite a bit more umph than even a PIC32, but I'm not so sure. (Yeah, the clock rate is probably 10 to 20x the PIC32, but there are a lot of threads SHARING that, and some of the worry is that the unnoticed impact will be especially bad in that shared environment.) On the third hand, I think I'd argue that part of what makes a program "embedded" is that it's not a good idea to have resource consumption hidden by ANY languages, OS, or whatever... (for instance, Arduino has a serial library that uses the HW uart, but it STILL takes 1ms/byte for transmit (at 9600bps) since there's no buffering on the transmit side. I've seen that bite a couple of people now.) I've almost convinced myself that I understand the value of C++ and similar languages in high-end GUI OS environments; they do a much better job of hiding data structure internals than traditional languages. I'm still not sure I understand the point of C++ in small embedded systems (although I sorta like function overloading.) BillW

I have always thought that the 'hidden overhead' argument against C++ in embedded systems was a bit specious. For example, given the two C statements: a += b; a /= b; The second has a lot more 'hidden overhead' than the first on many, many architectures. Of course, anybody writing in C for a small system knows, more or less instinctively, that division is more expensive than addition. Well, I submit that an _experienced_, _knowledgeable_, C++ programmer has a similar understanding of the overheads involved in C++ (things like virtual functions and exceptions). I have built some very large embedded systems (x86 based as it happens) in C++. These are developed/maintained by several programmers of different skill levels over a period of literally a decade, and I have never seen a 'hidden overhead' get in the way of good performance. A reductio ad absurdium argument on the 'hidden overhead' point would have us all writing in assembly (which I rather like, but...). -- Bob Ammerman RAm Systems

Robert Ammerman wrote: > I have always thought that the 'hidden overhead' argument against C++ in > embedded systems was a bit specious. > > For example, given the two C statements: > > a += b; > a /= b; > > The second has a lot more 'hidden overhead' than the first on many, many > architectures. Of course, anybody writing in C for a small system knows, > more or less instinctively, that division is more expensive than addition. > > Well, I submit that an _experienced_, _knowledgeable_, C++ programmer has a > similar understanding of the overheads involved in C++ (things like virtual > functions and exceptions). I agree. I think that the problem may be mostly that a standard-conform C++ compiler (and only such a compiler could really be called C++) has to implement many such high-overhead constructs that only a small fraction of users would use. This leads to implementing a lot of features for little (economic) gain -- which I think is the reason C++ in this area is rare. William "Chops" Westfield wrote: > I'm still not sure I understand the point of C++ in small embedded > systems (although I sorta like function overloading.) There are a number of features in C++ that don't cause run-time overhead and make programming nicer. Function overloading and (non-virtual) classes are among them. But a compiler that provides these without the rest is not a C++ compiler, and I'm not sure it's economically viable to implement all the rest for the little use some of it would have. Gerhard

> There are a number of features in C++ that don't cause run-time overhead > and make programming nicer. Function overloading and (non-virtual) classes > are among them. But a compiler that provides these without the rest is not > a C++ compiler, and I'm not sure it's economically viable to implement all > the rest for the little use some of it would have. So what's the trouble to get a full C++ compiler and use only the features you like? I teach both C and C++ programming. The C students often use the compiler in C++ mode without noticing. -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

On May 29, 2008, at 4:24 AM, Robert Ammerman wrote: > A reductio ad absurdium argument on the 'hidden overhead' point > would have us all writing in assembly (which I rather like, but...) I agree, and writing in C++ may be perfectly OK for exactly the same reasons that writing in a language other than assembler is frequently OK. > I submit that an _experienced_, _knowledgeable_, C++ programmer has > a similar understanding of the overheads involved in C++ An "experience, knowledgeable, EMBEDDED C++ programmer" perhaps. I'd claim that there are a lot of people who would claim experience and knowledge that haven't got a clue which C++ constructs are "expensive", because in their usual application environment of 2+GHz and 1GB ram, they don't have to. (These same sorts probably wouldn't do any better in C, though.) I mean, you've seen the size and inefficiency of the average windows program, right? BillW

Wouter van Ooijen wrote: >> There are a number of features in C++ that don't cause run-time overhead >> and make programming nicer. Function overloading and (non-virtual) >> classes are among them. But a compiler that provides these without the >> rest is not a C++ compiler, and I'm not sure it's economically viable >> to implement all the rest for the little use some of it would have. > > So what's the trouble to get a full C++ compiler ... The trouble is that there are not so many around. I think there is a reason for that, and I think the reason is that writing a full C++ compiler is not trivial and much effort must be expended for features that are not very relevant in the areas we're talking about. That's probably a good reason for some compiler vendors to use this effort to improve the optimization of their C compiler, for example -- which leaves us without a C++ compiler from them. > ... and use only the features you like? I wouldn't have a problem at all. But I understand why someone would think that writing a full C++ compiler for certain platforms is not worth the effort. As a compiler user, I can simply choose not to use the parts I'm not interested in. But a compiler writer can't write a C++ compiler without them... if he does, he doesn't write a C++ compiler :) Gerhard

"William "Chops" Westfield wrote: > I've almost convinced myself that I understand the value of C++ and > similar languages in high-end GUI OS environments; they do a much > better job of hiding data structure internals than traditional > languages. I'm still not sure I understand the point of C++ in small > embedded systems (although I sorta like function overloading.) IMHO, OOP is a good way to make code more human readable, and extensible. Lately I've been reading and thinking a lot about design patterns, which for the most part require OOP. Given the cost of hardware vs. software, I think it's logical to consider sacrificing a bit of performance to be able to develop software faster and maintain it cheaper. When I went from programming in Delphi back to C, I noticed that I miss objects and inheritance. :) I try to follow the advice to "program into a language", and it definitely helps, but there are some things you just can't fake well in C. BTW, I spoke to a Microchip FAE, and IAR is the only C++ compiler he's familiar with. According to him, the cost is about $3k. Vitaliy

One of the underlying principles in the original definition of C++ by Bjarne Stroustrop (sp?) was this: There should be no cost for features not used by a given program. While it is not always possible to meet this design goal, most implementations of C++ come pretty close. For example, objects with no virtual methods don't have a virtual method table. -- Bob Ammerman RAm Systems

> The trouble is that there are not so many around. True for PICs, but for nearly every other CPU there is the GCC... > I wouldn't have a problem at all. But I understand why someone would think > that writing a full C++ compiler for certain platforms is not worth the > effort. Nice thing about a compiler with a (mostly) independent back-end is that the re-targeting effort is mostly independent of the language. Holds for GCC, I guess for most commercial compilers too. -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Wouter van Ooijen wrote: > Nice thing about a compiler with a (mostly) independent back-end is that > the re-targeting effort is mostly independent of the language. Holds for > GCC, I guess for most commercial compilers too. I never wrote a compiler, but it seems to me that much of the "finer" details of optimization are quite dependent on the specific processor the code is created for. A generic implementation can provide generic optimizations at a higher level, but has probably trouble to provide optimal optimization at the lower levels. How do the gcc ports compare to other compilers in this respect? Gerhard

Gerhard Fiedler wrote: {Quote hidden}> Wouter van Ooijen wrote: > > > Nice thing about a compiler with a (mostly) independent back-end is that > > the re-targeting effort is mostly independent of the language. Holds for > > GCC, I guess for most commercial compilers too. > > I never wrote a compiler, but it seems to me that much of the "finer" > details of optimization are quite dependent on the specific processor the > code is created for. A generic implementation can provide generic > optimizations at a higher level, but has probably trouble to provide > optimal optimization at the lower levels. > > How do the gcc ports compare to other compilers in this respect? > > Gerhard The front end work of a compiler is pretty straight forward. Our compilers have a lot of generic language and general optimizations. Target specific optimizations require a deep understanding of the processor and out number generic optimizations by about 4 to 1. Despite all of the attempts to make the process more efficient it still remains very labor intensive to create a well optimized compiler. Good compilers in the process embed target restrictions and silicon workarounds into the generated code. GCC in general is based on some old compiler technology and in general lacks attention to detail that is found in many commercial compilers. In general we find that GCC is beaten by 20% or more. My biased opinion. Regards, -- Walter Banks Byte Craft Limited http://www.bytecraft.com walterKILLspambytecraft.com Canada

> How do the gcc ports compare to other compilers in this respect? That's a good question. Unfortunately I have seen only biased and/or badly done comparisons. I have suggested students to attempt a fair comparison, but so far no takers... -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

On Fri, May 30, 2008 at 9:33 PM, Walter Banks <.....walterKILLspam.....bytecraft.com> wrote: > GCC in general is based on some old compiler technology and in general > lacks attention to detail that is found in many commercial compilers. In > general we find that GCC is beaten by 20% or more. > > My biased opinion. That being said, the best dsPIC/PIC24 compiler around is now C30 which is based on gcc plus a proprietary optimizer (procedure abstraction). Maybe it is the same with PIC32 with C32 (based on gcc). It might be the best compiler for PIC32, not so sure about GreenHill. Xiaofan

On Fri, May 30, 2008 at 9:52 PM, Xiaofan Chen <EraseMExiaofancspam_OUTTakeThisOuTgmail.com> wrote: > That being said, the best dsPIC/PIC24 compiler around is now C30 which is > based on gcc plus a proprietary optimizer (procedure abstraction). > > Maybe it is the same with PIC32 with C32 (based on gcc). It might be > the best compiler for PIC32, not so sure about GreenHill. And it should not be so difficult for Microchip to add C++ support for PIC32 since MIPS has done the job already with their MIPS toolchain. And C32 is full of MIPS IP. So they must have a reason not to do so. Number 1 reason I can think of is either resource constraint or support issue. Just read this and you will know that development resource within Microchip seems to be over-stretched which is not surprising at all as I see some big US public listed companies are all very good at "lean enterprise"... http://forum.microchip.com/tm.aspx?m=337538 Xiaofan

I was wondering (been doing for a long time actually!) if anyone has seen a C++ to C converter which, though cumbersome and maybe not perfect as for code generated, could be an useful tool for a "smooth transition" to C++ even on small platforms such as PIC18. I considered writing one in the past but never had the time. -- Ciao, Dario

On Sun, Jun 1, 2008 at 9:56 PM, Dario Greggio <adpm.tospam_OUTinwind.it> wrote: > peter green wrote: > >>>I was wondering (been doing for a long time actually!) >>>if anyone has seen a C++ to C converter >> >> http://en.wikipedia.org/wiki/Cfront > > Hmmm, so, just one, and obsoleted... ! This one is alive and only costs US$50. http://www.comeaucomputing.com/ Xiaofan

Quoting Xiaofan Chen <@spam@xiaofancKILLspamgmail.com>: >>>> I was wondering (been doing for a long time actually!) >>>> if anyone has seen a C++ to C converter >>> >>> http://en.wikipedia.org/wiki/Cfront >> >> Hmmm, so, just one, and obsoleted... ! > > This one is alive and only costs US$50. > http://www.comeaucomputing.com/ What would be the primary use of such converter? I see two possibilities: 1. Convert some existing C++ code *once*, any subsequent changes are made to the resulting C code. 2. Write the program in C++, translate to C code so it would compile for the target, test, repeat. Seems rather clunky (unless the process is automated and very fast). Many OOP concepts can be implemented or "faked" in C. For example, to achieve a high degree of encapsulation: - Put related functions/data in their own modules - Name functions using the <ModuleName_FunctionName> format - Only export the "interface" functions and data (using the module's .h file) - Practice the principles of tight cohesion and loose coupling Vitaliy

spam@maksimov.org wrote: > What would be the primary use of such converter? I see two possibilities: > > 1. Convert some existing C++ code *once*, any subsequent changes are > made to the resulting C code. > > 2. Write the program in C++, translate to C code so it would compile > for the target, test, repeat. Seems rather clunky (unless the process > is automated and very fast). I "only" :) wished a C++ to C converter, that I/we could use to write some C++ code for a PIC16/18/dsPIC - translating into C first and then compiling. Just to test... and provided that one can find the reasons for a C++ program on PICs ! -- Ciao, Dario

On Sun, Jun 1, 2008 at 3:33 PM, <KILLspamspamKILLspammaksimov.org> wrote: > > Many OOP concepts can be implemented or "faked" in C. For example, to > achieve a high degree of encapsulation: > > - Put related functions/data in their own modules > - Name functions using the <ModuleName_FunctionName> format > - Only export the "interface" functions and data (using the module's .h file) > - Practice the principles of tight cohesion and loose coupling > > Vitaliy > I believe that many of the C++ features that would be useful for embedded programming can be implemented in C without much trouble. Here's an interesting perspective: http://mstation.org/erikdecl.php Regards, Mark markrages@gmail -- Mark Rages, Engineer Midwest Telecine LLC RemoveMEmarkragesTakeThisOuTmidwesttelecine.com

>> What would be the primary use of such converter? It would be a way to get a subset of C++ on a CPU that didn't have any available c++ compilers due to difficulties in parts of the compiler that you weren't really interested in anyway. Convert c++ to c, then compile with your favorite C compiler and implement only those run-time functions that you absolutely MUST have. For instance, the function overloading that I claimed to like seems to happen as a pretty trivial renaming of functions to include additional info about the argument list, so that "foo(char *, int)" becomes "foo_cp_i" and "foo(char *, double)" becomes "foo_cp_df" BillW

> I believe that many of the C++ features that would be useful for > embedded programming can be implemented in C without much trouble. > In C afaict you cannot copy structures through assignment or return them as a function result. There is also no operator overloading. This means that any custom types you make are decidedly second class citizens. In C++ I can make a fixed point type or a complex number type or a string type or a matrix type or a vector type or whatever and use it as naturally as the built in numeric types. In C I cannot do this.

John Temples wrote: > On Mon, 2 Jun 2008, peter green wrote: > > >> In C afaict you cannot copy structures through assignment or return them >> as a function result. >> > > You can do both. > Well I couldn't with the C compiler i've been working with recently (and old version of gcc), maybe this changed in a more recent C standard but it is certainly not behaviour that can be relied opon in code that is to be portable (much like the ability to declare variables anywhere in a block can't be relied on).

peter green wrote: >>> In C afaict you cannot copy structures through assignment or return them >>> as a function result. >>> >> >> You can do both. >> > Well I couldn't with the C compiler i've been working with recently (and > old version of gcc), maybe this changed in a more recent C standard but > it is certainly not behaviour that can be relied opon in code that is to > be portable (much like the ability to declare variables anywhere in a > block can't be relied on). How old is your copy of GCC? Returning structs worked for as long as I can remember. Returning a structure doesn't seem much more difficult than returning an int or a char. If a function is defined as returning a struct, it just needs to return a pointer, and the struct definition tells the compiler how many bytes there are in the struct and which fields they belong to. Vitaliy

On Tue, 3 Jun 2008, peter green wrote: >>> In C afaict you cannot copy structures through assignment or return them >>> as a function result. >> >> You can do both. >> > Well I couldn't with the C compiler i've been working with recently (and > old version of gcc), maybe this changed in a more recent C standard This feature was standardized nearly 20 years ago. Does this compiler not claim ANSI compatibility? > it is certainly not behaviour that can be relied opon in code that is to > be portable I wouldn't draw that conclusion from one very unusual compiler that might not be claiming to be a standard C compiler. > (much like the ability to declare variables anywhere in a > block can't be relied on). That was standardized "just" nine years ago, and yes, few compilers in the small embedded space have fully adopted C99 functionality. Many consider C99 features to be non-portable. -- John W. Temples, III

spam@maksimov.org wrote: >>>>> I was wondering (been doing for a long time actually!) if anyone has >>>>> seen a C++ to C converter >> >> This one is alive and only costs US$50. >> http://www.comeaucomputing.com/ > > What would be the primary use of such converter? I see two > possibilities: > > 1. Convert some existing C++ code *once*, any subsequent changes are > made to the resulting C code. > > 2. Write the program in C++, translate to C code so it would compile for > the target, test, repeat. Seems rather clunky (unless the process is > automated and very fast). I don't know about the speed, but any decent build environment can easily automate this process. It's not much different from the earlier C compilers (create assembler code, run the assembler over it to create relocatable object code, link that into a hex file or whatever representation of the binary). In the simplest case, it's just a batch file that calls two programs (the C++/C converter, then the C compiler). In a more general case, it's a simple setup for a makefile to create the result through one more step. For me, this doesn't look any different than a native C++ compiler or a normal C compiler. The one additional step is done automatically by my build environment, and once set up, I won't really think about it a lot. > Many OOP concepts can be implemented or "faked" in C. Definitely... but wasn't it you who asked for a C++ compiler? If this does what it says it does, that's your C++ compiler for any processor that has a C compiler. Gerhard

Gerhard Fiedler wrote: > If this [Comeau C++] does > what it says it does, that's your C++ compiler for any processor that has a > C compiler. They do say that it *won't* work with a given C compiler until they've ported it, and that cost "runs from $5-$50K with around $20K being average." -- Timothy J. Weber http://timothyweber.org

Timothy Weber wrote: > Gerhard Fiedler wrote: >> If this [Comeau C++] does what it says it does, that's your C++ compiler >> for any processor that has a C compiler. > > They do say that it *won't* work with a given C compiler until they've > ported it, and that cost "runs from $5-$50K with around $20K being average." Yes, I just assumed it would work with an ANSI compiler. Should have written "if it does what I think it does" :) Still probably a lot less than a custom port of a C++ compiler (like gcc). Not sure about which one would win in terms of code quality. Gerhard

Gerhard Fiedler wrote: > Timothy Weber wrote: > >> Gerhard Fiedler wrote: >>> If this [Comeau C++] does what it says it does, that's your C++ compiler >>> for any processor that has a C compiler. >> They do say that it *won't* work with a given C compiler until they've >> ported it, and that cost "runs from $5-$50K with around $20K being average." > > Yes, I just assumed it would work with an ANSI compiler. Should have > written "if it does what I think it does" :) :) And even "what you'd think it would be possible for it to do." Wasn't C supposed to be portable assembler? ANSI C at least? But there we are. > Still probably a lot less than a custom port of a C++ compiler (like gcc). > Not sure about which one would win in terms of code quality. Yes, it would be interesting to see. But I wonder if the old cfront would still be "better than plain C" for the right person and the right project. Surely it's easier to use out-of-date C++ than to implement vtables, etc. directly in C. -- Timothy J. Weber http://timothyweber.org

Timothy Weber wrote: > But I wonder if the old cfront would still be "better than plain C" for > the right person and the right project. Surely it's easier to use > out-of-date C++ than to implement vtables, etc. directly in C. Very likely. If I thought about doing something like this, I'd probably have a good look at cfront. Making it work is probably more efficient than collecting and writing a lot of library code that provides some of the functionality it probably already has. Gerhard

Gerhard Fiedler wrote: > Timothy Weber wrote: > >> But I wonder if the old cfront would still be "better than plain C" for >> the right person and the right project. Surely it's easier to use >> out-of-date C++ than to implement vtables, etc. directly in C. > > Very likely. If I thought about doing something like this, I'd probably > have a good look at cfront. Making it work is probably more efficient than > collecting and writing a lot of library code that provides some of the > functionality it probably already has. Exactly! I remember when C++ first arrived for the PC. I had independently (ignorantly) developed classes and inheritance in C, and was starting to work with virtual functions too. I jumped at the chance to let the compiler handle those things for me. -- Timothy J. Weber http://timothyweber.org

Timothy J. Weber wrote: > I remember when C++ first arrived for the PC. I had independently > (ignorantly) developed classes and inheritance in C, and was starting to > work with virtual functions too. I jumped at the chance to let the > compiler handle those things for me. Ah... before using C++ on the PC, I used TurboPascal. It took quite a while for anything else to get up to that standard :) Gerhard

Gerhard Fiedler wrote: > Ah... before using C++ on the PC, I used TurboPascal. It took quite a while > for anything else to get up to that standard :) Agreed! In retrospect, I'm not sure why I had switched to C from Turbo Pascal at that time anyway - maybe just because Dr. Dobb's liked it or because of its general popularity. Then came Turbo C++ and Borland C++ and OWL, vs. MFC, and more complex tradeoffs. -- Timothy J. Weber http://timothyweber.org

On Sat, May 31, 2008 at 1:25 AM, Dario Greggio <spamBeGoneadpm.tospamBeGoneinwind.it> wrote: > I was wondering (been doing for a long time actually!) > if anyone has seen a C++ to C converter which, though cumbersome and > maybe not perfect as for code generated, could be an useful tool for a > "smooth transition" to C++ even on small platforms such as PIC18. > > I considered writing one in the past but never had the time. I wonder if SWIG would be useful for you. It doesn't do exactly that, but the header files it would generate may be enough. http://www.swig.org Alex