Thanks so much for your suggestion.

Generally speaking I have more interests in the improvement of mcs51. Besides the library's code seperation you mentioned, could you please give me a list of several major or urgent tasks related to mcs51's improvement? So I can have an overview of the current situation of mcs51 port. (The feature list of SDCC on sourcefoge is so long and can even be tracked back to ten years ago, which confuses me a lot)

You are appreciated to give me guidance.

Hash: SHA1

Am 20.12.2013 12:28, schrieb Ben Shi:
> Hi, guys,
> I am new to SDCC but have great interests in both using and
> developping it.
> The reason I asked for the AVR port is that I have interests in
> mcs51, avr and stm8. (they 3 and pic are the most popular ones in
> my country)
> If I want to do something, which one is suggested? Is it OK for me
> to pick up the AVR port, or I should pay attentions to stm8 which
> is more popular recently? Or some other works  are of higher
> priority than my familiar 3 archs above?
> Thanks for anybody to give me suggestions, since I am really want
> to make some contribution to SDCC.
> Ben

This reflects my personal opinion on what sdcc needs; other develoeprs
might disagree:

* There is a well-working avr port in gcc. No need to duplicate that
in sdcc.

* The pic ports are broken. It could be worth the effort to make the
pic16 port fully working (it has more users than the pic14 port, and
much less broken than the pic14 port).
 This is probably a task for someone who is somewhat familiar with the
pic architecture.

* For a beginner hat is a bit interested in the stm8, writing a patch
for bug #2227 seems like a good start (it is an assembler bug, so it
doesn't require knowing a lot of details of the compiler).

* The mcs51 port is the original one for sdcc, but IMO, it has fallen
a bit behind over time: The generated code hasn't improved as much as
for the other ports (which might be due to already being good enough
though). Looking at the runtime library, the mcs51 situation is a bit
of a mess: The mcs51-specific stuff is in the generic files via
#ifdef, while the other ports have their port-specific stuff nicely
separated. Fixing this is feature request #327.

* The stm8 port is quite new, the next release will be the first one
to inlude it. We'll have to see how users react, and which bug reports
and feature requests we will get. Currently it seems that there is
some potential for improvement in this port, but not more so than in
other pots.

* sdcc lacks support for some C features that any serious compiler
should have supported for quite some time now: Assignment of structs
and unions (feature request #204), Passing structs and unions as
function parameters (feature request #23), returning of structs and
unions, variable length arrays (feature request #318). Support for
long long integer constants is incomplete (bug #1996). This becomes
more and more problematic, since more and more code is written that
uses these features, and then fails to compile with sdcc.

* sdcc does not have some common machine-independent optimizations. We
don't have interval analysis at all, and pointer analysis is in bad shape.

* There are some other shortcomings that make the generated code less
efficient than it could be for all targets. See for example bug #2089
and feature request #380.

To summarize: The pic16 ad mcs51 ports need to be improved, the
support for C features badly needs to be improved, machine-independent
optimization needs to be improved.


Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove -


在2013年12月21 05时19分,"sdcc-devel-request"<>写道:

Send sdcc-devel mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of sdcc-devel digest..."