From: Maarten B. <sou...@ds...> - 2013-05-19 22:38:43
|
Hello everyone, Today the new version 3.3.0 of SDCC has been released. As always the files can be downloaded from SourceForge: https://sourceforge.net/projects/sdcc/files/ This time there is also an installer for 64 bit Windows. Unfortunately SourceForge cannot differentiate between 32 and 64 bit Windows when detecting your running Operating System, so 64 bit users will have to open the sdcc-win64 folder themselves. I hope you all enjoy using this new version. Maarten Brock |
From: Tijl C. <tijl@FreeBSD.org> - 2013-05-20 11:41:34
|
On 2013-05-20 00:38, Maarten Brock wrote: > Today the new version 3.3.0 of SDCC has been released. > > As always the files can be downloaded from SourceForge: > https://sourceforge.net/projects/sdcc/files/ > > This time there is also an installer for 64 bit Windows. Unfortunately > SourceForge cannot differentiate between 32 and 64 bit Windows when > detecting your running Operating System, so 64 bit users will have to > open the sdcc-win64 folder themselves. > > I hope you all enjoy using this new version. It seems that in the src distribution some pic libraries (libdev18f*k22) got hidden behind --enable-new-pics configure flag. That wasn't the case with 3.2.0. I'm also seeing commands like the following with both -p18f2423 and -p18f452. Is that correct? source='adc/adcopen.c' object='libio18f2423_a-adcopen.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ '/usr/ports/head/lang/sdcc/work/sdcc-3.3.0/device/lib/pic16//../../../bin/sdcc' -DHAVE_CONFIG_H -I. -I.. -I. -I../../../include/pic16 -I../../../non-free/include/pic16 -I../../device/include -I../../device/include/mcs51 -p18f2423 --std-c99 --asm="'/usr/local/bin/gpasm'" --fomit-frame-pointer --obanksel=9 --denable-peeps --optimize-cmp --optimize-df --i-code-in-asm -DUSE_FLOATS=0 -mpic16 -p18f452 -c -o libio18f2423_a-adcopen.o `test -f 'adc/adcopen.c' || echo './'`adc/adcopen.c |
From: Raphael N. <rn...@we...> - 2013-05-20 19:20:38
|
Hi Tijl, It seems that in the src distribution some pic libraries (libdev18f*k22) > got hidden behind --enable-new-pics configure flag. That wasn't the case > with 3.2.0. > This is intentionally: Major distributions (used to) provide gputils 0.13.7, so that sdcc would default to not target devices that are not supported by this version to avoid build failures. The option has been introduced on 2012-04-22, shortly before sdcc 3.1.5. While I do not know if the device list to be excluded by default is properly maintained, I just checked the binary release and found that all libraries are included (at least the 18f*k22 ones you mentioned). So the binary release seems to complete. If you have recent gputils installed on your box, you can rebuild sdcc from source with --enable-new-pics and get support for all devices available in sdcc. From the information below, I assume you did this ;-) > I'm also seeing commands like the following with both -p18f2423 and > -p18f452. Is that correct? > > source='adc/adcopen.c' object='libio18f2423_a-adcopen.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/sh ../depcomp \ > '/usr/ports/head/lang/sdcc/work/sdcc-3.3.0/device/lib/pic16//../../../bin/sdcc' > -DHAVE_CONFIG_H -I. -I.. -I. -I../../../include/pic16 > -I../../../non-free/include/pic16 -I../../device/include > -I../../device/include/mcs51 -p18f2423 --std-c99 > --asm="'/usr/local/bin/gpasm'" --fomit-frame-pointer --obanksel=9 > --denable-peeps --optimize-cmp --optimize-df --i-code-in-asm -DUSE_FLOATS=0 > -mpic16 -p18f452 -c -o libio18f2423_a-adcopen.o `test -f 'adc/adcopen.c' || > echo './'`adc/adcopen.c > This is quite normal and due to the way the device specific libraries are built: The device-specific options are simply prepended to the general options, the latter include the default target device (-p18f452). The first -p option is actually used, the later one(s) are ignored by sdcc. Best regards Raphael |
From: Tijl C. <ti...@co...> - 2013-05-21 10:06:17
|
On 2013-05-20 21:20, Raphael Neider wrote: >> It seems that in the src distribution some pic libraries >> (libdev18f*k22) got hidden behind --enable-new-pics configure flag. >> That wasn't the case with 3.2.0. > > This is intentionally: Major distributions (used to) provide gputils > 0.13.7, so that sdcc would default to not target devices that are > not supported by this version to avoid build failures. The option has > been introduced on 2012-04-22, shortly before sdcc 3.1.5. While I do > not know if the device list to be excluded by default is properly > maintained, I just checked the binary release and found that all > libraries are included (at least the 18f*k22 ones you mentioned). So > the binary release seems to complete. Ok, I just found it peculiar, because only 18f*k22, added in gputils 0.14.x I think, were excluded, but pics added in gputils 0.15 and 1.0 weren't. Also, it's only libdev18f*k22 that is excluded, libio18f*k22 isn't. |
From: Raphael N. <rn...@we...> - 2013-05-21 17:07:14
|
Hi, > This is intentionally: [...] > > Ok, I just found it peculiar, because only 18f*k22, added in gputils > 0.14.x I think, were excluded, but pics added in gputils 0.15 and 1.0 > weren't. Also, it's only libdev18f*k22 that is excluded, libio18f*k22 > isn't. > Arrgh. I believe that I successfully built sdcc with gputils that did not support excluded devices back then. I do not remember if I treated libio specially ... And, yes, the list of 'new' devices has not been maintained when new(er) devices have been added, which leads to the situation you describe: some "older" devices are hidden whereas some "newer" ones are not. Anyway, currently, there is more viable option at hand: The devices supported by gputils are already auto-detected at configure time, so we just (tm) need to generate proper automake conditionals from them and wrap all device-specific stuff in these conditionals (libdev, libio) and -- voila -- we have a maintenance-free gputils-version-agnostic build system. ... or we would have, if someone found the time to implement it. This should not be too hard since the Makefile.am are already auto-generated if I am not mistaken... Thanks for the report; maybe something good will come from it :-D Best regards Raphael |
From: Raphael N. <rn...@we...> - 2013-05-31 06:20:34
|
Hi, Ok, I just found it peculiar, because only 18f*k22, added in gputils >> 0.14.x I think, were excluded, but pics added in gputils 0.15 and 1.0 >> weren't. Also, it's only libdev18f*k22 that is excluded, libio18f*k22 >> isn't. >> > > [...] > > Thanks for the report; maybe something good will come from it :-D > I am happy to announce that from now on (r8700) most of the pic14 and pic16 libraries are automagically built for the common subset of devices supported by sdcc and whatever gputils are currently in use. No more manual maintenance of to-be-excluded devices required ;-). This covers both the device libraries (pic14/16), the io libraries (pic16), and the pic14 enhanced core libraries libsdcce and libme. There is now even a variant for enhanced cores that avoids the extended instruction set in the libraries to allow compiling for enhanced cores with gputils 0.13.{5,6}, which do support enhanced core devices but not yet the extended instructions. Have fun! Raphael |
From: Tijl C. <ti...@co...> - 2013-06-02 13:09:01
|
On 2013-05-31 08:20, Raphael Neider wrote: > I am happy to announce that from now on (r8700) most of the pic14 and pic16 > libraries are automagically built for the common subset of devices > supported by sdcc and whatever gputils are currently in use. No more manual > maintenance of to-be-excluded devices required ;-). > This covers both the device libraries (pic14/16), the io libraries (pic16), > and the pic14 enhanced core libraries libsdcce and libme. There is now even > a variant for enhanced cores that avoids the extended instruction set in > the libraries to allow compiling for enhanced cores with gputils > 0.13.{5,6}, which do support enhanced core devices but not yet the extended > instructions. I'm eager to try it, but there haven't been any snapshots uploaded the past two days. Could this have broken the snapshot builds? |
From: Maarten B. <sou...@ds...> - 2013-06-02 13:25:22
|
> On 2013-05-31 08:20, Raphael Neider wrote: > > I am happy to announce that from now on (r8700) most of the pic14 and pic16 > > libraries are automagically built for the common subset of devices > > supported by sdcc and whatever gputils are currently in use. No more manual > > maintenance of to-be-excluded devices required ;-). > > This covers both the device libraries (pic14/16), the io libraries (pic16), > > and the pic14 enhanced core libraries libsdcce and libme. There is now even > > a variant for enhanced cores that avoids the extended instruction set in > > the libraries to allow compiling for enhanced cores with gputils > > 0.13.{5,6}, which do support enhanced core devices but not yet the extended > > instructions. > > I'm eager to try it, but there haven't been any snapshots uploaded the > past two days. Could this have broken the snapshot builds? No, this is not the cause. There has been a storm which resulted in a big power failure in the area of the owner of the snapshot mediator. As a result there will probably be no snapshots in the upcoming days. Maarten |