|
From: <445...@qq...> - 2025-02-10 02:40:20
|
Thanks a lot. 月明风清 445...@qq... ------------------ 原始邮件 ------------------ 发件人: "Development chatter about sdcc" <pk...@sp...>; 发送时间: 2025年2月8日(星期六) 下午4:12 收件人: "sdcc-devel"<sdc...@li...>; 主题: Re: [sdcc-devel] SDCC developer meeting 2 in Bamberg in early April? Am 06.02.25 um 07:11 schrieb 月明风清 via sdcc-devel: > 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 |