[sdcc-devel] 回复： SDCC developer meeting 2 in Bamberg in early April?

[<445...@qq...>]

Thanks a lot.




月明风清
445...@qq...



 




------------------ 原始邮件 ------------------
发件人:                                                                                                                        "Development chatter about sdcc"                                                                                    <pk...@sp...&gt;;
发送时间:&nbsp;2025年2月8日(星期六) 下午4:12
收件人:&nbsp;"sdcc-devel"<sdc...@li...&gt;;

主题:&nbsp;Re: [sdcc-devel] SDCC developer meeting 2 in Bamberg in early April?



Am 06.02.25 um 07:11 schrieb 月明风清 via sdcc-devel:
&gt; I have a question about SDCC that what is the unique value of SDCC。

I guess this would easier to answer if you could be a bit more specific
with your question. It depends what you compare SDCC to, and what your
use-case is. Still, I'll try to give two answers.

Comparing SDCC to non-free compilers targeting the same 8-bit
architectures (IAR, Keil, Cosmic, Raisonance, etc):

* SDCC is free
* SDCC has far better support for C standards, especially recent ones.
* SDCC supports more host systems (in particular AFAIK SDCC is the only
one that works on macOS).

For an example, see the comparison of C compilers targeting the STM8
from 2024: http://www.colecovision.eu/stm8/compilers.shtml

Comparing SDCC to free GCC and LLVM:

* SDCC is better suited for irregular architectures with a small
register set. Both wrt. named address spaces some architectures need,
and wrt. irregularity in the registers. GCC and LLVM tend to use
Chaitin-style graph-coloring register allocators, which a great if you
have many interchangeable registers, and the big difference is in a
variable being stored a register vs. it not being stored in one. The
graph-structure-theoretic grapoh-coloring register allocator used by
most ports in SDCC is much better at handling a small number of
registers that are non-interchangeable (i.e. it also matters a lot which
register a variable is stored in, not just if it is stored in one vs.
being stored in memory or rematerialized).
* The learning curve to get into SDCC development is less steep than for
GCC, so you can get a new port working quicker.
* The internal interfaces are more stable than LLVM, i.e. once you have
a working port, the maintenance effort is lower.

Philipp



_______________________________________________
sdcc-devel mailing list
sdc...@li...
https://lists.sourceforge.net/lists/listinfo/sdcc-devel