Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

A rolling disk gathers no MOS.


devel / comp.arch.embedded / Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

SubjectAuthor
* Why use non-free compilers (Keil, etc) for architectures supported byPhilipp Klaus Krause
+- Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?Peter Heitzer
+* Re: Why use non-free compilers (Keil, etc) for architecturesDavid Brown
|+* Re: Why use non-free compilers (Keil, etc) for architecturesPhil Hobbs
||`* Re: Why use non-free compilers (Keil, etc) for architecturesDavid Brown
|| `* Re: Why use non-free compilers (Keil, etc) for architecturesGrant Edwards
||  `* Re: Why use non-free compilers (Keil, etc) for architecturesPhil Hobbs
||   `* Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?Clifford Heath
||    +- Re: Why use non-free compilers (Keil, etc) for architecturesPhil Hobbs
||    `* Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?boB
||     `* Re: Why use non-free compilers (Keil, etc) for architectures supportedchris
||      `- Re: Why use non-free compilers (Keil, etc) for architecturesDavid Brown
|`* Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?Paul Rubin
| +- Re: Why use non-free compilers (Keil, etc) for architecturesNiklas Holsti
| `- Re: Why use non-free compilers (Keil, etc) for architecturesDavid Brown
+- Re: Why use non-free compilers (Keil, etc) for architectures supportedchris
+- Re: Why use non-free compilers (Keil, etc) for architecturesDon Y
+- Re: Why use non-free compilers (Keil, etc) for architecturesMichael Schwingen
`* Re: Why use non-free compilers (Keil, etc) for architecturesPhilipp Klaus Krause
 `* Re: Why use non-free compilers (Keil, etc) for architecturesDon Y
  `* Re: Why use non-free compilers (Keil, etc) for architecturesPhilipp Klaus Krause
   +* Re: Why use non-free compilers (Keil, etc) for architecturesDon Y
   |`* Re: Why use non-free compilers (Keil, etc) for architecturesPhilipp Klaus Krause
   | `- Re: Why use non-free compilers (Keil, etc) for architecturesDon Y
   `* Re: Why use non-free compilers (Keil, etc) for architecturesDavid Brown
    `* Re: Why use non-free compilers (Keil, etc) for architecturesPhilipp Klaus Krause
     `- Re: Why use non-free compilers (Keil, etc) for architecturesDavid Brown

Pages:12
Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tb8q43$ftri$1@solani.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=967&group=comp.arch.embedded#967

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: pkk...@spth.de (Philipp Klaus Krause)
Newsgroups: comp.arch.embedded
Subject: Why use non-free compilers (Keil, etc) for architectures supported by
SDCC?
Date: Wed, 20 Jul 2022 13:49:23 +0200
Message-ID: <tb8q43$ftri$1@solani.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 20 Jul 2022 11:49:23 -0000 (UTC)
Injection-Info: solani.org;
logging-data="522098"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Cancel-Lock: sha1:jlxUtOseq/QkKsPId3s+3vfyH0Y=
Content-Language: en-US
X-User-ID: eJwNwoERwCAIBLCVisAD4yC++49gL3GFYMLgML+/JpsyyNhWXMcEi7bxXc7ulCwbOQXN0KE/LvkRbg==
 by: Philipp Klaus Krause - Wed, 20 Jul 2022 11:49 UTC

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.

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<jjqhfaFudt6U1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=968&group=comp.arch.embedded#968

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: peter.he...@rz.uni-regensburg.de (Peter Heitzer)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?
Date: 20 Jul 2022 14:23:38 GMT
Lines: 14
Message-ID: <jjqhfaFudt6U1@mid.individual.net>
References: <tb8q43$ftri$1@solani.org>
X-Trace: individual.net vhIb0uRWYRxxNqIDqc7uKATB9ktTKGZiNTsuz7PB3nSfYtPaCRlRA/lTsu
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:i27biwuY4NCinF2MNvS9ZOZ2mWc=
User-Agent: tin/2.4.3-20181224 ("Glen Mhor") (UNIX) (Linux/4.19.0-13-amd64 (x86_64))
 by: Peter Heitzer - Wed, 20 Jul 2022 14:23 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tb9apf$1ntab$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=969&group=comp.arch.embedded#969

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Wed, 20 Jul 2022 18:33:45 +0200
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <tb9apf$1ntab$1@dont-email.me>
References: <tb8q43$ftri$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 20 Jul 2022 16:33:51 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="983aac2ca37b76c3297d6f475c1c41db";
logging-data="1832267"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TeAy8o08uetzopXP0zqick0Xw8l4yljA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:OrboAKPp5Mvt4wYV0zRAVFLhtVg=
In-Reply-To: <tb8q43$ftri$1@solani.org>
Content-Language: en-GB
 by: David Brown - Wed, 20 Jul 2022 16:33 UTC

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.

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=970&group=comp.arch.embedded#970

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Wed, 20 Jul 2022 15:55:57 -0400
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader01.eternal-september.org; posting-host="7323a83422e34dbfc9c18d6a5bc84fb4";
logging-data="1926197"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX189MNAnBibqew+JK25FPU6Q"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
Cancel-Lock: sha1:gBTZgtOTpQdv6tj5/X1dqxdnFM0=
In-Reply-To: <tb9apf$1ntab$1@dont-email.me>
 by: Phil Hobbs - Wed, 20 Jul 2022 19:55 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tbbbgt$2alc0$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=971&group=comp.arch.embedded#971

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Thu, 21 Jul 2022 12:58:37 +0200
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <tbbbgt$2alc0$1@dont-email.me>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me>
<fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 21 Jul 2022 10:58:37 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="9f7f9c518df3a5a7dc374f15660bb5cb";
logging-data="2446720"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2l7ZkuCS8YMjT0m1dn1fXcABZHGBnlUw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:Dpqq5DMKP62aLSQ42oQ44RKfXrE=
Content-Language: en-GB
In-Reply-To: <fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net>
 by: David Brown - Thu, 21 Jul 2022 10:58 UTC

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.

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tbbpvq$rbt$2@reader2.panix.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=972&group=comp.arch.embedded#972

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!panix!.POSTED.::1!not-for-mail
From: inva...@invalid.invalid (Grant Edwards)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Thu, 21 Jul 2022 15:05:30 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <tbbpvq$rbt$2@reader2.panix.com>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me>
<fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net>
<tbbbgt$2alc0$1@dont-email.me>
Injection-Date: Thu, 21 Jul 2022 15:05:30 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="::1";
logging-data="28029"; mail-complaints-to="abuse@panix.com"
User-Agent: slrn/1.0.3 (Linux)
 by: Grant Edwards - Thu, 21 Jul 2022 15:05 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<a6c63d7e-9cbf-d6d5-c39b-639873d269dd@electrooptical.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=973&group=comp.arch.embedded#973

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Thu, 21 Jul 2022 13:18:55 -0400
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <a6c63d7e-9cbf-d6d5-c39b-639873d269dd@electrooptical.net>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me>
<fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net>
<tbbbgt$2alc0$1@dont-email.me> <tbbpvq$rbt$2@reader2.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader01.eternal-september.org; posting-host="6972dd019c9dcf99f6ee19f703e5b3d7";
logging-data="2638434"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19JmWyMFh3LxiMwpuo1U1x/"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
Cancel-Lock: sha1:bcyPu4eKENunVExlCXtSncibl0I=
In-Reply-To: <tbbpvq$rbt$2@reader2.panix.com>
 by: Phil Hobbs - Thu, 21 Jul 2022 17:18 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<874jzanxqd.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=974&group=comp.arch.embedded#974

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?
Date: Thu, 21 Jul 2022 11:10:02 -0700
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <874jzanxqd.fsf@nightsong.com>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader01.eternal-september.org; posting-host="8cd9c48abda3f17e72b004d450547021";
logging-data="2651312"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8b+rY0oa7zgC8K7cyXb/C"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:A4ijU0VNlm48JdwxAg9NxX3++eY=
sha1:xCpZtOl+ecZZUsAR4uV4HEPayn4=
 by: Paul Rubin - Thu, 21 Jul 2022 18:10 UTC

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.

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<jjtlq3FfjesU1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=975&group=comp.arch.embedded#975

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Thu, 21 Jul 2022 21:56:03 +0300
Organization: Tidorum Ltd
Lines: 33
Message-ID: <jjtlq3FfjesU1@mid.individual.net>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me>
<874jzanxqd.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net bj0y4sUbxd0phwlmJ/HOxQI9biQuUS3MaFjqjwfT3qblGY12Ds
Cancel-Lock: sha1:Gs8IcEX+Amk3+AHk2eJMBtQMZFo=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0)
Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
In-Reply-To: <874jzanxqd.fsf@nightsong.com>
 by: Niklas Holsti - Thu, 21 Jul 2022 18:56 UTC

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.

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tbc7hn$2htja$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=976&group=comp.arch.embedded#976

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Thu, 21 Jul 2022 20:56:54 +0200
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <tbc7hn$2htja$1@dont-email.me>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me>
<874jzanxqd.fsf@nightsong.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 21 Jul 2022 18:56:55 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="b28c2b8686a1686bc5a06a80032866a1";
logging-data="2684522"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18WA3Vmc8p+WO+njt6TITwBaYwQzhQeBz0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:vgb+HOSgbdNnm0ihBzbD0rtXfwo=
Content-Language: en-GB
In-Reply-To: <874jzanxqd.fsf@nightsong.com>
 by: David Brown - Thu, 21 Jul 2022 18:56 UTC

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.

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<170407881d5a7a01$1$965318$2add206e@news.thecubenet.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=977&group=comp.arch.embedded#977

 copy link   Newsgroups: comp.arch.embedded
Date: Fri, 22 Jul 2022 13:00:41 +1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1
Subject: Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?
Content-Language: en-US
Newsgroups: comp.arch.embedded
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me> <fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net> <tbbbgt$2alc0$1@dont-email.me> <tbbpvq$rbt$2@reader2.panix.com> <a6c63d7e-9cbf-d6d5-c39b-639873d269dd@electrooptical.net>
From: no_s...@please.net (Clifford Heath)
In-Reply-To: <a6c63d7e-9cbf-d6d5-c39b-639873d269dd@electrooptical.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 61
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!news.thecubenet.com!not-for-mail
NNTP-Posting-Date: Fri, 22 Jul 2022 03:00:43 +0000
Organization: theCubeNet - www.thecubenet.com
X-Complaints-To: abuse@thecubenet.com
Message-ID: <170407881d5a7a01$1$965318$2add206e@news.thecubenet.com>
X-Received-Bytes: 3793
 by: Clifford Heath - Fri, 22 Jul 2022 03:00 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tbe07b$ud2$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=978&group=comp.arch.embedded#978

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!jazQyxryRFiI4FEZ51SAvA.user.46.165.242.75.POSTED!not-for-mail
From: chris-no...@tridac.net (chris)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures supported
by SDCC?
Date: Fri, 22 Jul 2022 12:04:11 +0100
Organization: Aioe.org NNTP Server
Message-ID: <tbe07b$ud2$1@gioia.aioe.org>
References: <tb8q43$ftri$1@solani.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="31138"; posting-host="jazQyxryRFiI4FEZ51SAvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
X-Notice: Filtered by postfilter v. 0.9.2
 by: chris - Fri, 22 Jul 2022 11:04 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<d4bd4b22-6556-4c8b-5003-ac3baf942cf1@electrooptical.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=979&group=comp.arch.embedded#979

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Fri, 22 Jul 2022 09:27:40 -0400
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <d4bd4b22-6556-4c8b-5003-ac3baf942cf1@electrooptical.net>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me>
<fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net>
<tbbbgt$2alc0$1@dont-email.me> <tbbpvq$rbt$2@reader2.panix.com>
<a6c63d7e-9cbf-d6d5-c39b-639873d269dd@electrooptical.net>
<170407881d5a7a01$1$965318$2add206e@news.thecubenet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader01.eternal-september.org; posting-host="e114204ba38e04de6b7abac190037045";
logging-data="3315142"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX196yvNO0WKmvSnNMhfJ+2C6"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
Cancel-Lock: sha1:0uG387A3Ujd4Sq1f1QvKY8FphIA=
In-Reply-To: <170407881d5a7a01$1$965318$2add206e@news.thecubenet.com>
 by: Phil Hobbs - Fri, 22 Jul 2022 13:27 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<mvaggh5dqbg9o1h7s9o16aadl9624790om@4ax.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=991&group=comp.arch.embedded#991

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!novia.net!not-for-mail
From: boB...@K7IQ.com (boB)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?
Date: Thu, 25 Aug 2022 19:14:26 -0700
Message-ID: <mvaggh5dqbg9o1h7s9o16aadl9624790om@4ax.com>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me> <fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net> <tbbbgt$2alc0$1@dont-email.me> <tbbpvq$rbt$2@reader2.panix.com> <a6c63d7e-9cbf-d6d5-c39b-639873d269dd@electrooptical.net> <170407881d5a7a01$1$965318$2add206e@news.thecubenet.com>
User-Agent: ForteAgent/8.00.32.1272
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 81
NNTP-Posting-Host: c2928f63.newscene.com
X-Trace: DXC=bXI9L90@R;0fMO4cCQ>U<0;^NkA6HIcB2V[l?>g^C2\8j6RFB_=bo=7X6RTA5;^1^;2@T2RHZ;Hh;ViFLJ\LRaM8
X-Complaints-To: abuse@newscene.com
X-Received-Bytes: 4211
 by: boB - Fri, 26 Aug 2022 02:14 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tearnh$k0h$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=992&group=comp.arch.embedded#992

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!jazQyxryRFiI4FEZ51SAvA.user.46.165.242.75.POSTED!not-for-mail
From: chris-no...@tridac.net (chris)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures supported
by SDCC?
Date: Fri, 26 Aug 2022 17:17:53 +0100
Organization: Aioe.org NNTP Server
Message-ID: <tearnh$k0h$1@gioia.aioe.org>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me> <fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net> <tbbbgt$2alc0$1@dont-email.me> <tbbpvq$rbt$2@reader2.panix.com> <a6c63d7e-9cbf-d6d5-c39b-639873d269dd@electrooptical.net> <170407881d5a7a01$1$965318$2add206e@news.thecubenet.com> <mvaggh5dqbg9o1h7s9o16aadl9624790om@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="20497"; posting-host="jazQyxryRFiI4FEZ51SAvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
X-Notice: Filtered by postfilter v. 0.9.2
 by: chris - Fri, 26 Aug 2022 16:17 UTC

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

>
>
>

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<teatc4$11t7$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=993&group=comp.arch.embedded#993

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Fri, 26 Aug 2022 18:45:55 +0200
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <teatc4$11t7$1@dont-email.me>
References: <tb8q43$ftri$1@solani.org> <tb9apf$1ntab$1@dont-email.me>
<fd462ce2-918f-7a93-29e1-f0375020a53f@electrooptical.net>
<tbbbgt$2alc0$1@dont-email.me> <tbbpvq$rbt$2@reader2.panix.com>
<a6c63d7e-9cbf-d6d5-c39b-639873d269dd@electrooptical.net>
<170407881d5a7a01$1$965318$2add206e@news.thecubenet.com>
<mvaggh5dqbg9o1h7s9o16aadl9624790om@4ax.com> <tearnh$k0h$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 26 Aug 2022 16:45:56 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="4d22aacc3ecaa0ed54c54edb2a0fc935";
logging-data="34727"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18d3x1jRLeuxNzgiODojPWc6uewbOoAyhg="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:HcjlmX4sM+rFHvsrsLsnu1BouQE=
In-Reply-To: <tearnh$k0h$1@gioia.aioe.org>
Content-Language: en-GB
 by: David Brown - Fri, 26 Aug 2022 16:45 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tes7l1$2fcmk$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=997&group=comp.arch.embedded#997

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Thu, 1 Sep 2022 23:25:21 -0700
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <tes7l1$2fcmk$1@dont-email.me>
References: <tb8q43$ftri$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 2 Sep 2022 06:25:37 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="a4539979d52e910819d458636da0f380";
logging-data="2601684"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19lBZCcoqwwkKdEDZx+Ghlw"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:gsSc528GpnG9U04wCc46OBUdxQA=
In-Reply-To: <tb8q43$ftri$1@solani.org>
Content-Language: en-US
 by: Don Y - Fri, 2 Sep 2022 06:25 UTC

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!)

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<slrntha38r.t7s0.news-1513678000@a-tuin.ms.intern>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1000&group=comp.arch.embedded#1000

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!news2.arglkargh.de!news.karotte.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: news-151...@discworld.dascon.de (Michael Schwingen)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: 4 Sep 2022 20:39:55 GMT
Lines: 21
Message-ID: <slrntha38r.t7s0.news-1513678000@a-tuin.ms.intern>
References: <tb8q43$ftri$1@solani.org>
X-Trace: individual.net F2x3Ij0wAZd1GqBnpgbYGw9koyE7DCsVANXaNoHAdiwXgcuqSF
Cancel-Lock: sha1:hnIo5NKi/rlYFYiZ4TtLE5UovSA=
User-Agent: slrn/1.0.3 (Linux)
 by: Michael Schwingen - Sun, 4 Sep 2022 20:39 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tf54sg$tamn$1@solani.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1001&group=comp.arch.embedded#1001

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: pkk...@spth.de (Philipp Klaus Krause)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Mon, 5 Sep 2022 17:33:36 +0200
Message-ID: <tf54sg$tamn$1@solani.org>
References: <tb8q43$ftri$1@solani.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 5 Sep 2022 15:33:36 -0000 (UTC)
Injection-Info: solani.org;
logging-data="961239"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.2.1
Cancel-Lock: sha1:Ky67HxbPllWS+z3wQqlfCZbzQVg=
X-User-ID: eJwFwYERADEIArCVWlF0Ha88+4/wSYGXr5PFLJdbR6gc+9sb7NCuk0ch9qCNWTgk5AWYPx+wENI=
In-Reply-To: <tb8q43$ftri$1@solani.org>
Content-Language: en-US
 by: Philipp Klaus Krause - Mon, 5 Sep 2022 15:33 UTC

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tf5bsg$3ktct$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1002&group=comp.arch.embedded#1002

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Mon, 5 Sep 2022 10:32:56 -0700
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <tf5bsg$3ktct$1@dont-email.me>
References: <tb8q43$ftri$1@solani.org> <tf54sg$tamn$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 5 Sep 2022 17:33:05 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="f86a9c9aedbdbc511ed316011684bfb9";
logging-data="3831197"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19M+WSbpfLe+Wiwpgp+GM0a"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:Tsd2COd0bunOtv9AsZ9oYpu6dec=
In-Reply-To: <tf54sg$tamn$1@solani.org>
Content-Language: en-US
 by: Don Y - Mon, 5 Sep 2022 17:32 UTC

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

Good luck!

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tf6sfs$t06u$1@solani.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1003&group=comp.arch.embedded#1003

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: pkk...@spth.de (Philipp Klaus Krause)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Tue, 6 Sep 2022 09:22:36 +0200
Message-ID: <tf6sfs$t06u$1@solani.org>
References: <tb8q43$ftri$1@solani.org> <tf54sg$tamn$1@solani.org>
<tf5bsg$3ktct$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 6 Sep 2022 07:22:36 -0000 (UTC)
Injection-Info: solani.org;
logging-data="950494"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.2.1
Cancel-Lock: sha1:Fg76i9ak0ABWHpl2IqTcXrkBByY=
Content-Language: en-US
X-User-ID: eJwFwQEBACAIA7BKAueQR/D9I7hl0DgFJpFKxc567yvJQTTu+vBxOXnSrpXBZ4Te41J8KYgRYQ==
In-Reply-To: <tf5bsg$3ktct$1@dont-email.me>
 by: Philipp Klaus Krause - Tue, 6 Sep 2022 07:22 UTC

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.

> […]
>
> [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]
>

That is still true for many 8-bit devices, which are the targets of SDCC.

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

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tf725q$3sadk$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1004&group=comp.arch.embedded#1004

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Tue, 6 Sep 2022 01:59:27 -0700
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <tf725q$3sadk$1@dont-email.me>
References: <tb8q43$ftri$1@solani.org> <tf54sg$tamn$1@solani.org>
<tf5bsg$3ktct$1@dont-email.me> <tf6sfs$t06u$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 6 Sep 2022 08:59:39 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="26ca75a5ef8773f71c3ceb9114848c4e";
logging-data="4073908"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/do35hl+Oi/+A7LlgMVa22"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:EmPYd0vYYVmiuU+2R76CSK0o90g=
Content-Language: en-US
In-Reply-To: <tf6sfs$t06u$1@solani.org>
 by: Don Y - Tue, 6 Sep 2022 08:59 UTC

On 9/6/2022 12:22 AM, Philipp Klaus Krause wrote:
> 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.

Understood. I was merely relaying my experiences (e.g., abandoning MS
because of their approach to bug fixes). Most of my "smaller" projects
have had large codebases (it wasn't uncommon to have a 250KB binary running
on an 8b MCU; sewing various "bank switching" schemes into the toolkit
was a prerequisite)

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

Exactly. FOSS projects that thrive seem to rely on lots of eyes and hands
so the "load" isn't too great on any one individual. But, many projects
are relatively easy to contribute without requiring specific knowledge
beyond "this code fragment looks broken". E.g., I have no problem commiting
patches for drivers and many services -- but don't bother doing so with gcc
as the "admission fee" is too high.

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

My experience with tools for small processors predates "internet forums".
I would typically have had to log on (with a modem) to a vendor's "BBS"
and leave a message, there; picking up a new binary (from there) when
available and transfering it via X/Y/ZMODEM to my own host.

One typically didn't see other correspondence from other customers.
Nor do I imagine they saw my bug reports or the vendors' announcements
of new binaries built in response to those (unless the vendor deliberately
reached out to them).

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

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.

Other "small CPU" vendors often offer their own toolchains thus removing the
burden of that expense (free competing with free).

OTOH, the '51 (et al.) is a pretty ubiquitous architecture offered by
a variety of vendors. And, at relatively high levels of integration
(compared to 8b processors of days gone by)

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

Again, good luck!

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tf72ok$3sc8f$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1005&group=comp.arch.embedded#1005

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Tue, 6 Sep 2022 11:09:39 +0200
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <tf72ok$3sc8f$1@dont-email.me>
References: <tb8q43$ftri$1@solani.org> <tf54sg$tamn$1@solani.org>
<tf5bsg$3ktct$1@dont-email.me> <tf6sfs$t06u$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 6 Sep 2022 09:09:40 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="1bcf6303ae7d2de3329e1f909372e924";
logging-data="4075791"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/PXUANDUrB4gNoUC86zql+tSvIlhSb/Rc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:h+MXd9TDFrAf8+HM10u2G4jbbn0=
In-Reply-To: <tf6sfs$t06u$1@solani.org>
Content-Language: en-GB
 by: David Brown - Tue, 6 Sep 2022 09:09 UTC

On 06/09/2022 09:22, Philipp Klaus Krause wrote:
> 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).
>
<snip>
>
> 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.
>
>

One important question, which I certainly can't answer myself, is
whether this is worth the effort.

For the most part, 8-bit microcontrollers are a dying breed. The only
real exception is the AVR, which is a very different kind of processor
and well supported by gcc (and maybe clang/llvm?).

It used to be the case that whenever a chip manufacturer wanted a small
processor in their device - radio chip, complex analogue converter,
etc., - they put in an 8051. Now they put in an ARM Cortex-M device.

So these kinds of brain-dead 8-bit CISC cores are almost only for legacy
use - when a company already has so much time and money invested in
hardware or software that is tied tightly to such cores, that they
cannot easily change to something from this century. 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.

It's great that there are still people interested in improving this
venerable toolchain. But when you start talking about a person-year of
work, that's a lot of effort - it is not going to happen unless there is
a clear justification for the cost. (Maybe it is possible to make this
a student project for someone studying compiler design?)

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tf76ek$uf28$1@solani.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1006&group=comp.arch.embedded#1006

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: pkk...@spth.de (Philipp Klaus Krause)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Tue, 6 Sep 2022 12:12:36 +0200
Message-ID: <tf76ek$uf28$1@solani.org>
References: <tb8q43$ftri$1@solani.org> <tf54sg$tamn$1@solani.org>
<tf5bsg$3ktct$1@dont-email.me> <tf6sfs$t06u$1@solani.org>
<tf725q$3sadk$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 6 Sep 2022 10:12:37 -0000 (UTC)
Injection-Info: solani.org;
logging-data="998472"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.2.1
Cancel-Lock: sha1:dwIPYBIAPGwFgclXrk8uLn2g1tU=
Content-Language: en-US
X-User-ID: eJwFwQkBwDAIA0BLFJoAcjoe/xJ2B+Nh+SV4sdia0IEyfYiUa+LPXo70Vxk9mgVHiLWob58fEnEQsg==
In-Reply-To: <tf725q$3sadk$1@dont-email.me>
 by: Philipp Klaus Krause - Tue, 6 Sep 2022 10:12 UTC

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.

Philipp

Re: Why use non-free compilers (Keil, etc) for architectures supported by SDCC?

<tf7853$uf28$2@solani.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1007&group=comp.arch.embedded#1007

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: pkk...@spth.de (Philipp Klaus Krause)
Newsgroups: comp.arch.embedded
Subject: Re: Why use non-free compilers (Keil, etc) for architectures
supported by SDCC?
Date: Tue, 6 Sep 2022 12:41:39 +0200
Message-ID: <tf7853$uf28$2@solani.org>
References: <tb8q43$ftri$1@solani.org> <tf54sg$tamn$1@solani.org>
<tf5bsg$3ktct$1@dont-email.me> <tf6sfs$t06u$1@solani.org>
<tf72ok$3sc8f$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 6 Sep 2022 10:41:39 -0000 (UTC)
Injection-Info: solani.org;
logging-data="998472"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.2.1
Cancel-Lock: sha1:DeVpGL2CjrsrRjQqurtJyROPJV0=
In-Reply-To: <tf72ok$3sc8f$1@dont-email.me>
X-User-ID: eJwFwQkBACAIBLBK8kscQK5/BDcTJ59QN1eDQXo0wbKu1fTum5ZZQU9HLLj40BZu4qSt8wc7VRIf
Content-Language: en-US
 by: Philipp Klaus Krause - Tue, 6 Sep 2022 10:41 UTC

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.

Pages:12
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor