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
Why use non-free compilers (Keil, etc) for architectures supported by SDCC?
Started by ●July 20, 2022
Reply by ●July 22, 20222022-07-22
Reply by ●July 22, 20222022-07-22
On 07/20/22 12: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 generally dislike proprietary tools, but back in the day, say for 8051 series, the architecture was so dire that it was hard work to program anything other than trivial projects in assembler. Any vendor that could deliver a reasonably functional C complier and ice adapter was on to a winner. Also, for 8051 series, the Keil toolchain had support for code banking, an essential for the limited address space. Just had to hold nose at the code produced, never look at it, but it did at least work. Later 8051 series from Silicon Labs and free toolchain were actually pretty good, but again, just don't look at the asm output. Now, we have luxury of options, ide's and debug options, but still prefer the simplicity of a Makefile environment, with gdb for the odd times where debug by module testing and inspection isn't enough... Chris
Reply by ●July 22, 20222022-07-22
Clifford Heath 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.C17 was actually their previous in-house effort, which was so buggy that they bought Hitech and then quietly killed off their own compiler. I bit the bullet and ported the code over to Hitech a few months later. The C17 series never sold well, I don't think, but you can still get the PIC17C456, twenty-odd years later. Microchip really rocks if you want product longevity. 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 ●August 25, 20222022-08-25
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 HeathWasn'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
Reply by ●August 26, 20222022-08-26
On 08/26/22 03:14, boB wrote:> 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> > >
Reply by ●August 26, 20222022-08-26
On 26/08/2022 18:17, chris wrote:> > 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 have never used Keil's 8051 compiler myself, but I did once help someone who was using it. It turned out to be a compiler issue - the compiler was not correctly handling integer promotion rules. I don't know if it was a bug as such, or an intentional non-conformance aimed at giving users more useful code generation. (After all, the integer promotion rules are often a PITA for 8-bit devices - on a device like the 8051, when 8-bit arithmetic is all you need for a calculation, using 16-bit can take 5 to 10 times as long.) I've known a number of commercial compilers for embedded systems that break the normal working of the C language in order to give more efficient results or simpler coding for users. That's not necessarily a bad thing - compilers don't have to be conforming - but it's a serious pain when it is the default behaviour and the documentation is poor. Examples of this include skipping the zeroing of implicitly initialised statically allocated data (i.e., the ".bss" segment) in the name of faster startup, and abusing "const" to mean "put this in the flash address space rather than the ram address space".
Reply by ●September 2, 20222022-09-02
On 7/20/2022 4:49 AM, 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.Inertia and "expectations" of support -- can I call someone, today, and get my problem serviced (cuz I can't sit on my hands waiting for someone to "make spare time" to address my needs). Note that embedded devices differ from desktop applications in that there are often hooks to hardware, interfaces to ASM "helpers", etc. A company may have developed a set of these from other products and wants to just "drop them in" -- without worrying about keywords, pragmas, calling/return conventions, crt0.s, etc. Finally, one often needs/wants a debugger that "knows about" the rest of the toolchain and any quirks it may have. E.g., I typically hook the "debugger console" with a DEBUG() macro in my code. So, I can see messages like: Task05: Starting with arguments '123' and 'hello bob' Task09: Waiting for memory Task02: Opening output device 'tty03' Task01: Waiting for user input Task05: Initialization complete without having to watch a "memory buffer" (and not have to reinvent these mechanisms for the next project!)
Reply by ●September 4, 20222022-09-04
On 2022-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).For 8051, Keil seems to generate better code than SDCC - I am currently doing some work on an old TI CC2511 (8051-core) chip, and tend to run into data size issues because SDCC statically allocates variables for all function parameters - Keil does have better optimizations for that (and probably also a better code generator, but I don't have much experience with keil). Also, at work, we have used IAR because TI only supplied binary libraries for the CC2541 for that compiler (we had to get the correct compiler version, the latest-and-greatest would not do). If I can choose the chip, I tend to choose something that has working gcc support if possible. cu Michael
Reply by ●September 5, 20222022-09-05
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'd estimate the total effort at a full-time position for slightly more than a year, though even less effort should allow some improvements. Philipp
Reply by ●September 5, 20222022-09-05
On 9/5/2022 8:33 AM, Philipp Klaus Krause wrote:> 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.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 (so I don't have to explore alternative ways of writing the code to avoid triggering it -- and then leaving a "FIXME" to remind myself to restore the code to its "correct" form once the compiler is fixed. When I was doing small processors (early 80's thru 90's), I developed relationships with a few vendors that let me get overnight turnaround on bug reports. In addition to the quick response, I *knew* that the changes in the tools were only oriented towards my reported bug; I didn't have to worry about some "major rewrite" that likely introduced NEW bugs, elsewhere! [I abandoned MS's tools when I reported a bug -- a pointer to a member function -- and was offered a completely new version of the compiler, "for free" (what, so I can debug THIS compiler, too??)] 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 other big win I found in tools of that era was how well the "under the hood" aspects of the code generator and support routines were documented. As I would have to modify the generated code to exist in a multitasking environment, I wanted to know where helper routines stored any static data on which they relied. Or, rewrite standard libraries to support reentrancy. Or, hook the debugger so I could see *a* task's evolving state regardless of the actions of other tasks (this isn't always trivial) [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 bugsIf "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. Good luck!
