From: Ben S. <pow...@16...> - 2013-12-21 06:00:11
|
Philipp, 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. Ben -----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----- 在2013年12月21 05时19分,"sdcc-devel-request"<sdc...@li...>写道: Send sdcc-devel mailing list submissions to sdc...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/sdcc-devel or, via email, send a message with subject or body 'help' to sdc...@li... You can reach the person managing the list at sdc...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of sdcc-devel digest..." |
From: Philipp K. K. <pk...@sp...> - 2013-12-20 14:43:45
|
-----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----- |
From: Philipp K. K. <pk...@sp...> - 2013-12-21 10:51:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.12.2013 06:59, schrieb Ben Shi: > Philipp, > > 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. > > Ben Well, I'm not an expert on the mcs51 port. Other developers are. We're planning for a sdcc 3.4.0 release, so currently we mostly want bug fixes. You're welcome to write patches for new features, but they probably would only be included after the 3.4.0 release (with each new feature might come new bugs, and we want sdcc to stabilize a bit before the release). The mcs51 lacks a few things that other ports have: * The mcs51 was the first port to have a deadMove() peephole function. Then some other ports got the more pwoerful notUsed() and notUsedFrom(). The deadMove() in mcs51 should be replaced by the more powerful notUsed() and the mcs51 should get a notUsedFrom(). This will allow additional peephole optimizations. * The mcs51 does not yet support 64-bit integers (long long). * There were some disagreements among sdcc developers about the efficiency vs. standard compliance trade-off. Maarten emphasized efficiency more, while I emphasized standard-compliance more, the other developers fell in between. This resulted in thing being done a bit differently in different ports. However, we have now mostly found solutions that allow for both efficiency and standard compliance, but they are not implemented yet: - - Some string functions: Currently we have an #ifdef that makes the mcs51 version take an unsigned char where some other ports use an int as the standard requires. This could be resolved by having both a version that takes unsigned char and one that takes int (in separate files), and a macro to select the unsigned char version for direct calls. - - The mcs51 port uses a __bit for the _Bool data type, while other ports use a stadard-compliant type. Support for a standard-compliant _Bool should be implemented for the mcs51 (and the existing __bit be kept around for those who want to save memory). The __bit only uses one bit of storage, while the _Bool uses a byte, but you can't take the address of a a __bit, and the __bit cannot be used in structs and unions (see also bug #1602). Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlK1cocACgkQbtUV+xsoLpqjjwCgwLBzB+Pq/TntYrubTdYIR6e7 EDAAoIbB6nDrEeiVFU97ipfeGiLKb0V2 =8R2z -----END PGP SIGNATURE----- |
From: Thomas S. <t.s...@al...> - 2013-12-21 12:56:55
|
On 12/21/2013 11:50 AM, Philipp Klaus Krause wrote: > The mcs51 lacks a few things that other ports have: My personal wishlist for the mcs51 port is: * compiler builtin functions like long multiply/divide use nonstandard nonreentrant calling conventions, thus silently making functions marked as __reentrant non-reentrant. The simplest fix would IMO be to push/pop the argument variables in the pro-/epilog of the function marked as __reentrant. * functions that only call __reentrant functions should be considered leaf functions for the purpose of the overlay segment. This would avoid bloating the overlay segment. * 8 registers aren't a lot, if you want to add 2 32bit variables, for example. This causes frequent spills, thus either bloating the overlay segment, or causing expensive stack operations. Using some DATA memory as additional registers would mitigate this. * Debug information is very basic at the moment. I don't know of a reliable way to get at the values of non-static variables (i.e. auto or overlay). Furthermore, call-graph information (like statement x can continue at statement y, z or return from the function) would make source-level single stepping possible. Stack unwind info would make backtrace information available. Thomas |
From: Maarten B. <sou...@ds...> - 2013-12-22 15:11:27
|
Hi all, > On 12/21/2013 11:50 AM, Philipp Klaus Krause wrote: > >> The mcs51 lacks a few things that other ports have: > > My personal wishlist for the mcs51 port is: > > * compiler builtin functions like long multiply/divide use nonstandard > nonreentrant calling conventions, thus silently making functions marked > as __reentrant non-reentrant. The simplest fix would IMO be to push/pop > the argument variables in the pro-/epilog of the function marked as > __reentrant. Maybe the very first that should be added is a warning when a reentrant function calls a non-reentrant one, be it built-in or not. Furthermore I don't think this benefits from short-cuts. > * functions that only call __reentrant functions should be considered > leaf functions for the purpose of the overlay segment. This would avoid > bloating the overlay segment. Good suggestion. This could move more locals into overlay, relieving the data segment. > * 8 registers aren't a lot, if you want to add 2 32bit variables, for > example. This causes frequent spills, thus either bloating the overlay > segment, or causing expensive stack operations. Using some DATA memory > as additional registers would mitigate this. If this is added it should be a fixed number or many hard-to track bugs might pop up. > * Debug information is very basic at the moment. I don't know of a > reliable way to get at the values of non-static variables (i.e. auto or > overlay). Furthermore, call-graph information (like statement x can > continue at statement y, z or return from the function) would make > source-level single stepping possible. Stack unwind info would make > backtrace information available. > > Thomas All variables that are not on stack have a fixed address which you can find in the debug output files. Most debuggers support OMF files and these already can source-level single step. But in general, I consider it FAR more important to fix any outstanding bugs than to implement new features or improve efficiency. And since there are still >100 non-pic related bugs, I concentrate on fixing them. Maarten |