I wonder why some developers choose non-free compilers (Keil, IAR,To develop a non trivial program you not only need a compiler but also
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 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.
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.
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.
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. [...]
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. [...]
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.
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.
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
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.
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.
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.
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.
On 22/7/22 03:18, Phil Hobbs wrote:
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.
Until Microchip bought the company, I think basically any substantive question about Hitech C went directly to the founder (whose interesting
 name I can't recall). There were based at 45 Colebard Street West
Acacia Ridge QLD 4110, next to the Archerfield airport in the south of Brisbane.
On 22/7/22 03:18, Phil Hobbs wrote:
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.
Until Microchip bought the company, I think basically any substantive >question about Hitech C went directly to the founder (whose interesting
name I can't recall). There were based at 45 Colebard Street West
Acacia Ridge QLD 4110, next to the Archerfield airport in the south of >Brisbane.
There's something about small teams that ensures high-quality responses
- if you can get a response. Perhaps the opposites are true for large teams.
Clifford Heath
On Fri, 22 Jul 2022 13:00:41 +1000, Clifford Heath
<no_spam@please.net> wrote:
On 22/7/22 03:18, Phil Hobbs wrote:
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.
Until Microchip bought the company, I think basically any substantive
question about Hitech C went directly to the founder (whose interesting
name I can't recall). There were based at 45 Colebard Street West
Acacia Ridge QLD 4110, next to the Archerfield airport in the south of
Brisbane.
There's something about small teams that ensures high-quality responses
- if you can get a response. Perhaps the opposites are true for large teams. >>
Clifford Heath
Wasn't Hitech the small company (that 1 guy?) from Australia or NZ ??
I remember around 2007 +/- year or two, when there was a big Microchip conference up here in the Seattle-Everett area, he came by my work at
the time and sitting there in our lab, made some changes to his
compiler or was helping us with some issue. This was before Hitech
was sold of course. VERY good person and I can't remember his name
either.
boB
Hitech (sp ?) here in the uk were agents for Keil compilers, including
the 8051 8 bit series. We used that for a project around 1999 and it
produced consistently working code. Something like 6 x 32 K banks and
we never found a serous compiler bug.
You would not want to look at the asm source from it though, typically
pages of impenetrable asm just for a hello world...
Chris
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 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).
Thanks for all the replies, here and elsewhere. Since by now, further ones are
arriving very slowly only, I'd like to give a quick summary.
I'll quote just one reply in full, since in just a few lines it illustrates the
main points:
"In my case the customer requested SDCC based project but it failed to compile into the small flash size. Debugging was quite difficult. Using
the Simplicity Studio and Keil Compiler pairing made the code small
enough to fit into the device and made debugging much easier."
The 3 most-cited reasons to not use SDCC were:
* Lack of efficiency of the code generated by SDCC.
* Better debug support and integration in non-free toolchains.
* Availability of paid support for non-free compilers.
In my opinion, the best way forward from here to make SDCC more competitive vs.
non-free compilers is:
0) Improve machine-independent optimizations
1) Improve machine-dependent optimizations for mcs51
2) Improve debug support and integration
3) Find and fix bugs
I've rarely worried about code *size* and only seldom worried about efficiency (execution speed).
But, I *do* get annoyed if the generated code doesn't do what it
was supposed to do! Or, does it with unexpected side-effects, etc.
To that end, the biggest win was vendor responsiveness; knowing
that reporting a bug will result in prompt attention to fix *that*
bug […]
Unfortunately (for you, supporting a product), the only way to get that
sort of responsiveness is to make "support" your full-time job. <frown>
[…]
[The devices I used were unlike current offerings in that they didn't
require
large "vendor/manufacturer libraries" to implement basic functionality
of on-chip components]
In my opinion, the best way forward from here to make SDCC more
competitive vs. non-free compilers is:
0) Improve machine-independent optimizations
1) Improve machine-dependent optimizations for mcs51
2) Improve debug support and integration
3) Find and fix bugs
If "uptake" is your goal, you might focus on just a single processor (8051 family seems a common application) and be known for how well you address *that* segment of the market -- rather than trying to bring the quality
of all code generators up simultaneously.
Am 05.09.22 um 19:32 schrieb Don Y:
I've rarely worried about code *size* and only seldom worried about
efficiency (execution speed).
But, I *do* get annoyed if the generated code doesn't do what it
was supposed to do! Or, does it with unexpected side-effects, etc.
However, the replies so far show that code size, not wrong code is the problem. IMO, that is not surprising for mcs51: The mcs51 port in SDCC
is old, bug reports come in rarely, and in recnet years, most work on
mcs51 has been bugfixes. IMO, the mcs51 port is very stable. Improving
code generation always comes with the risk of introducing bugs. Still,
if time allows, it might be worth it (and I hope that most of the new
bugs will be found before a release).
Well, I asked for reasons why people are using non-free compilers
instead of SDCC. Many of the replies were indeed for mcs51. IMO, this is because the mcs51 is a common µC where SDCC has fallen behind vs. the non-free compilers.
SDCC has other ports, that got far less replies, because the
architectures are less common (e.g. ds390) or because SDCC is already
the leading compiler for them (e.g. stm8).
0)-3) were chosen is a way that I hope will make SDCC more competitive
for mcs51, while not neglecting other ports.
Am 05.09.22 um 19:32 schrieb Don Y:
I've rarely worried about code *size* and only seldom worried about
efficiency (execution speed).
But, I *do* get annoyed if the generated code doesn't do what it
was supposed to do! Or, does it with unexpected side-effects, etc.
However, the replies so far show that code size, not wrong code is the problem.
IMO, that is not surprising for mcs51: The mcs51 port in SDCC is old, bug reports come in rarely, and in recnet years, most work on mcs51 has been bugfixes. IMO, the mcs51 port is very stable. Improving code generation always
comes with the risk of introducing bugs. Still, if time allows, it might be worth it (and I hope that most of the new bugs will be found before a release).
To that end, the biggest win was vendor responsiveness; knowing
that reporting a bug will result in prompt attention to fix *that*
bug […]
Unfortunately (for you, supporting a product), the only way to get that
sort of responsiveness is to make "support" your full-time job. <frown>
Unpaid support with fixed response times for a free compiler doesn't look like
a good full-time job to me.
IMO, in general, the SDCC support channels (ticket
trackers, mailing lists) are quite responsive; most of the time, there is a reply within hours, but sometimes it takes much longer.
In my opinion, the best way forward from here to make SDCC more competitive >>> vs. non-free compilers is:
0) Improve machine-independent optimizations
1) Improve machine-dependent optimizations for mcs51
2) Improve debug support and integration
3) Find and fix bugs
If "uptake" is your goal, you might focus on just a single processor (8051 >> family seems a common application) and be known for how well you address
*that* segment of the market -- rather than trying to bring the quality
of all code generators up simultaneously.
Well, I asked for reasons why people are using non-free compilers instead of SDCC. Many of the replies were indeed for mcs51. IMO, this is because the mcs51
is a common µC where SDCC has fallen behind vs. the non-free compilers.
SDCC has other ports, that got far less replies, because the architectures are
less common (e.g. ds390) or because SDCC is already the leading compiler for them (e.g. stm8).
0)-3) were chosen is a way that I hope will make SDCC more competitive for mcs51, while not neglecting other ports.
It could also be that many of the 8b devices are just not seeing much
market share (or have fallen out of production). How many 68xx devices
win designs nowadays? Does Zilog even make processors anymore? Etc.
One important question, which I certainly can't answer myself, is
whether this is worth the effort.
[…]How many of these
users would switch toolchains, even if SDCC were made hugely better than whatever they have now? I'd expect almost none, they'd stick to what
they have - most would not even upgrade to newer versions of the same
tools that they already use.
I would expect existing SDCC users to be more interested in upgrading,
and they would always be happy with better code generation. But I do
not imagine there are many /new/ users - either people starting working
on 8051 projects today, or moving from commercial toolchains.
Am 06.09.22 um 10:59 schrieb Don Y:
It could also be that many of the 8b devices are just not seeing much
market share (or have fallen out of production). How many 68xx devices
win designs nowadays? Does Zilog even make processors anymore? Etc.
However, there are still plenty of people compiling code for the Z80 and SM83.
But practically no one uses non-free compilers to do that.
Most use SDCC either
directly or via the z88dk fork. A few use zcc or ack. All of these are free, so
not covered by the question that started the thread.
It is mostly a retrocomputing / -gaming crowd. Since many of them are willing to try development snapshots, and report bugs, their use of SDCC helps a lot in
spotting bugs in SDCC early, so they can be fixed before a release.
Am 06.09.22 um 11:09 schrieb David Brown:
One important question, which I certainly can't answer myself, is
whether this is worth the effort.
That clearly depends on many aspects. What is the higher goal? What are
the available resources? IMO improving the free toolchain for 8-Bit
devices is worth it at this time.
[…]How many of these users would switch toolchains, even if SDCC were
made hugely better than whatever they have now? I'd expect almost
none, they'd stick to what they have - most would not even upgrade to
newer versions of the same tools that they already use.
I would expect existing SDCC users to be more interested in upgrading,
and they would always be happy with better code generation. But I do
not imagine there are many /new/ users - either people starting
working on 8051 projects today, or moving from commercial toolchains.
Indeed there is a question of putting in effort to match the needs of different user groups, such as current SDCC users targetting µC, current SDCC retrocomputing and retrogaming, current users of non-free tools, etc. Naturally, SDCC developers do have an idea about the needs and wants of current SDCC users from the mailing lists, issue trackers, etc.
On the other hand, such information was not readily available about
users that currently use a non-free compiler for architectures supported
by SDCC. Knowing how much overlap there is between what could be done
for different user groups is already useful information. In particular improving the machine-independent optimizations and debug support is something that will benefit both current and potential new users.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 78:34:12 |
| Calls: | 6,915 |
| Files: | 12,382 |
| Messages: | 5,432,880 |