I wonder why some developers choose non-free compilers (Keil, IAR, Cosmic, Raisonance, etc) when targeting architectures supported by the free Small Device C Compiler (SDCC). Answears that also mention the architecture besides the reasons would be particularly helpful.
Why use non-free compilers (Keil, etc) for architectures supported by SDCC?
Started by ●July 20, 2022
Reply by ●July 20, 20222022-07-20
Philipp Klaus Krause <pkk@spth.de> wrote:>I wonder why some developers choose non-free compilers (Keil, IAR, >Cosmic, Raisonance, etc) when targeting architectures supported by the >free Small Device C Compiler (SDCC). Answears that also mention the >architecture besides the reasons would be particularly helpful.To develop a non trivial program you not only need a compiler but also a good debugger or simulator that allows for testing any part of the microcontroller. Most free simulators are either textbased (gdb type) or support only a few parts and a subset of the controllers peripherals. A further reason for choosing a non free toolchain might be support for older designs created before SDCC was an alternative. -- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
Reply by ●July 20, 20222022-07-20
On 20/07/2022 13:49, Philipp Klaus Krause wrote:> I wonder why some developers choose non-free compilers (Keil, IAR, > Cosmic, Raisonance, etc) when targeting architectures supported by the > free Small Device C Compiler (SDCC). Answears that also mention the > architecture besides the reasons would be particularly helpful.I rarely use microcontrollers that work with SDCC, but others at the same company have. There are a few reasons, I think, that lead to SDCC not being chosen despite its obvious advantages (cost being the main one). These are not in order, and I don't know how relevant they are in the grand scheme of things. 1. Manufacturers often recommend Keil or IAR, rarely SDCC. 2. Demo code is often for Keil or IAR. With these kinds of devices, there is invariably non-standard code or extensions so code can't easily be ported between compilers. 3. Pre-written code - either within the company, or from outside - is hard to port to SDCC. You usually have to stick with the previous tools. 4. New developers get familiar with Keil or IAR from university. 5. There is a perception (I can't say if it is fair or not) that SDCC gives less efficient results than the big name compilers.
Reply by ●July 20, 20222022-07-20
David Brown wrote:> On 20/07/2022 13:49, Philipp Klaus Krause wrote: >> I wonder why some developers choose non-free compilers (Keil, IAR, >> Cosmic, Raisonance, etc) when targeting architectures supported by the >> free Small Device C Compiler (SDCC). Answears that also mention the >> architecture besides the reasons would be particularly helpful. > > I rarely use microcontrollers that work with SDCC, but others at the > same company have. There are a few reasons, I think, that lead to SDCC > not being chosen despite its obvious advantages (cost being the main > one). These are not in order, and I don't know how relevant they are in > the grand scheme of things. > > 1. Manufacturers often recommend Keil or IAR, rarely SDCC. > > 2. Demo code is often for Keil or IAR. With these kinds of devices, > there is invariably non-standard code or extensions so code can't easily > be ported between compilers. > > 3. Pre-written code - either within the company, or from outside - is > hard to port to SDCC. You usually have to stick with the previous tools. > > 4. New developers get familiar with Keil or IAR from university. > > 5. There is a perception (I can't say if it is fair or not) that SDCC > gives less efficient results than the big name compilers. > >Plus, 6. When you hit a bug, there's somebody being paid to answer your phone calls. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●July 21, 20222022-07-21
On 20/07/2022 21:55, Phil Hobbs wrote:> David Brown wrote: >> On 20/07/2022 13:49, Philipp Klaus Krause wrote: >>> I wonder why some developers choose non-free compilers (Keil, IAR, >>> Cosmic, Raisonance, etc) when targeting architectures supported by >>> the free Small Device C Compiler (SDCC). Answears that also mention >>> the architecture besides the reasons would be particularly helpful. >> >> I rarely use microcontrollers that work with SDCC, but others at the >> same company have. There are a few reasons, I think, that lead to >> SDCC not being chosen despite its obvious advantages (cost being the >> main one). These are not in order, and I don't know how relevant they >> are in the grand scheme of things. >> >> 1. Manufacturers often recommend Keil or IAR, rarely SDCC. >> >> 2. Demo code is often for Keil or IAR. With these kinds of devices, >> there is invariably non-standard code or extensions so code can't >> easily be ported between compilers. >> >> 3. Pre-written code - either within the company, or from outside - is >> hard to port to SDCC. You usually have to stick with the previous tools. >> >> 4. New developers get familiar with Keil or IAR from university. >> >> 5. There is a perception (I can't say if it is fair or not) that SDCC >> gives less efficient results than the big name compilers. >> >> > > Plus, > > 6. When you hit a bug, there's somebody being paid to answer your phone > calls. >My experience with big commercial toolchains is that this does not always help - often the support people have very little technical experience or knowledge. Maybe I just don't ask stupid enough questions. But I have heard (reliably) of toolchain support departments where the people dedicated to helping with dongles and software license locking problems outnumber the technical toolchain support staff by a factor of 3. Of course there are exceptions - some big name toolchains have excellent support staff. My experience with open source toolchains is that you don't have a number to call, but you can find good help fast from forums, mailing lists, etc. And you can quickly get in contact with people involved in the development of the toolchains, not just a support monkey that won't listen to your question until you have installed all the Windows service packs and rebooted your PC. I don't know about SDCC, but for gcc there are several ways to get commercial support - including from companies heavily involved in the development of the toolchains. Since you are paying for the support, not the software, it always has to be good quality. But none of that contradicts the fact that "there is someone on the phone to help and/or yell at" being a significant reason for people to choose big name commercial toolchains over free and open source solutions.
Reply by ●July 21, 20222022-07-21
On 2022-07-21, David Brown <david.brown@hesbynett.no> wrote:>> 6. When you hit a bug, there's somebody being paid to answer your >> phone calls.As pointed out below, "ansering your phone call" and "fixing your problem" are two very different things. I don't care about the former. I do care about the latter.> My experience with big commercial toolchains is that this does not > always help - often the support people have very little technical > experience or knowledge. [...] > > My experience with open source toolchains is that you don't have a > number to call, but you can find good help fast from forums, mailing > lists, etc. [...]Same here. Over the decades, my experiences with getting questions answered and bugs fixed have been far, far better with open-source tools than with commercial tools. However, that won't stop the anti-open-source people from using "there's no tech support phone number" as a reason to ignore open source tools.> But none of that contradicts the fact that "there is someone on the > phone to help and/or yell at" being a significant reason for people > to choose big name commercial toolchains over free and open source > solutions.It is indeed a popular reason. It's just not a good reason. -- Grant
Reply by ●July 21, 20222022-07-21
Grant Edwards wrote:> On 2022-07-21, David Brown <david.brown@hesbynett.no> wrote: > >>> 6. When you hit a bug, there's somebody being paid to answer your >>> phone calls. > > As pointed out below, "ansering your phone call" and "fixing your > problem" are two very different things. I don't care about the > former. I do care about the latter. > >> My experience with big commercial toolchains is that this does not >> always help - often the support people have very little technical >> experience or knowledge. [...] >> >> My experience with open source toolchains is that you don't have a >> number to call, but you can find good help fast from forums, mailing >> lists, etc. [...] > > Same here. Over the decades, my experiences with getting questions > answered and bugs fixed have been far, far better with open-source > tools than with commercial tools. However, that won't stop the > anti-open-source people from using "there's no tech support phone > number" as a reason to ignore open source tools. > >> But none of that contradicts the fact that "there is someone on the >> phone to help and/or yell at" being a significant reason for people >> to choose big name commercial toolchains over free and open source >> solutions. > > It is indeed a popular reason. It's just not a good reason. > > -- > Grant >My experience is different, though it wasn't with Keil et al. For instance, one time long ago, I found a fairly horrible linker bug in Microchip C17--it was loading segments misaligned by one byte IIRC. I sent in a support email at lunchtime, and the debugged linker executable was in my email the following morning. Of course I've had the same sort of thing happen with open source, e.g. the late lamented ZeroBugs debugger for Linux, written by the estimable Christian Vlasceanu. Nice piece of code, that, but he ran out of gas and/or money and got a day job. A pity--it was very nearly as good as the Visualage C++ 3.08 debugger (of song and story). I expect that the distinction is mainly the size of the teams and the user bases. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●July 21, 20222022-07-21
David Brown <david.brown@hesbynett.no> writes:> 5. There is a perception (I can't say if it is fair or not) that SDCC > gives less efficient results than the big name compilers.I haven't used Keil or IAR, but comparing GCC to SDCC, it seems to me that SDCC is a more primitive compiler. There's a bunch of features absent and the error diagnostics were often unhelpful. I've used SDCC twice. Once was starting a small project from scratch, which wasn't too bad. I just dealt with issues as they arose. The other was attempting to port a midsized project (around 5K SLOC) from GCC to SDCC. It became clear pretty quickly that getting an SDCC version working at all would be considerable effort and the resulting binary probably wouldn't fit on the target cpus I was thinking of. I'm not at all trying to bag on SDCC since it is obviously useful, but I can understand why people sometimes look for more featureful compilers. Finally, although both programs mentioned were written in C, GCC can also compile C++, which has some attractions. I don't know if IAR or Keil compile C++. I also remember thinking that it would be interesting to write embedded applications in Ada, and GCC compiles that too. Right now I think there are no non-GCC compilers for Ada-2012 or later.
Reply by ●July 21, 20222022-07-21
On 2022-07-21 21:10, Paul Rubin wrote:> > Finally, although both programs mentioned were written in C, GCC can > also compile C++, which has some attractions. I don't know if IAR or > Keil compile C++.Both Keil and IAR support both C and C++, according to their webpages. But perhaps you have to pay separately for a C compiler and for a C++ compiler, and probably separately per target architecture, too.> I also remember thinking that it would be interesting > to write embedded applications in Ada, and GCC compiles that too. Right > now I think there are no non-GCC compilers for Ada-2012 or later.There are some: The GNAT Ada compiler from AdaCore, which initially used the GCC back-end, will have a variant based on the LLVM back-end. Currently this is still experimental, I believe. This compiler is the most up to date in terms of language features. ObjectAda from PTC is an Ada 2012 compiler, but I believe it supports only x86 and x86_64 platforms, so not comparable to SDCC. Janus/Ada from RR Software "supports the complete syntax and selected features of" Ada 2012. However, it lacks a few Ada 95 features, and is currently only available on and for x86 Windows. In the past, it supported also embedded targets such as the Z80. There may be others; I have not made a thorough survey.
Reply by ●July 21, 20222022-07-21
On 21/07/2022 20:10, Paul Rubin wrote:> David Brown <david.brown@hesbynett.no> writes: >> 5. There is a perception (I can't say if it is fair or not) that SDCC >> gives less efficient results than the big name compilers. > > I haven't used Keil or IAR, but comparing GCC to SDCC, it seems to me > that SDCC is a more primitive compiler. There's a bunch of features > absent and the error diagnostics were often unhelpful. I've used SDCC > twice. Once was starting a small project from scratch, which wasn't too > bad. I just dealt with issues as they arose. The other was attempting > to port a midsized project (around 5K SLOC) from GCC to SDCC. It became > clear pretty quickly that getting an SDCC version working at all would > be considerable effort and the resulting binary probably wouldn't fit on > the target cpus I was thinking of. > > I'm not at all trying to bag on SDCC since it is obviously useful, but I > can understand why people sometimes look for more featureful compilers. > > Finally, although both programs mentioned were written in C, GCC can > also compile C++, which has some attractions. I don't know if IAR or > Keil compile C++. I also remember thinking that it would be interesting > to write embedded applications in Ada, and GCC compiles that too. Right > now I think there are no non-GCC compilers for Ada-2012 or later.One key point here is that both IAR and Keil have toolchains targeting "big" processors, such as ARM. These are more advanced toolchains, and support C++ (I don't know what standard versions - but I'd be surprised if they were fully up-to-date). So when comparing features, SDCC features should be compared to those of Keil or IAR for the same target - and I doubt if anyone is using much C++ for the 8051 or 68HC05 processors. As for Ada, the only "big name" commercial toolchain I know of for Ada is Green Hills, and it is only for ARM, PowerPC, and perhaps a few other 32-bit devices. There is GCC Ada for the 8-bit AVR, though I believe the run-time and library are somewhat incomplete. There is no doubt that GCC is a vastly more feature-filled project than SDCC. It is a world apart in terms of the languages it supports, the standards it follows, the static error checking, the diagnostics, the optimisations, etc. But while they are both free (and open) compilers, the targets they support are very different.
