From: Borut R. <bor...@gm...> - 2011-11-05 07:20:48
|
I'm willing to add support for all missing pic14 enh. devices to gputils and make a new release 0.14.1. If somebory wants to help me preparing the gputils gpprocessors.c file, he is welcome! It would be nice if this would be done before the sdcc RC2 release, planned for nest weekend, so that we have enough time to catch at least some of potential bugs. Borut On 11/05/2011 03:27 AM, Raphael Neider wrote: > Dear Tamas, > >> I added the enhanced 14 bit devices to the attached file. >> I also fixed some minor bugs (io = 6 was specified for some new 14bit enh. >> devices) >> >> If you agree this, please merge into the pic14devices.txt > I have included your device descriptions into sdcc r7012. However, > most of the devices are not supported by the current gputils SVN HEAD; > some probably should be, but do not have their available headers > installed (16f1826/7), some completely lack proper .inc files (which > are used to generate SDCC's device libraries). Consequently, SDCC now > fully supports only 12f1822 and 16f1933/4/6/7. Device library files > for the 16f1826/7 are provided, but not compiled in order not to break > the build process in the assembly stage. Sorry for the not-too-great > news, but anyways thanks for your contribution. > > BTW: Having included a lot of devices into pic14devices.txt means that > you *can* use sdcc -mpic14 -mpXXX -S input.c to obtain input.asm even > though the pXXX.c and pXXX.h files are missing. You'll have to declare > the SFRs manually, though. > > Kind regards, > Raphael > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Borut R. <bor...@gm...> - 2011-11-11 18:26:32
|
Hello Raphael, On 11/11/2011 08:07 AM, Raphael Neider wrote: > 1. I can check in only the new files using the old naming scheme > (underscore) for consistency. > > 2. I can check in the new files using the old naming scheme plus > updated versions of existing header files that have seen changes in > the latest gputils' templates/sources. Some bit names and config flags > have been dropped or renamed, so even this update might break user > code. > > 3. I can check in the new files using the new naming scheme together > with updated versions of all other device headers to reflect the new > naming scheme (basically a complete rewrite) and the changes made to > gputils' templates/sources from which they are generated. Due to the > changed naming convention, this will most likely break a lot of code > out there (if there is a lot of code out there, that is), but will (a) > simplify further maintenance (no manual modifications on generated > files for now), and (b) bring our headers closer to what the HiTech > compiler is using (as pointed out by Gál). At least in the long run, I > think I want to get here. > ... and no, I do not really want to maintain XXX_bits next to XXXbits or use > #ifdef LEGACY_NAMING > #define _BITSUFFIX _bits > #else > #define _BITSUFFIX bits > #endif > /* ... */XXX ## _BITSUFFIX > throughout the library ;-) > If we are going to replace XXX_bits with XXXbits in the future, I would vote for XXX_bits next to XXXbits (without LEGACY_NAMING) for old files and only XXXbits for new files and mention somewhere in the documentation that XXX_bits is deprecated and will be obsoleted (removed) in the near future. So we retain the backward compatibility and have clear path for new development / devices. But you already mentioned that you don't like this approach... >> I also fixed a nasty bug which made the gputils >> 0.14.0 unusable :-(. > How so? At least all the sdcc/pic14 and pic16 device libraries > compiled, assembled and linked without complaints (not sure about > their actual content, though)? The .cinit section is not generated for lkr files were DATABANKS heave SHADOW option. 12f1822_g.lkr is (only) such a case in gputils 0.14.0. There are also problems when the hex file is directly generated by assembler (non relocatable code), but this is not used by sdcc. Borut |
From: Raphael N. <rn...@we...> - 2011-11-11 22:34:40
|
Hi Borut, > If we are going to replace XXX_bits with XXXbits in the future, I would > vote for XXX_bits next to XXXbits (without LEGACY_NAMING) for old files > and only XXXbits for new files and mention somewhere in the > documentation that XXX_bits is deprecated and will be obsoleted > (removed) in the near future. So we retain the backward compatibility > and have clear path for new development / devices. Sounds good to me. Old device headers will include #ifndef NO_LEGACY_NAMES #define XXX_bits XXXbits /* ... */ #endif /* NO_LEGACY_NAMES */ so that legacy names are available by default but can easily be removed via -DNO_LEGACY_NAMES. New device headers only include new names (I manually removed the generated legacy section). > But you already mentioned that you don't like this approach... Well, I am a reasonable man, and your approach clearly is the better one. I just checked in the updated device library sources + script modifications + documentation updates as r7033. Unless I broke something, I am not planning any more commits before the release. Raphael |
From: Borut R. <bor...@gm...> - 2011-11-12 06:36:45
|
Hello Rapheal, On 11/11/2011 11:34 PM, Raphael Neider wrote: > Sounds good to me. Old device headers will include > > #ifndef NO_LEGACY_NAMES > #define XXX_bits XXXbits > /* ... */ > #endif /* NO_LEGACY_NAMES */ > > so that legacy names are available by default but can easily be > removed via -DNO_LEGACY_NAMES. > New device headers only include new names (I manually removed the > generated legacy section). > Great! >> But you already mentioned that you don't like this approach... > Well, I am a reasonable man, and your approach clearly is the better one. I knew you are ;-) > I just checked in the updated device library sources + script > modifications + documentation updates as r7033. Unless I broke > something, I am not planning any more commits before the release. > > Raphael I dared to add the XXX_bits deprecation note in chapter 1.4 Compatibility with previous versions to sdccman.lyx. So I think we are ready for RC2. Borut |
From: Raphael N. <rn...@we...> - 2011-11-12 12:47:28
|
Hi, > Now I saw that the RC2 is planned for the next weekend, so we have > plenty of time for testing and small corrections. Great. I realized that #define NO_LEGACY_NAMES is only meaningful if #define NO_BIT_DEFINES is also used and will thus update the according manual sections. > Raphael, can you please update the SDCC 3.1.0 Feature List page at > http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release: > currently only "Added support for pic18f2xk22/pic18f4xk22 family" is > mentioned, but I think we have a lot more ;-) Uhhh, well ... I skimmed through the ChangeLog looking for changes by me as well as changes to something pic-related and found only bug fixes and the addition of new/more devices. I updated the Wiki to also indicate support for enhanced core pic14 devices, but that's about all the news from the PIC ports this time :-( Raphael |
From: Borut R. <bor...@gm...> - 2011-11-12 10:51:35
|
On 11/12/2011 07:36 AM, Borut Ražem wrote: > So I think we are ready for RC2. Now I saw that the RC2 is planned for the next weekend, so we have plenty of time for testing and small corrections. Raphael, can you please update the SDCC 3.1.0 Feature List page at http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release: currently only "Added support for pic18f2xk22/pic18f4xk22 family" is mentioned, but I think we have a lot more ;-) Philipp & Maatren, we have to write something to the "SDCC 3.1.0 Tasks" table. Probably all open items are postponed? Maarten, can you re-check sdcc on Win98: I removed the wine bug workaround. The Win98 sdcc reinstall problem is still under investigation. Borut |
From: Maarten B. <sou...@ds...> - 2011-11-12 11:09:48
|
Hi Borut, > On 11/12/2011 07:36 AM, Borut Razem wrote: > > So I think we are ready for RC2. > > Now I saw that the RC2 is planned for the next weekend, so we have > plenty of time for testing and small corrections. > > Philipp & Maatren, we have to write something to the "SDCC 3.1.0 Tasks" > table. Probably all open items are postponed? I think so. > Maarten, can you re-check sdcc on Win98: I removed the wine bug > workaround. The Win98 sdcc reinstall problem is still under investigation. I was just working on that. It seems to work, just as I expected because I already tried with a modified build with the workaround disabled. But it seems something else came up: the w64 version no longer works (at least under wine on the DCF). I can't try on a real 64 bit windows right now, not until monday at work. The reinstall is annoying maybe, but not necessarily a showstopper. It can be explained to install twice if this can't be fixed. Maarten |
From: Philipp K. K. <pk...@sp...> - 2011-11-12 12:13:17
|
Am 12.11.2011 12:09, schrieb Maarten Brock: > Hi Borut, > >> On 11/12/2011 07:36 AM, Borut Razem wrote: >>> So I think we are ready for RC2. >> >> Now I saw that the RC2 is planned for the next weekend, so we have >> plenty of time for testing and small corrections. >> >> Philipp & Maatren, we have to write something to the "SDCC 3.1.0 Tasks" >> table. Probably all open items are postponed? > > I think so. Done. Once 3.1.0 is release I'll just copy them to the 3.2.0 list (without the "POSTPONED"). Philipp |
From: Borut R. <bor...@gm...> - 2011-11-12 17:31:43
|
Rphael, in the mean time I added support for p16f1455, p16f1458, p16f1459, p16f1782, p16f1783, p16lf1455, p16lf1458, p16lf1459, p16lf1782 and p16lf1783. Gál Zsolt provided the gpprocessor.c patch. Borut |
From: Raphael N. <rn...@we...> - 2011-11-13 23:54:38
|
Hi, > in the meantime I added support for p16f1455, p16f1458, p16f1459, > p16f1782, p16f1783, p16lf1455, p16lf1458, p16lf1459, p16lf1782 and > p16lf1783. Gál Zsolt provided the gpprocessor.c patch. SDCC r7037 also includes support for the 16F145[589] and 16F178[23] devices. However, there is no datasheet available for the 145x series, so their device description is incomplete. Luckily, all missing data is ignored by the compiler so there is no harm done. Raphael |
From: Patryk <pa...@wp...> - 2011-11-12 23:22:26
|
I have my company Win 7 x64 machine by me, I checked the installation and simple '51 file compilation - seems OK. SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.0 #7034 (Nov 12 2011) (MINGW64) Anything more to check? ----- Original Message ----- From: "Maarten Brock" <sou...@ds...> To: "Development chatter about sdcc" <sdc...@li...> Sent: Saturday, November 12, 2011 12:09 PM Subject: Re: [sdcc-devel] sdcc RC2 (was: New pic14 enhanced core devices) > Hi Borut, > >> On 11/12/2011 07:36 AM, Borut Razem wrote: >> > So I think we are ready for RC2. >> >> Now I saw that the RC2 is planned for the next weekend, so we have >> plenty of time for testing and small corrections. >> >> Philipp & Maatren, we have to write something to the "SDCC 3.1.0 Tasks" >> table. Probably all open items are postponed? > > I think so. > >> Maarten, can you re-check sdcc on Win98: I removed the wine bug >> workaround. The Win98 sdcc reinstall problem is still under >> investigation. > > I was just working on that. It seems to work, just as I > expected because I already tried with a modified build > with the workaround disabled. > > But it seems something else came up: the w64 version no > longer works (at least under wine on the DCF). I can't > try on a real 64 bit windows right now, not until monday > at work. > > The reinstall is annoying maybe, but not necessarily a > showstopper. It can be explained to install twice if > this can't be fixed. > > Maarten > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Maarten B. <sou...@ds...> - 2011-11-13 11:17:27
|
Thank you, Patryk, So it appears that the win64 build works on a real 64 bit windows but not on the compile farm machine under wine. Can you please also check the win32 build on it? Maarten > I have my company Win 7 x64 machine by me, I checked the installation and > simple '51 file compilation - seems OK. > SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 > 3.1.0 #7034 (Nov 12 2011) (MINGW64) > Anything more to check? > > ----- Original Message ----- > From: "Maarten Brock" <sou...@ds...> > To: "Development chatter about sdcc" <sdc...@li...> > Sent: Saturday, November 12, 2011 12:09 PM > Subject: Re: [sdcc-devel] sdcc RC2 (was: New pic14 enhanced core devices) > > > > Hi Borut, > > > >> On 11/12/2011 07:36 AM, Borut Razem wrote: > >> > So I think we are ready for RC2. > >> > >> Now I saw that the RC2 is planned for the next weekend, so we have > >> plenty of time for testing and small corrections. > >> > >> Philipp & Maatren, we have to write something to the "SDCC 3.1.0 Tasks" > >> table. Probably all open items are postponed? > > > > I think so. > > > >> Maarten, can you re-check sdcc on Win98: I removed the wine bug > >> workaround. The Win98 sdcc reinstall problem is still under > >> investigation. > > > > I was just working on that. It seems to work, just as I > > expected because I already tried with a modified build > > with the workaround disabled. > > > > But it seems something else came up: the w64 version no > > longer works (at least under wine on the DCF). I can't > > try on a real 64 bit windows right now, not until monday > > at work. > > > > The reinstall is annoying maybe, but not necessarily a > > showstopper. It can be explained to install twice if > > this can't be fixed. > > > > Maarten > > > > > > ------------------------------------------------------------------------------ > > RSA(R) Conference 2012 > > Save $700 by Nov 18 > > Register now > > http://p.sf.net/sfu/rsa-sfdev2dev1 > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Patryk <pa...@wp...> - 2011-11-13 11:54:34
|
Win32 build also seems to work on that machine. Installation to "C:\Program Files" required installer to be "Run as Administrator", and no such requirement to install to "C:\". ----- Original Message ----- From: "Maarten Brock" <sou...@ds...> To: "Development chatter about sdcc" <sdc...@li...> Sent: Sunday, November 13, 2011 12:17 PM Subject: Re: [sdcc-devel] sdcc RC2 (was: New pic14 enhanced core devices) > Thank you, Patryk, > > So it appears that the win64 build works on a real 64 bit windows but > not on the compile farm machine under wine. > > Can you please also check the win32 build on it? > > Maarten > >> I have my company Win 7 x64 machine by me, I checked the installation and >> simple '51 file compilation - seems OK. >> SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 >> 3.1.0 #7034 (Nov 12 2011) (MINGW64) >> Anything more to check? >> >> ----- Original Message ----- >> From: "Maarten Brock" <sou...@ds...> >> To: "Development chatter about sdcc" <sdc...@li...> >> Sent: Saturday, November 12, 2011 12:09 PM >> Subject: Re: [sdcc-devel] sdcc RC2 (was: New pic14 enhanced core devices) >> >> >> > Hi Borut, >> > >> >> On 11/12/2011 07:36 AM, Borut Razem wrote: >> >> > So I think we are ready for RC2. >> >> >> >> Now I saw that the RC2 is planned for the next weekend, so we have >> >> plenty of time for testing and small corrections. >> >> >> >> Philipp & Maatren, we have to write something to the "SDCC 3.1.0 >> >> Tasks" >> >> table. Probably all open items are postponed? >> > >> > I think so. >> > >> >> Maarten, can you re-check sdcc on Win98: I removed the wine bug >> >> workaround. The Win98 sdcc reinstall problem is still under >> >> investigation. >> > >> > I was just working on that. It seems to work, just as I >> > expected because I already tried with a modified build >> > with the workaround disabled. >> > >> > But it seems something else came up: the w64 version no >> > longer works (at least under wine on the DCF). I can't >> > try on a real 64 bit windows right now, not until monday >> > at work. >> > >> > The reinstall is annoying maybe, but not necessarily a >> > showstopper. It can be explained to install twice if >> > this can't be fixed. >> > >> > Maarten >> > >> > >> > ------------------------------------------------------------------------------ >> > RSA(R) Conference 2012 >> > Save $700 by Nov 18 >> > Register now >> > http://p.sf.net/sfu/rsa-sfdev2dev1 >> > _______________________________________________ >> > sdcc-devel mailing list >> > sdc...@li... >> > https://lists.sourceforge.net/lists/listinfo/sdcc-devel >> > >> >> >> ------------------------------------------------------------------------------ >> RSA(R) Conference 2012 >> Save $700 by Nov 18 >> Register now >> http://p.sf.net/sfu/rsa-sfdev2dev1 >> _______________________________________________ >> sdcc-devel mailing list >> sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-devel >> > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Maarten B. <sou...@ds...> - 2011-11-13 21:04:24
|
Hi, > Uhhh, well ... I skimmed through the ChangeLog looking for changes by > me as well as changes to something pic-related and found only bug > fixes and the addition of new/more devices. A good idea, so I did the same and found I had not yet documented --peep-return and --no-peep-return. And that the modified assembler no longer accepts multiple mnemonics should also be documented. It's in revision 7036. Maarten |
From: Borut R. <bor...@gm...> - 2011-11-14 19:42:20
|
On 11/12/2011 12:09 PM, Maarten Brock wrote: > But it seems something else came up: the w64 version no > longer works (at least under wine on the DCF). I can't > try on a real 64 bit windows right now, not until monday > at work. Any news? I suspect that something is wrong with the latest wine version 1.3.32. Should I try to install the wine version 1.3.8 in which the wine bug #25062 was fixed? > The reinstall is annoying maybe, but not necessarily a > showstopper. It can be explained to install twice if > this can't be fixed. Currently I really don't have enough time and energy to waste it for Win98 installer :-( If somebody else can take a look, he is welcome. If not, it will probably stay as it is. P.S.: Maarten, did you try to install sdcc 2.9.0 and upgrade it to 3.0.0? Is there the same problem or it is something new, introduced in 3.0.0? Borut |
From: Maarten B. <sou...@ds...> - 2011-11-14 22:54:22
|
> On 11/12/2011 12:09 PM, Maarten Brock wrote: >> But it seems something else came up: the w64 version no >> longer works (at least under wine on the DCF). I can't >> try on a real 64 bit windows right now, not until monday >> at work. > > Any news? I suspect that something is wrong with the latest wine version > 1.3.32. Should I try to install the wine version 1.3.8 in which the wine > bug #25062 was fixed? Err, didn't I post already about the test by Patryk that at least it works (for him) on real 64 bit windows? I did not test again at work today. I also have not investigated why it fails on wine. It's worth a shot to try wine 1.3.8. Personally I know nothing about wine. >> The reinstall is annoying maybe, but not necessarily a >> showstopper. It can be explained to install twice if >> this can't be fixed. > > Currently I really don't have enough time and energy to waste it for > Win98 installer :-( As said, there is a workaround. I wonder if there are any win98 users anyway. > If somebody else can take a look, he is welcome. If not, it will > probably stay as it is. > P.S.: Maarten, did you try to install sdcc 2.9.0 and upgrade it to > 3.0.0? Is there the same problem or it is something new, introduced in > 3.0.0? Well, I probably did last year. I may not have noticed the problem back then. I can try it again later this week. Maarten |
From: Borut R. <bor...@gm...> - 2011-11-15 05:53:44
|
On 11/14/2011 11:54 PM, Maarten Brock wrote: > Err, didn't I post already about the test by Patryk that at least it works > (for him) on real 64 bit windows? I did not test again at work today. Yes you did. I just thought that you'll do some deeper investigation... ;-) > I also have not investigated why it fails on wine. It's worth a shot to > try wine 1.3.8. Personally I know nothing about wine. I'll try it probably in the evening. >> Currently I really don't have enough time and energy to waste it for >> Win98 installer :-( > As said, there is a workaround. I wonder if there are any win98 users anyway. I have the same concerns. >> P.S.: Maarten, did you try to install sdcc 2.9.0 and upgrade it to >> 3.0.0? Is there the same problem or it is something new, introduced in >> 3.0.0? > Well, I probably did last year. I may not have noticed the problem back > then. I can try it again later this week. OK, Borut |
From: Borut R. <bor...@gm...> - 2011-11-15 20:45:30
|
On 11/15/2011 06:53 AM, Borut Ražem wrote: >> I also have not investigated why it fails on wine. It's worth a shot to >> try wine 1.3.8. Personally I know nothing about wine. > > I'll try it probably in the evening. I downgraded wine to version 1.3.8 on cf-x86 build machine. Let's keep our fingers crossed and see what will happen with tomorrow build... Borut |
From: Borut R. <bor...@gm...> - 2011-11-16 17:19:34
|
On 11/15/2011 09:45 PM, Borut Ražem wrote: > On 11/15/2011 06:53 AM, Borut Ražem wrote: >>> I also have not investigated why it fails on wine. It's worth a shot to >>> try wine 1.3.8. Personally I know nothing about wine. >> >> I'll try it probably in the evening. > > I downgraded wine to version 1.3.8 on cf-x86 build machine. Let's keep > our fingers crossed and see what will happen with tomorrow build... Hallelujah, it works! After the release I'll try to find the latest working wine version and to figure out why it doesn't work in newer versions. For now I'm happy with what we have. Borut |
From: Patryk <pa...@wp...> - 2011-11-15 21:30:39
|
> As said, there is a workaround. I wonder if there are any win98 users > anyway. There is still at least one - responsiveness of Win98 without antivirus (intentionally no internet access) is amazing even on an old PIII-500 with large RAM, you should try it :-) ----- Original Message ----- From: "Maarten Brock" <sou...@ds...> To: "Development chatter about sdcc" <sdc...@li...> Sent: Monday, November 14, 2011 11:54 PM Subject: Re: [sdcc-devel] sdcc RC2 >> On 11/12/2011 12:09 PM, Maarten Brock wrote: >>> But it seems something else came up: the w64 version no >>> longer works (at least under wine on the DCF). I can't >>> try on a real 64 bit windows right now, not until monday >>> at work. >> >> Any news? I suspect that something is wrong with the latest wine version >> 1.3.32. Should I try to install the wine version 1.3.8 in which the wine >> bug #25062 was fixed? > > Err, didn't I post already about the test by Patryk that at least it works > (for him) on real 64 bit windows? I did not test again at work today. > > I also have not investigated why it fails on wine. It's worth a shot to > try wine 1.3.8. Personally I know nothing about wine. > >>> The reinstall is annoying maybe, but not necessarily a >>> showstopper. It can be explained to install twice if >>> this can't be fixed. >> >> Currently I really don't have enough time and energy to waste it for >> Win98 installer :-( > > As said, there is a workaround. I wonder if there are any win98 users > anyway. > >> If somebody else can take a look, he is welcome. If not, it will >> probably stay as it is. > >> P.S.: Maarten, did you try to install sdcc 2.9.0 and upgrade it to >> 3.0.0? Is there the same problem or it is something new, introduced in >> 3.0.0? > > Well, I probably did last year. I may not have noticed the problem back > then. I can try it again later this week. > > Maarten > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Maarten B. <sou...@ds...> - 2011-11-15 23:13:47
|
Hi, >> As said, there is a workaround. I wonder if there are any win98 users >> anyway. > > There is still at least one - responsiveness of Win98 without antivirus > (intentionally no internet access) is amazing even on an old PIII-500 with > large RAM, you should try it :-) I guess that you are that one, because it is not me. I just tested it. I do not regularly use it. >>>> The reinstall is annoying maybe, but not necessarily a >>>> showstopper. It can be explained to install twice if >>>> this can't be fixed. >>> >>> Currently I really don't have enough time and energy to waste it for >>> Win98 installer :-( >> >> As said, there is a workaround. I wonder if there are any win98 users >> anyway. >> >>> If somebody else can take a look, he is welcome. If not, it will >>> probably stay as it is. >> >>> P.S.: Maarten, did you try to install sdcc 2.9.0 and upgrade it to >>> 3.0.0? Is there the same problem or it is something new, introduced in >>> 3.0.0? >> >> Well, I probably did last year. I may not have noticed the problem back >> then. I can try it again later this week. I just removed SDCC and then after a reboot installed 2.8.0. That works. Then I upgraded to 2.9.0 and it starts uninstall, asks for reboot, but continues installation instead and never asks for reboot again. After that it works because it never rebooted so the old path is still valid. After a manual reboot the path is gone. A reinstall fixes the path and does reboot. Next I upgraded to 3.0.0 and the same things happen. And the same happened last week when I upgraded the 3.0.0 to 3.1.0. So this appears to be a very old bug (or my win98 machine is acting up). The fact that it was never reported probably means it is not a big issue. Let's not waste any more time on it. Still I'm glad SDCC still works (again) on such an old OS. Maarten |
From: Patryk <pa...@wp...> - 2011-11-16 22:07:52
|
> Then I upgraded to 2.9.0 and it starts uninstall, asks for reboot, but > continues installation instead and never asks for reboot again. I confirm #7034 behaves as described. > The fact that it was never > reported probably means it is not a big issue. Let's not waste any more > time on it. I'm using SDCC with SiLabs IDE, and the path to SDCC is remembered by IDE, so lack of PATH get unnoticed by me during previous installs. ----- Original Message ----- From: "Maarten Brock" <sou...@ds...> To: "Development chatter about sdcc" <sdc...@li...> Sent: Wednesday, November 16, 2011 12:13 AM Subject: Re: [sdcc-devel] sdcc RC2 > Hi, > >>> As said, there is a workaround. I wonder if there are any win98 users >>> anyway. >> >> There is still at least one - responsiveness of Win98 without antivirus >> (intentionally no internet access) is amazing even on an old PIII-500 >> with >> large RAM, you should try it :-) > > I guess that you are that one, because it is not me. I just tested it. I > do not regularly use it. > >>>>> The reinstall is annoying maybe, but not necessarily a >>>>> showstopper. It can be explained to install twice if >>>>> this can't be fixed. >>>> >>>> Currently I really don't have enough time and energy to waste it for >>>> Win98 installer :-( >>> >>> As said, there is a workaround. I wonder if there are any win98 users >>> anyway. >>> >>>> If somebody else can take a look, he is welcome. If not, it will >>>> probably stay as it is. >>> >>>> P.S.: Maarten, did you try to install sdcc 2.9.0 and upgrade it to >>>> 3.0.0? Is there the same problem or it is something new, introduced in >>>> 3.0.0? >>> >>> Well, I probably did last year. I may not have noticed the problem back >>> then. I can try it again later this week. > > I just removed SDCC and then after a reboot installed 2.8.0. That works. > > Then I upgraded to 2.9.0 and it starts uninstall, asks for reboot, but > continues installation instead and never asks for reboot again. After that > it works because it never rebooted so the old path is still valid. After a > manual reboot the path is gone. A reinstall fixes the path and does > reboot. > > Next I upgraded to 3.0.0 and the same things happen. And the same happened > last week when I upgraded the 3.0.0 to 3.1.0. So this appears to be a very > old bug (or my win98 machine is acting up). The fact that it was never > reported probably means it is not a big issue. Let's not waste any more > time on it. > > Still I'm glad SDCC still works (again) on such an old OS. > > Maarten > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Gál Z. <tra...@fr...> - 2011-11-05 14:10:51
|
Dear Borut, I could managed to do the modification for my 16f1938 but I have some missing information about meaning some fields in gpprocessor.c file. I was looking for the explanation and I found that gputils wiki page is missing where I was pointed to find the missing information. I will try this modification in correlation with the information sent by Tamas and somebody will check it maybe. Regards, Zsolt |