From: Maarten B. <sou...@ds...> - 2013-12-20 15:54:02
|
Hello all, In general I agree with Philipp. I think I am the most active mcs51 developer of recent times, but there is only so much I can do. However I certainly won't encourage a beginner to start messing with compiler internals. Anyone 'somewhat familiar' does not qualify IMO. Maarten > -----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 |