From: Gudjon I. G. <gu...@gu...> - 2012-05-18 09:14:47
|
Hi list Quite soon after the release of sdcc 3.1 I had a package ready for Debian. It is cleaned for complying with the Debian Free Software Guidelines (DFSG) but I can also make a full package for the non-free Debian part. The problem is that I haven't found a sponsor for the new version and the main reason is that version 3.1 creates a little bit bigger code than version 2.9, see below [1] I have mostly moved to ARM microcontrollers but I am very interested in keeping sdcc as a Debian package and I want the package to be up to date. But what does the list think? Does anyone miss the package? If anyone wants to adopt it or sponsor an upload you are more than welcome. The current Debian source package can be found here if anyone wants to use/test it: http://mentors.debian.net/debian/pool/main/s/sdcc/sdcc_3.1.0+dfsg-1.dsc Regards Gudjon [1] """ > I'll CC Keith on this in the hope that he'll chime in with some details > of the problems he's seeing. Perhaps you can help figure out how we > resolve these issues so that we can move forward to SDCC 3.X thereby > motivating me to want to work on the packages and help upload again? Sure, I'm seeing fairly significant code size increases from the 3.X series, the end result is that our firmware cannot fit in the available flash space when compiled with 3.X while it fits (barely) with earlier versions of the compiler. I've got one small example that compiles to 212 bytes with SDCC 2.9 but takes 246 bytes with 3.1.0 (#7066). That one seems to be an unfortunate combination of register allocation changes and some missing move optimizations. """ |
From: Diego H. <die...@di...> - 2012-05-18 09:23:42
|
I would really love to see sdcc debian packages updated. As a PIC16 port user, I'd like to see the sdcc-non-free package too. I hope you find a sponsor. Thanks On Fri, May 18, 2012 at 10:54 AM, Gudjon I. Gudjonsson <gu...@gu...>wrote: > ** > > Hi list > > Quite soon after the release of sdcc 3.1 I had a package ready for Debian. > It is cleaned for complying with the Debian Free Software Guidelines (DFSG) > but I can also make a full package for the non-free Debian part. > > > > The problem is that I haven't found a sponsor for the new version and the > main reason is that version 3.1 creates a little bit bigger code than > version 2.9, see below [1] > > > > I have mostly moved to ARM microcontrollers but I am very interested in > keeping sdcc as a Debian package and I want the package to be up to date. > But what does the list think? Does anyone miss the package? If anyone wants > to adopt it or sponsor an upload you are more than welcome. > > > > The current Debian source package can be found here if anyone wants to > use/test it: > > > > http://mentors.debian.net/debian/pool/main/s/sdcc/sdcc_3.1.0+dfsg-1.dsc > > > > Regards > > Gudjon > > > > [1] > > """ > > > I'll CC Keith on this in the hope that he'll chime in with some details > > > of the problems he's seeing. Perhaps you can help figure out how we > > > resolve these issues so that we can move forward to SDCC 3.X thereby > > > motivating me to want to work on the packages and help upload again? > > > > Sure, I'm seeing fairly significant code size increases from the 3.X > > series, the end result is that our firmware cannot fit in the available > > flash space when compiled with 3.X while it fits (barely) with earlier > > versions of the compiler. > > > > I've got one small example that compiles to 212 bytes with SDCC 2.9 but > > takes 246 bytes with 3.1.0 (#7066). That one seems to be an unfortunate > > combination of register allocation changes and some missing move > > optimizations. > > """ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Diego H. <die...@di...> - 2012-05-18 09:25:56
|
BTW, do you know the state of gputils package? Is anybody maintaining it? Thanks On Fri, May 18, 2012 at 11:22 AM, Diego Herranz < die...@di...> wrote: > I would really love to see sdcc debian packages updated. > As a PIC16 port user, I'd like to see the sdcc-non-free package too. > > I hope you find a sponsor. > > Thanks > > On Fri, May 18, 2012 at 10:54 AM, Gudjon I. Gudjonsson <gu...@gu...>wrote: > >> ** >> >> Hi list >> >> Quite soon after the release of sdcc 3.1 I had a package ready for >> Debian. It is cleaned for complying with the Debian Free Software >> Guidelines (DFSG) but I can also make a full package for the non-free >> Debian part. >> >> >> >> The problem is that I haven't found a sponsor for the new version and the >> main reason is that version 3.1 creates a little bit bigger code than >> version 2.9, see below [1] >> >> >> >> I have mostly moved to ARM microcontrollers but I am very interested in >> keeping sdcc as a Debian package and I want the package to be up to date. >> But what does the list think? Does anyone miss the package? If anyone wants >> to adopt it or sponsor an upload you are more than welcome. >> >> >> >> The current Debian source package can be found here if anyone wants to >> use/test it: >> >> >> >> http://mentors.debian.net/debian/pool/main/s/sdcc/sdcc_3.1.0+dfsg-1.dsc >> >> >> >> Regards >> >> Gudjon >> >> >> >> [1] >> >> """ >> >> > I'll CC Keith on this in the hope that he'll chime in with some details >> >> > of the problems he's seeing. Perhaps you can help figure out how we >> >> > resolve these issues so that we can move forward to SDCC 3.X thereby >> >> > motivating me to want to work on the packages and help upload again? >> >> >> >> Sure, I'm seeing fairly significant code size increases from the 3.X >> >> series, the end result is that our firmware cannot fit in the available >> >> flash space when compiled with 3.X while it fits (barely) with earlier >> >> versions of the compiler. >> >> >> >> I've got one small example that compiles to 212 bytes with SDCC 2.9 but >> >> takes 246 bytes with 3.1.0 (#7066). That one seems to be an unfortunate >> >> combination of register allocation changes and some missing move >> >> optimizations. >> >> """ >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Sdcc-user mailing list >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user >> >> > |
From: Philipp K. K. <pk...@sp...> - 2012-05-18 09:47:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18.05.2012 10:54, Gudjon I. Gudjonsson wrote: > Hi list > > Quite soon after the release of sdcc 3.1 I had a package ready for > Debian. It is cleaned for complying with the Debian Free Software > Guidelines (DFSG) but I can also make a full package for the > non-free Debian part. > > > > The problem is that I haven't found a sponsor for the new version > and the main reason is that version 3.1 creates a little bit bigger > code than version 2.9, see below [1] > More information on the code size increase can be found at http://sourceforge.net/tracker/?func=detail&aid=3400613&group_id=599&atid=100599 Code size history for some backends can be found in the graphs at http://sourceforge.net/apps/trac/sdcc/wiki/z80%20code%20size and http://sourceforge.net/apps/trac/sdcc/wiki/hc08%20code%20size it will take time go get code size back to what it was and better for all ports though. > > I have mostly moved to ARM microcontrollers but I am very > interested in keeping sdcc as a Debian package and I want the > package to be up to date. But what does the list think? Does anyone > miss the package? If anyone wants to adopt it or sponsor an upload > you are more than welcome. While I am an sdcc developer and thus get my sdcc from svn anyway I do know people that would like to see current sdcc in Debian. Philipp P.S.: I also think that a 3.2.0 release should be done sometime soon: There have been many commits since 3.1.0; the list of improvements since 3.1.0 has grown quite long: http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.2.0%20Release in particular the gbz80 port is usable again, there have been massive improvements in code size in the gbz80 and hc08 ports and sdcc now works on the Hurd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+2GqIACgkQbtUV+xsoLppOiwCghinQKFQ37sh0Kk3i0kkL5+KP VM0AniBVS8B4TFrPOWYYfQoNxS4Nc2q8 =0/be -----END PGP SIGNATURE----- |
From: Diego H. <die...@di...> - 2012-05-31 15:45:40
|
Any progress on Debian packages? Thanks! On Fri, May 18, 2012 at 11:47 AM, Philipp Klaus Krause <pk...@sp...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 18.05.2012 10:54, Gudjon I. Gudjonsson wrote: > > Hi list > > > > Quite soon after the release of sdcc 3.1 I had a package ready for > > Debian. It is cleaned for complying with the Debian Free Software > > Guidelines (DFSG) but I can also make a full package for the > > non-free Debian part. > > > > > > > > The problem is that I haven't found a sponsor for the new version > > and the main reason is that version 3.1 creates a little bit bigger > > code than version 2.9, see below [1] > > > > More information on the code size increase can be found at > > http://sourceforge.net/tracker/?func=detail&aid=3400613&group_id=599&atid=100599 > Code size history for some backends can be found in the graphs at > http://sourceforge.net/apps/trac/sdcc/wiki/z80%20code%20size > and > http://sourceforge.net/apps/trac/sdcc/wiki/hc08%20code%20size > it will take time go get code size back to what it was and better for > all ports though. > > > > > I have mostly moved to ARM microcontrollers but I am very > > interested in keeping sdcc as a Debian package and I want the > > package to be up to date. But what does the list think? Does anyone > > miss the package? If anyone wants to adopt it or sponsor an upload > > you are more than welcome. > > While I am an sdcc developer and thus get my sdcc from svn anyway I do > know people that would like to see current sdcc in Debian. > > Philipp > > P.S.: I also think that a 3.2.0 release should be done sometime soon: > There have been many commits since 3.1.0; the list of improvements > since 3.1.0 has grown quite long: > http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.2.0%20Release > in particular the gbz80 port is usable again, there have been massive > improvements in code size in the gbz80 and hc08 ports and sdcc now > works on the Hurd. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk+2GqIACgkQbtUV+xsoLppOiwCghinQKFQ37sh0Kk3i0kkL5+KP > VM0AniBVS8B4TFrPOWYYfQoNxS4Nc2q8 > =0/be > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Philipp K. K. <pk...@sp...> - 2012-06-06 10:28:45
|
Am 31.05.2012 17:44, schrieb Diego Herranz: > Any progress on Debian packages? > > Thanks! The 3.1.0 packages are in unstable now. Philipp |
From: Diego H. <die...@di...> - 2012-06-09 16:59:08
|
Great! It would be fantastic to update the stable releases often. Thank you two for the effort. On Wed, Jun 6, 2012 at 12:28 PM, Philipp Klaus Krause <pk...@sp...> wrote: > Am 31.05.2012 17:44, schrieb Diego Herranz: > > Any progress on Debian packages? > > > > Thanks! > > The 3.1.0 packages are in unstable now. > > Philipp > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Joel D. <jr...@pr...> - 2012-06-10 03:53:22
|
Hi- I'm new to sdcc, and am having some issues getting some very simple code to compile for a pic processor on a Fedora 15 system. I'm running with a clean build from a fresh checkout of the sdcc source from trunk. > sdcc -v SDCC : mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 3.1.5 #7876 (Jun 8 2012) (Linux) compiling what is essentially an 8 line program with: > sdcc --debug -mpic14 -p12f675 toggle.c I'm getting a whole string of warnings such as: /usr/local/bin/../share/sdcc/include/pic/pic12f675.h:64: warning 115: unknown or unsupported #pragma directive 'memmap INDF_ADDR INDF_ADDR SFR 0x000' followed by: /usr/local/bin/../share/sdcc/include/pic/pic12f675.h:358: error 20: Undefined identifier 'COMCON_ADDR' /usr/local/bin/../share/sdcc/include/pic/pic12f675.h:358: error 2: Initializer element is not constant I've rebuilt the .c and .h files with inc2h.pl, and was seeing the same warnings when I ran with sdcc installed from a binary using yum. Is the pic support really not ready to go yet, or is there something else going on here? Thanks for any help y'all can provide. Joel -- Joel Davidson Austin, TX jr...@pr... |
From: Raphael N. <rn...@we...> - 2012-06-11 17:12:24
|
Hi, > I'm new to sdcc, and am having some issues getting some very simple > code to compile for a pic processor on a Fedora 15 system. I'm running > with a clean build from a fresh checkout of the sdcc source from trunk. > >> sdcc -v > SDCC : > mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 > 3.1.5 #7876 (Jun 8 2012) (Linux) > > compiling what is essentially an 8 line program with: >> sdcc --debug -mpic14 -p12f675 toggle.c > > I'm getting a whole string of warnings such as: > /usr/local/bin/../share/sdcc/include/pic/pic12f675.h:64: warning 115: > unknown or unsupported #pragma directive 'memmap INDF_ADDR INDF_ADDR SFR 0x000' pic12f675.h as currently distributed does not contain any #pragma lines. Are you sure you actually use your newly built sdcc ('which sdcc' might tell you that you actually use /usr/local/bin/sdcc instead of /home/login/bin/sdcc or wherever you installed your built sdcc). I guess that Fedora comes with some ancient (?) sdcc installed via the package manager, which now causes confusion. Please ./configure --prefix=$HOME/local sdcc, make && make install it, export PATH=$HOME/local/bin:$PATH, purge the shell's cache using 'hash -r' and try again. You might also pass -I/path/to/non-free/include/pic14 to force the compiler to look there first. The other errors seem to be follow-ups. > I've rebuilt the .c and .h files with inc2h.pl, and was seeing the same This procedure is not really recommended (nor usually required) for users ... > warnings when I ran with sdcc installed from a binary using yum. Ah, interesting. So there is / was an sdcc installed via yum. Please uninstall and try again. > Is the pic support really not ready to go yet, or is there something > else going on here? The PIC backends are usually useable, though they are not as mature as most other backends. Best regards Raphael |
From: Joel D. <jr...@pr...> - 2012-06-12 14:00:12
|
On Mon, 11 Jun 2012, it would appear that Raphael Neider wrote: > Hi, > >> I'm new to sdcc, and am having some issues getting some very simple >> code to compile for a pic processor on a Fedora 15 system. I'm running >> with a clean build from a fresh checkout of the sdcc source from trunk. >> >>> sdcc -v >> SDCC : >> mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 >> 3.1.5 #7876 (Jun 8 2012) (Linux) >> >> compiling what is essentially an 8 line program with: >>> sdcc --debug -mpic14 -p12f675 toggle.c >> >> I'm getting a whole string of warnings such as: >> /usr/local/bin/../share/sdcc/include/pic/pic12f675.h:64: warning 115: >> unknown or unsupported #pragma directive 'memmap INDF_ADDR INDF_ADDR SFR 0x000' > > pic12f675.h as currently distributed does not contain any #pragma > lines. Are you sure you actually use your newly built sdcc ('which > sdcc' might tell you that you actually use /usr/local/bin/sdcc instead > of /home/login/bin/sdcc or wherever you installed your built sdcc). I > guess that Fedora comes with some ancient (?) sdcc installed via the > package manager, which now causes confusion. > Please ./configure --prefix=$HOME/local sdcc, make && make install it, > export PATH=$HOME/local/bin:$PATH, purge the shell's cache using 'hash > -r' and try again. You might also pass > -I/path/to/non-free/include/pic14 to force the compiler to look there > first. > > The other errors seem to be follow-ups. > >> I've rebuilt the .c and .h files with inc2h.pl, and was seeing the same > > This procedure is not really recommended (nor usually required) for users ... > >> warnings when I ran with sdcc installed from a binary using yum. > > Ah, interesting. So there is / was an sdcc installed via yum. Please > uninstall and try again. > >> Is the pic support really not ready to go yet, or is there something >> else going on here? > > The PIC backends are usually useable, though they are not as mature as > most other backends. > > Best regards > Raphael Raphael- I rebuilt sdcc as you suggested, and running it with the -I<path to include> seems to compile ok. I added -L<path to libs> and it looks everything got generated. I'll dump the hex file to make sure it's what I expect, but it looks good now. Thanks for your help. Joel -- Joel Davidson Austin, TX jr...@pr... |