Re: [sdcc-devel] [Sdcc-user] Help - About AVR Branch of SDCC

-----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-----

Thread view

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"<sdcc-devel-request@...>写道：
Send sdcc-devel mailing list submissions to
sdcc-devel@...
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
sdcc-devel-request@...
You can reach the person managing the list at
sdcc-devel-owner@...
When replying, please edit your Subject line so it is more specific
than "Re: Contents of sdcc-devel digest..."

-----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-----

-----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-----

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

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