-----BEGIN PGP SIGNED MESSAGE----- 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. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlK0V5UACgkQbtUV+xsoLpoYegCfeKSKSaD9YgdP4zt8w4wCp2cN oiQAoK9zxCwn6Rzy/5pFFW13TuQQnCDt =WNB4 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user