From: Philipp K. K. <pk...@sp...> - 2012-11-18 20:14:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How about releasing sdcc 3.3.0 around the end of the year? We've often had sdcc releases at that time. Here's the pros and cons I can think of: Pro: * Substantial code size improvements since 3.2.0 in the hc08, s08, z80, z180, r2k, r3ka, gbz80 ports due to the merge of the smallopts and lospre branches. * Lots of bug-fixes. * Improved pic device support. Cons: * No user-visible big changes (no new C constructs supported, no ports added) * There's many things left to do on the sdcc 3.3.0 tasks list. * Relatively small number of commits since the previous release (the number is similar to the one for 2.8.0 and 2.9.0 releases, but much lower than the one for the 3.1.0 and 3.2.0 releases). Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCpQYYACgkQbtUV+xsoLpob9QCginQDvm9MwwRe1R9qpDcaUN8p 5X0AoOcUfqduEF9qwn7y2CKVlBB99q68 =vBXX -----END PGP SIGNATURE----- |
From: Maarten B. <sou...@ds...> - 2012-11-18 20:40:11
|
Hi Philipp, Can this wait until january? I would like to have the sdas/ASxxxx upgrade done before the next release and have more spare time by the end of the year. We also have to focus on the sourceforge upgrade that should be done before the end of the year. Btw. Have you noticed that gbz80 is failing regression tests on the Raspbian machine? Maarten > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > How about releasing sdcc 3.3.0 around the end of the year? We've often > had sdcc releases at that time. Here's the pros and cons I can think of: > > Pro: > * Substantial code size improvements since 3.2.0 in the hc08, s08, > z80, z180, r2k, r3ka, gbz80 ports due to the merge of the smallopts > and lospre branches. > * Lots of bug-fixes. > * Improved pic device support. > > Cons: > * No user-visible big changes (no new C constructs supported, no ports > added) > * There's many things left to do on the sdcc 3.3.0 tasks list. > * Relatively small number of commits since the previous release (the > number is similar to the one for 2.8.0 and 2.9.0 releases, but much > lower than the one for the 3.1.0 and 3.2.0 releases). > > Philipp |
From: Philipp K. K. <pk...@sp...> - 2012-11-18 21:50:18
|
On 18.11.2012 21:40, Maarten Brock wrote: > Hi Philipp, > > Can this wait until january? Sure. Do you have a proposal for when to start the light freeze? > I would like to have the sdas/ASxxxx upgrade > done before the next release and have more spare time by the end of the > year. > > We also have to focus on the sourceforge upgrade that should be done > before the end of the year. > > Btw. Have you noticed that gbz80 is failing regression tests on the > Raspbian machine? Yes (two days ago - before it was lost in the noise of other regression failures), I'll look at it later, but it probably is another instance of the long long constant bug showing up only on some architectures. Philipp |
From: Borut R. <bor...@gm...> - 2012-11-19 07:01:47
|
On Sun, Nov 18, 2012 at 10:50 PM, Philipp Klaus Krause <pk...@sp...> wrote: > On 18.11.2012 21:40, Maarten Brock wrote: >> Hi Philipp, >> >> Can this wait until january? > > Sure. Do you have a proposal for when to start the light freeze? > >> I would like to have the sdas/ASxxxx upgrade >> done before the next release and have more spare time by the end of the >> year. There is an other missing fuctionalty which I'd like to see it in the next release: support of long long literal constants. Is anybody working on it? >> We also have to focus on the sourceforge upgrade that should be done >> before the end of the year. I'm a little bit afraid about this: I've done the upgrade on gputils project and discovered that the tracker items are renumbered without keeping references to the old bug numbers. This means that we will lose a lot of info since there are a lot of references to bugs using their tacker numbers in the ChangeLog, bug trackers, ... Maybe we should submit an enhancement request to souceforge maintainers to keep the old numbers somewhere... I doubt that the support of old system will die at end of the year, so I woud't hurry too much with the update. IMHO it is better to do the release first and the update afeter that so that there is no time pressure in something goes bad... There is an other open question regarding the migration: what to do with the sdcc wiki? I'd like to migrate it to mediawiki, but it seems that it is still not supported (at least it wasn't last time I was looking at it). And the migation will also take some time... >> Btw. Have you noticed that gbz80 is failing regression tests on the >> Raspbian machine? > > Yes (two days ago - before it was lost in the noise of other regression > failures), I'll look at it later, but it probably is another instance of > the long long constant bug showing up only on some architectures. I'll take a look tomorrow when I'll be back home: I'll make a diff with the asm file generated on a working plaform and submit a bug report if the bug is not so obvious to fix it on the fly. Borut |
From: Erik P. <epe...@iv...> - 2012-11-20 07:15:03
|
On Mon, 19 Nov 2012, Borut Ra?em wrote: > There is an other missing fuctionalty which I'd like to see it in the > next release: support of long long literal constants. Is anybody > working on it? I've been working on long long literal constants on and off. I have a fairly large edit of SDCCval.c that I haven't checked in yet because it breaks the regression tests badly and I haven't yet been able to find the cause. Erik |
From: Philipp K. K. <pk...@sp...> - 2012-11-20 16:11:35
|
Am 20.11.2012 08:14, schrieb Erik Petrich: > > > On Mon, 19 Nov 2012, Borut Ra?em wrote: > >> There is an other missing fuctionalty which I'd like to see it in the >> next release: support of long long literal constants. Is anybody >> working on it? > > I've been working on long long literal constants on and off. I have a > fairly large edit of SDCCval.c that I haven't checked in yet because it > breaks the regression tests badly and I haven't yet been able to find the > cause. > > Erik Just out of curiosity: What's your approach? Storing both a 64-bit integer and a double for every literal value? Is the diff available somewhere? Philipp |
From: Borut R. <bor...@gm...> - 2012-11-21 09:02:09
|
On 20. 11. 2012 17:11, Philipp Klaus Krause wrote: > Am 20.11.2012 08:14, schrieb Erik Petrich: >> >> On Mon, 19 Nov 2012, Borut Ra?em wrote: >> >>> There is an other missing fuctionalty which I'd like to see it in the >>> next release: support of long long literal constants. Is anybody >>> working on it? >> I've been working on long long literal constants on and off. I have a >> fairly large edit of SDCCval.c that I haven't checked in yet because it >> breaks the regression tests badly and I haven't yet been able to find the >> cause. >> >> Erik > Just out of curiosity: What's your approach? Storing both a 64-bit > integer and a double for every literal value? Is the diff available > somewhere? > > Philipp I'm curious too ;-) Borut |
From: Erik P. <epe...@iv...> - 2012-11-22 05:39:25
|
On Tue, 20 Nov 2012, Philipp Klaus Krause wrote: > Am 20.11.2012 08:14, schrieb Erik Petrich: >> >> I've been working on long long literal constants on and off. I have a >> fairly large edit of SDCCval.c that I haven't checked in yet because it >> breaks the regression tests badly and I haven't yet been able to find the >> cause. >> >> Erik > > Just out of curiosity: What's your approach? Storing both a 64-bit > integer and a double for every literal value? Is the diff available > somewhere? > > Philipp I've just extended the const_val union to include a 64-bit integer type. This part is already checked in and is consistent with what sdcc has been doing for literal values. A literal value is stored more or less as its type would indicate. (The exceptions are char and float: char is stored as an int, float is stored as a double.) I don't see the benefit of storing both an integer and double for literal values. Due to the holiday here I have a few extra days that I can work on this this week; I'll get something checked in soon. Erik |