You can subscribe to this list here.
2000 |
Jan
(1) |
Feb
(56) |
Mar
(65) |
Apr
(18) |
May
(40) |
Jun
(12) |
Jul
(18) |
Aug
(19) |
Sep
(164) |
Oct
(86) |
Nov
(67) |
Dec
(29) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(96) |
Feb
(176) |
Mar
(119) |
Apr
(59) |
May
(181) |
Jun
(193) |
Jul
(140) |
Aug
(180) |
Sep
(182) |
Oct
(322) |
Nov
(263) |
Dec
(187) |
2002 |
Jan
(130) |
Feb
(83) |
Mar
(106) |
Apr
(28) |
May
(39) |
Jun
(46) |
Jul
(78) |
Aug
(107) |
Sep
(66) |
Oct
(33) |
Nov
(58) |
Dec
(53) |
2003 |
Jan
(197) |
Feb
(261) |
Mar
(282) |
Apr
(242) |
May
(218) |
Jun
(107) |
Jul
(108) |
Aug
(78) |
Sep
(129) |
Oct
(181) |
Nov
(139) |
Dec
(108) |
2004 |
Jan
(224) |
Feb
(185) |
Mar
(115) |
Apr
(102) |
May
(98) |
Jun
(103) |
Jul
(124) |
Aug
(88) |
Sep
(124) |
Oct
(100) |
Nov
(74) |
Dec
(79) |
2005 |
Jan
(66) |
Feb
(83) |
Mar
(123) |
Apr
(53) |
May
(109) |
Jun
(46) |
Jul
(126) |
Aug
(78) |
Sep
(61) |
Oct
(43) |
Nov
(213) |
Dec
(93) |
2006 |
Jan
(63) |
Feb
(109) |
Mar
(79) |
Apr
(185) |
May
(283) |
Jun
(179) |
Jul
(147) |
Aug
(156) |
Sep
(114) |
Oct
(173) |
Nov
(137) |
Dec
(148) |
2007 |
Jan
(154) |
Feb
(108) |
Mar
(132) |
Apr
(151) |
May
(241) |
Jun
(94) |
Jul
(109) |
Aug
(50) |
Sep
(62) |
Oct
(128) |
Nov
(90) |
Dec
(74) |
2008 |
Jan
(53) |
Feb
(161) |
Mar
(261) |
Apr
(53) |
May
(87) |
Jun
(44) |
Jul
(73) |
Aug
(67) |
Sep
(54) |
Oct
(37) |
Nov
(72) |
Dec
(53) |
2009 |
Jan
(51) |
Feb
(73) |
Mar
(84) |
Apr
(67) |
May
(59) |
Jun
(31) |
Jul
(78) |
Aug
(45) |
Sep
(90) |
Oct
(56) |
Nov
(69) |
Dec
(51) |
2010 |
Jan
(188) |
Feb
(73) |
Mar
(20) |
Apr
(46) |
May
(91) |
Jun
(24) |
Jul
(115) |
Aug
(135) |
Sep
(132) |
Oct
(90) |
Nov
(92) |
Dec
(58) |
2011 |
Jan
(121) |
Feb
(90) |
Mar
(56) |
Apr
(79) |
May
(98) |
Jun
(109) |
Jul
(104) |
Aug
(113) |
Sep
(234) |
Oct
(143) |
Nov
(160) |
Dec
(93) |
2012 |
Jan
(162) |
Feb
(160) |
Mar
(219) |
Apr
(186) |
May
(135) |
Jun
(360) |
Jul
(138) |
Aug
(72) |
Sep
(130) |
Oct
(146) |
Nov
(64) |
Dec
(137) |
2013 |
Jan
(65) |
Feb
(18) |
Mar
(35) |
Apr
(26) |
May
(108) |
Jun
(34) |
Jul
(16) |
Aug
(11) |
Sep
(61) |
Oct
(4) |
Nov
(23) |
Dec
(24) |
2014 |
Jan
(56) |
Feb
(58) |
Mar
(54) |
Apr
(26) |
May
(3) |
Jun
(31) |
Jul
(13) |
Aug
(13) |
Sep
(7) |
Oct
(26) |
Nov
(65) |
Dec
(54) |
2015 |
Jan
(64) |
Feb
(15) |
Mar
(25) |
Apr
(41) |
May
(22) |
Jun
(62) |
Jul
(26) |
Aug
(17) |
Sep
(35) |
Oct
(33) |
Nov
(37) |
Dec
(17) |
2016 |
Jan
(39) |
Feb
(12) |
Mar
(15) |
Apr
(13) |
May
(41) |
Jun
(76) |
Jul
(53) |
Aug
(38) |
Sep
(31) |
Oct
(11) |
Nov
(9) |
Dec
(19) |
2017 |
Jan
(11) |
Feb
(19) |
Mar
|
Apr
(28) |
May
(61) |
Jun
(9) |
Jul
(9) |
Aug
(14) |
Sep
|
Oct
(63) |
Nov
(43) |
Dec
(21) |
2018 |
Jan
(24) |
Feb
(46) |
Mar
(38) |
Apr
(6) |
May
(14) |
Jun
(10) |
Jul
(12) |
Aug
(12) |
Sep
(29) |
Oct
(9) |
Nov
(17) |
Dec
(22) |
2019 |
Jan
(20) |
Feb
(22) |
Mar
(22) |
Apr
(10) |
May
(2) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
(5) |
Oct
(13) |
Nov
(8) |
Dec
(11) |
2020 |
Jan
(23) |
Feb
(14) |
Mar
(2) |
Apr
(11) |
May
(14) |
Jun
(48) |
Jul
(111) |
Aug
(26) |
Sep
(6) |
Oct
(22) |
Nov
(7) |
Dec
(26) |
2021 |
Jan
(4) |
Feb
(40) |
Mar
(64) |
Apr
(46) |
May
(18) |
Jun
(20) |
Jul
(11) |
Aug
(40) |
Sep
(16) |
Oct
(15) |
Nov
(46) |
Dec
(10) |
2022 |
Jan
(60) |
Feb
(163) |
Mar
(117) |
Apr
(8) |
May
(22) |
Jun
(13) |
Jul
(5) |
Aug
(1) |
Sep
(20) |
Oct
(4) |
Nov
(13) |
Dec
(16) |
2023 |
Jan
(45) |
Feb
(5) |
Mar
(1) |
Apr
(7) |
May
(128) |
Jun
(41) |
Jul
(40) |
Aug
(52) |
Sep
(20) |
Oct
(18) |
Nov
(40) |
Dec
(52) |
2024 |
Jan
(19) |
Feb
(5) |
Mar
(6) |
Apr
(18) |
May
(5) |
Jun
(20) |
Jul
(58) |
Aug
(16) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
From: Sandeep D. <sa...@dd...> - 2000-03-19 03:36:47
|
Hi Dave, The website now looks really nice..clean and to the point. Iam ready with version 2.2.0 ..how about early next week. What do I need to do?? Iam going to switch the geocities account.. Three things. a) My Wife wants to be removed from the ACK List. b) How about the on-line documentation ? c) User mailing list ?? what do we do about that?? Sandeep |
From: Michael H. <mic...@ea...> - 2000-03-17 03:44:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > ok heres a quickie, runnign under win2k, with latest ( 2.92 ) gbdk, sdcc > allways complains > > "error *** Creation of temp file failed" > > every time it is run > > any ideas? > > ( temp set to "c:\temp\" > tmp set to "c:\temp\" ) Hi Visa. Your the second person to report this - I cant explain it or reproduce it. My first suggestion is to test making a new directory, setting TMP to that and trying again e.g: mkdir c:\tmp set TMP=c:\tmp If that doesnt fix it (I'm not sure why it would), could you please send me the output of compiling with the '-v' (verbose) option - it should show all the filenames used. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE40ajsUejL3SuzxEgRAn2DAJwPy+llu9d5gsK+VTfL1jrV1j88WwCcDIKr rDo0p9x8uivxONsaf9dPyKs= =FY1l -----END PGP SIGNATURE----- |
From: Sandeep D. <sa...@dd...> - 2000-03-12 00:50:00
|
Kevin had mentioned something abouts docs sometime ago.. I used LyX a freeware opensource WordProcessor (actually a very good one)...to create the document. The file SDCCUdoc.lyx is the actual source file can be edited with LyX.. LyX can be downloaded from <http://www.lyx.org> This can export the doc in sgml..I then used sgml2html to convert to html fairly easy process.. LyX takes a while to build... IF any one has any better tools Iam willing to switch .. Sandeep |
From: Sandeep D. <sa...@dd...> - 2000-03-12 00:45:44
|
Hi Michael , Your fix for the == IS_LITERAL looks good.. however the crash was because the local variable "key2" is being used before it is defined inside a loop, the compiler was not detecting this situation...have fixed it.. the caveat being such variables will be spilt.... Have mode some more infrastructural changes so "make clean" required... Sandeep > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Here's the one I found while releasing gbdk3-2.92: > > This code: > > typedef unsigned char UBYTE; > > UBYTE joypad(void); > > enum { > J_UP, J_DOWN, J_A > }; > > void main() > { > UBYTE key1, key2, j; > j = 0; > > while(1) { > key1 = joypad(); > if(!(key1 & J_A)){ > if((key1 & J_UP) && !(key2 & J_UP) && j > 0) > j--; > else if((key1 & J_DOWN) && !(key2 & J_DOWN) && j < 3) > j++; > } > key2 = key1; > } > } > > Causes a segfault in sdcc-mcs51 and sdcc-gbz80. If you init key2 i.e: > > j = 0; > key2 = anything; > > it's fine. > > I've also made a small change to SDCCicode.c re: IS_LITERAL. In some > cases esp in geniCodeCast geniCodeAssign the class of an operand is > derrived, then IS_LITERAL is run on the class. Problem is in some cases > when the operand is a SYMBOL then IS_LITERAL also passes, which later > causes a segfault in floatFromVal. I changed the check IS_LITERAL(etype) > to op->type == VALUE && IS_LITERAL() in the cases that were segfaulting > for me but didnt check any others... > > - -- Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.0 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE4yeLUUejL3SuzxEgRAgGbAKCgUwtC2qC8yaBqP8XtRHrgkqNCHwCgpRYz > I+p9be/fBKJU1w7aziIfAYI= > =OIyO > -----END PGP SIGNATURE----- > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel |
From: Michael H. <mic...@ea...> - 2000-03-11 06:12:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's the one I found while releasing gbdk3-2.92: This code: typedef unsigned char UBYTE; UBYTE joypad(void); enum { J_UP, J_DOWN, J_A }; void main() { UBYTE key1, key2, j; j = 0; while(1) { key1 = joypad(); if(!(key1 & J_A)){ if((key1 & J_UP) && !(key2 & J_UP) && j > 0) j--; else if((key1 & J_DOWN) && !(key2 & J_DOWN) && j < 3) j++; } key2 = key1; } } Causes a segfault in sdcc-mcs51 and sdcc-gbz80. If you init key2 i.e: j = 0; key2 = anything; it's fine. I've also made a small change to SDCCicode.c re: IS_LITERAL. In some cases esp in geniCodeCast geniCodeAssign the class of an operand is derrived, then IS_LITERAL is run on the class. Problem is in some cases when the operand is a SYMBOL then IS_LITERAL also passes, which later causes a segfault in floatFromVal. I changed the check IS_LITERAL(etype) to op->type == VALUE && IS_LITERAL() in the cases that were segfaulting for me but didnt check any others... - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4yeLUUejL3SuzxEgRAgGbAKCgUwtC2qC8yaBqP8XtRHrgkqNCHwCgpRYz I+p9be/fBKJU1w7aziIfAYI= =OIyO -----END PGP SIGNATURE----- |
From: Michael H. <mic...@ea...> - 2000-03-09 05:53:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all. I've just release gbdk3-2.92. I also came across an uninited varible bug but it's late :) Tomorrow... - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4xztFUejL3SuzxEgRAt9YAJ0WImK2dLQPLiUjqsCR4thIiHVVogCgq5Ga opQmfSokL7YHumXV1hRzzHI= =3W7L -----END PGP SIGNATURE----- |
From: Sandeep D. <sa...@dd...> - 2000-03-08 02:29:31
|
Kevin , This was a nasty one a combinations of two situations.. here is what the register allocator was trying to do and failed because of bugs if we are running out of registers then pick an iTemp which is assigned to registers and if it is not defined or used in this block or not used in the remainder of the block then add a push and pop for this itemp at the start and end of this block and use its registers... in this case iTemp1 was chosen but it should not have been since it is used in the block...coupled with the problem that iTemp1 was being allocated at this time... Fixed now .. update mcs51/ralloc.c I checked z80/ralloc.c this feature has been disabled so this bug should be there... Sandeep > > Compiling the following code for the mcs51 target causes a compiler > coredump: > > char bar(long p1, long p2) reentrant > { > long *lp; > > lp = &p2; > > return (char)(p1 + *lp); > } > > This occurs when ralloc.c calls reassignLR on a variable that was > never assigned a full set of registers (i.e. getRegGpr spilled the > variable). reassignLR() seems to assume that the variable has a full > set of registers assigned to it before it was spilled. > > That's as far as I've gotten; I can't see an obvious fix... > > Peace, > Kevin > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Michael H. <mic...@ea...> - 2000-03-08 00:08:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > This occurs when ralloc.c calls reassignLR on a variable that was > never assigned a full set of registers (i.e. getRegGpr spilled the > variable). reassignLR() seems to assume that the variable has a full > set of registers assigned to it before it was spilled. I've seen a similar problem, but I'm not sure if it's my fault :) Basically sym->nRegs != 0, but sym->regs[] = { 0, 0, 0, 0 } which causes a segfault in deassignLR. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4xZjhUejL3SuzxEgRArGpAJwI5IwmBZtUJGtrPY3/exKgdfnDNQCdFLaT G8OxZ+WTcedEg55iRM/ESeE= =a4kt -----END PGP SIGNATURE----- |
From: Kevin V. <ke...@vi...> - 2000-03-07 23:43:26
|
Compiling the following code for the mcs51 target causes a compiler coredump: char bar(long p1, long p2) reentrant { long *lp; lp = &p2; return (char)(p1 + *lp); } This occurs when ralloc.c calls reassignLR on a variable that was never assigned a full set of registers (i.e. getRegGpr spilled the variable). reassignLR() seems to assume that the variable has a full set of registers assigned to it before it was spilled. That's as far as I've gotten; I can't see an obvious fix... Peace, Kevin |
From: <Mic...@t-...> - 2000-03-06 22:19:31
|
It works again now ! the problem seems to be with the gcc-2.95.2 updates i have installed for mingw32. if i install the pure cygwin, make realclean seems to work. if i install the updates for cygwin, i get the problems as discribed below. Michael ----- Original Message ----- From: "Michael Schmitt" <Mic...@t-...> To: <sdc...@li...> Sent: Monday, March 06, 2000 10:47 PM Subject: Re: [sdcc-devel] Pointer & other problems & V2.2.0 > OK, Sandeep i have tried that. > > i have deleted c:\usr\local\.... and copied all from c:\src\sdcc\... to > c:\usr\local\.... to start from nothing. > started make realclean (this is doing a lot) and ./configure --prefix.... > the ./configure reported a short moment later > > BASH.EXE-2.02$ ./configure --prefix=/usr/local > creating cache ./config.cache > checking for mawk... no > checking for gawk... gawk > checking version of the package... 2.2.0 > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking for c++... c++ > checking whether the C++ compiler (c++ ) works... no > configure: error: installation or configuration problem: C++ compiler cannot > cre > ate executables. > > so i deleted c:\usr\local again ....... didn't execute the make realclean > and step over to ./configure > but it is always the same. so i uninstalled cygwin, reboot and installed it > again. repeated those steps, but again. > > so, currently i have deleted c:\src\sdcc\... and c:\usr\local\... > downloading everything new and reinstalling cygwin, as i do not get rid of > that what "make realclean" has done to this system. > > cygwin has worked fine before this make realclean. > > So do i need it even if i delete the whole stuff under c:\usr\local and copy > the sources ? i usually have used ./configure .. and a make followed by a > make install. if cvs has new files, i deleted this tree and copied it again. > > sorry, but for the moments this system is offline for compiling sdcc. > > Michael (a little bit sad) :-( > > > ----- Original Message ----- > From: "Sandeep Dutta" <sa...@dd...> > To: <sdc...@li...> > Sent: Monday, March 06, 2000 12:31 AM > Subject: Re: [sdcc-devel] Pointer & other problems & V2.2.0 > > > > Hi Michael , > > > > > From: "Sandeep Dutta" <sa...@dd...> > > > > > > > Downloaded the latest tree & got a clean build ..:-) we are very very > > > > close. > > > > > > i have tried to compile it under cygwin, but i cannot find s51.exe (is > it > > > not compiled ?) > > > the source was located under c:\usr\local > > > > > > > You have to do > > >make realclean > > >./configure > > >make > > > > > BTW Author, in the folder device\examples are some files (cpu_tool.c > > > cpu_tools.h and main8051.c) i guess the version i posted to thorsten OKR > Web > > > page. these files need to be updated, as they contain some bugs i have > > > already fixed. one is with buffers for serial rx/tx > 127 bytes. it does > not > > > work with V2.19Ga and the serial buffers get corrupted. maybe this has > to do > > > with the signed/unsigned comparision problem reported from "Dafni & > Robert > > > Berger" a week ago. if anybody can tell me how i can update these files > > > would be nice. > > > > > > > I forgot to mention you have to use --float-reent option also...the latest > tree > > compiles the libraries okay with the options..but beaware that dhrystone > > may not run on 8051 because of the severely limited stack space. > > > > As for updating the examples please register and obtain an usedid from > > sourceforge & I will be glad to add you in the developer list so that you > > can update the files yourself..... > > > > Sandeep > > > > > > > > Hope this helps if i haven't done something wrong .... now continuing > with > > > the ethernet schematics .. > > > > > > Michael > > > > > > _______________________________________________ > > > sdcc-devel mailing list > > > sdc...@li... > > > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel > > > > > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel |
From: Sandeep D. <sa...@dd...> - 2000-03-06 21:57:25
|
Fixed... Sandeep Kevin Vigor wrote: > > Compiling the following currently coredumps the compiler: > > void foo(unsigned char *s) > { > s[0] = 'c'; > } > > This occurs when cseBBlock calls aggrToPtr() with a NULL type > pointer. A piCode of the iCode that got passed into cseBBlock looks > like: > > c.c(3:0:5:0:0) *(iTemp2 [k5 lr0:0 so:0]{ ia1 re0 rm0}{}) := > 0x63 {char } > > Note the lack of any type information at all on the result portion of > the opcode. > > I'm looking, but help appreciated as always. > > Peace, > Kevin > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: <Mic...@t-...> - 2000-03-06 21:51:48
|
OK, Sandeep i have tried that. i have deleted c:\usr\local\.... and copied all from c:\src\sdcc\... to c:\usr\local\.... to start from nothing. started make realclean (this is doing a lot) and ./configure --prefix.... the ./configure reported a short moment later BASH.EXE-2.02$ ./configure --prefix=/usr/local creating cache ./config.cache checking for mawk... no checking for gawk... gawk checking version of the package... 2.2.0 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for c++... c++ checking whether the C++ compiler (c++ ) works... no configure: error: installation or configuration problem: C++ compiler cannot cre ate executables. so i deleted c:\usr\local again ....... didn't execute the make realclean and step over to ./configure but it is always the same. so i uninstalled cygwin, reboot and installed it again. repeated those steps, but again. so, currently i have deleted c:\src\sdcc\... and c:\usr\local\... downloading everything new and reinstalling cygwin, as i do not get rid of that what "make realclean" has done to this system. cygwin has worked fine before this make realclean. So do i need it even if i delete the whole stuff under c:\usr\local and copy the sources ? i usually have used ./configure .. and a make followed by a make install. if cvs has new files, i deleted this tree and copied it again. sorry, but for the moments this system is offline for compiling sdcc. Michael (a little bit sad) :-( ----- Original Message ----- From: "Sandeep Dutta" <sa...@dd...> To: <sdc...@li...> Sent: Monday, March 06, 2000 12:31 AM Subject: Re: [sdcc-devel] Pointer & other problems & V2.2.0 > Hi Michael , > > > From: "Sandeep Dutta" <sa...@dd...> > > > > > Downloaded the latest tree & got a clean build ..:-) we are very very > > > close. > > > > i have tried to compile it under cygwin, but i cannot find s51.exe (is it > > not compiled ?) > > the source was located under c:\usr\local > > > > You have to do > >make realclean > >./configure > >make > > > BTW Author, in the folder device\examples are some files (cpu_tool.c > > cpu_tools.h and main8051.c) i guess the version i posted to thorsten OKR Web > > page. these files need to be updated, as they contain some bugs i have > > already fixed. one is with buffers for serial rx/tx > 127 bytes. it does not > > work with V2.19Ga and the serial buffers get corrupted. maybe this has to do > > with the signed/unsigned comparision problem reported from "Dafni & Robert > > Berger" a week ago. if anybody can tell me how i can update these files > > would be nice. > > > > I forgot to mention you have to use --float-reent option also...the latest tree > compiles the libraries okay with the options..but beaware that dhrystone > may not run on 8051 because of the severely limited stack space. > > As for updating the examples please register and obtain an usedid from > sourceforge & I will be glad to add you in the developer list so that you > can update the files yourself..... > > Sandeep > > > > > Hope this helps if i haven't done something wrong .... now continuing with > > the ethernet schematics .. > > > > Michael > > > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel |
From: Kevin V. <ke...@vi...> - 2000-03-06 21:07:13
|
Compiling the following currently coredumps the compiler: void foo(unsigned char *s) { s[0] = 'c'; } This occurs when cseBBlock calls aggrToPtr() with a NULL type pointer. A piCode of the iCode that got passed into cseBBlock looks like: c.c(3:0:5:0:0) *(iTemp2 [k5 lr0:0 so:0]{ ia1 re0 rm0}{}) := 0x63 {char } Note the lack of any type information at all on the result portion of the opcode. I'm looking, but help appreciated as always. Peace, Kevin |
From: Sandeep D. <sa...@dd...> - 2000-03-06 18:57:59
|
Hi Anton , This is fixed as well Sandeep > > Hi all! > > Here is another troublesome program (checked with CVS snapshot of march 6 & > 2.1.9Ga): > > char f(unsigned char c) { > return (~(1 << c)); > } > > void main() { > f(3); > } > > sdcc generates the following: > > _f: > ar2 = 0x02 > ar3 = 0x03 > ar4 = 0x04 > ar5 = 0x05 > ar6 = 0x06 > ar7 = 0x07 > ar0 = 0x00 > ar1 = 0x01 > ; shl_bug.c 2 > mov r2,dpl > mov dpl,#0xfe > 00101$: > > I.e. no shift in this case - probably this is a bug in optimization. > > Best regards, Anton Voloshin mailto:va...@is... > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Sandeep D. <sa...@dd...> - 2000-03-06 18:57:42
|
Hi Anton This is fixed. Sandeep > > Hi all! > > The following code compiles wrong in sdcc (CVS snapshot of March 6 & > 2.1.9Ga): > > void f(); > > idata int l; > > void main() { > if (l == 123) f(); > } > > It generates the code: > ; switch.c 6 > mov r0,#_l > cjne @r0,#0x7b,00106$ > inc r0 > ; Peephole 132 changed ljmp to sjmp > ; Peephole 199 optimized misc jump sequence > cjne @r0,#0x00,00103$ > ; Peephole 201 removed redundant sjmp > 00106$: > 00107$: > lcall _f > 00103$: > > i.e. f() is called if low byte of l is != 123. > The problem is in peephole rule 199: > > replace { > cjne %1,%2,%3 > sjmp %4 > %3: > sjmp %5 > } by { > ; Peephole 199 optimized misc jump sequence > cjne %1,%2,%5 > sjmp %4 > %3: > } > > This rule works incorrectly when we have another jmp to %3. > > The problem may be solved by adding some more rules to src/mcs51/peeph.def. > The patch which does that is attached to this letter. (I have no account to > commit to sdcc CVS). > But I feel a bit unsure anyway about some rules in peeph.def (including > #199). > Maybe it would be cool to make it possible to add intelligent rules (i.e. > counting reference count to %3 is this case), > but i think this will be too slow :( > > Best regards, Anton Voloshin mailto:va...@is... > > ------------------------------------------------------------------------ > Name: peep-bug.patch > peep-bug.patch Type: unspecified type (application/octet-stream) > Encoding: quoted-printable -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Sandeep D. <sa...@dd...> - 2000-03-06 18:57:23
|
Hi Michael, The array problem is fixed. The segment fault problem ..... I think you need to do a make clean & build everything fresh..some dependency is missing make sure you get the latest sources since I changed a lot..I got the same problem then rebuilt after make clean & it went away.. PS. I fixed the z80 assembler & linker makefiles to build with ./configure & make.. (I made the change before I got your email..they build but have not verified ) Sandeep > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > however the fix for "&a[n]" was a little easier the lavaluereq flag > > would be incremented > > On the gb, something like: > > const unsigned char *film[] = { > &door1_tiles[0x0C*0], > &door2_tiles[0x0C*0], > &door3_tiles[0x0C*0], > .... > > Only sets the first byte. i.e it generates: > > ld de,#film + 0 > ld a,#<(_door1_tiles+0) > ld (de),a > ld de,#film + 2 > ld a,#<(_door1_tiles+0) > ld (de),a > > That was this morning - now I do not know. Also something is trashing > memory since this morning - compiling galaxy.c in the gbdk package (theres > a tarball on sourceforge under gbdk) segfaults with a corrupted symbol. I > dont know whos fault is it yet :) > > Has anyone seen this before? Is it truly trashed memory? Here is gdb's > backtrace: > > (gdb) backtrace > #0 addSet (list=0x20, item=0x8101550) at SDCCset.c:133 > #1 0x805c973 in allocIntoSeg (sym=0x20) at SDCCmem.c:250 > #2 0x805cb3e in allocGlobal (sym=0x8101550) at SDCCmem.c:363 > #3 0x805d501 in allocVariables (symChain=0x8101550) at SDCCmem.c:748 > #4 0x8049607 in yyparse () at SDCC.y:128 > > You can see that sym in (2) is currupted... > > > in this case fixed it and checked things in ...fixed a couple > of other > stuff too. > > > > s51 is abending with memory fault when I use "-r " option so cannot > > use it from the debugger ..looking into this... > > > > Michael anyplans for a z80 library ..or do you have them separate from > > the compiler. > The gbdk-lib package on cvs.gbdk.sourceforge.net has support for the z80 > as well. I'm not sure how to handle this yet :) We can always hack > something together for 2.2.0 or tell them to get the libs seperatly. > > > I will fix the makefiles for the z80 assembler & linker sothat they > > build with .configure .... > I'd prefer not to - amost all of the rules are in Makefile.common and are > inherieted from there. Using a shared rules file makes the Makefiles more > maintainable & cleaner. > > Blah blah. Trying to release gbdk3-2.92 today - I just have to try and > keep up with Sandeep :) > > - -- Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.0 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE4wvEOUejL3SuzxEgRAlyVAKCqDuatqrCwMgkjTzExfKwAtWmpxgCfYXAt > utjogDc5imd7G6n+jnTJh/o= > =ry7K > -----END PGP SIGNATURE----- > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sandeep Dutta Phone: 650-356-5417 Diab-SDS Fax: 650-356-5490 323 Vintage Park Drive Email: sa...@dd... Foster City, CA 94404 URL: www.ddi.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Sandeep D. <arc...@db...> - 2000-03-06 14:16:56
|
This message was sent from Geocrawler.com by "Sandeep Dutta" <san...@us...> Be sure to reply to that address. Kevin, Your fix for the situation c[n][m] = 0xfe; was right on the money ...However the fix for &array[n] was a lot simpler the lvaleureq flag should be set in this case and I fixed that in ast2iCode() function... Have checked in all the changes.... PS checked out everything fresh got a clean build ...we are close to 2.2.0 .. Sandeep Geocrawler.com - The Knowledge Archive |
From: Anton V. <va...@is...> - 2000-03-06 13:23:23
|
Hi all! It's me again :) I've found a preprocessor bug in sdcc (CVS snapshot of March 6 as well as 2.1.9Ga). The following program: #define A 1 #if A #endif void main() {} Generates the following: ;....... ; line.c 5 ; ----------------------------------------- ; function main ; ----------------------------------------- _main: ;....... Line number should be 6 instead. But if I'm using #ifdef instead of #if - everything is Ok. This bug can seriously confuse people when debugging in sdcdb (wrong line numbers information). Best regards, Anton Voloshin mailto:va...@is... P.S. There is no error message if I'm omitting #endif - this is probably a bug too |
From: Anton V. <va...@is...> - 2000-03-06 13:23:18
|
Hi all! Here is another troublesome program (checked with CVS snapshot of march 6 & 2.1.9Ga): char f(unsigned char c) { return (~(1 << c)); } void main() { f(3); } sdcc generates the following: _f: ar2 = 0x02 ar3 = 0x03 ar4 = 0x04 ar5 = 0x05 ar6 = 0x06 ar7 = 0x07 ar0 = 0x00 ar1 = 0x01 ; shl_bug.c 2 mov r2,dpl mov dpl,#0xfe 00101$: I.e. no shift in this case - probably this is a bug in optimization. Best regards, Anton Voloshin mailto:va...@is... |
From: Anton V. <va...@is...> - 2000-03-06 12:16:00
|
Hi all! The following code compiles wrong in sdcc (CVS snapshot of March 6 & 2.1.9Ga): void f(); idata int l; void main() { if (l == 123) f(); } It generates the code: ; switch.c 6 mov r0,#_l cjne @r0,#0x7b,00106$ inc r0 ; Peephole 132 changed ljmp to sjmp ; Peephole 199 optimized misc jump sequence cjne @r0,#0x00,00103$ ; Peephole 201 removed redundant sjmp 00106$: 00107$: lcall _f 00103$: i.e. f() is called if low byte of l is != 123. The problem is in peephole rule 199: replace { cjne %1,%2,%3 sjmp %4 %3: sjmp %5 } by { ; Peephole 199 optimized misc jump sequence cjne %1,%2,%5 sjmp %4 %3: } This rule works incorrectly when we have another jmp to %3. The problem may be solved by adding some more rules to src/mcs51/peeph.def. The patch which does that is attached to this letter. (I have no account to commit to sdcc CVS). But I feel a bit unsure anyway about some rules in peeph.def (including #199). Maybe it would be cool to make it possible to add intelligent rules (i.e. counting reference count to %3 is this case), but i think this will be too slow :( Best regards, Anton Voloshin mailto:va...@is... |
From: Michael H. <mic...@ea...> - 2000-03-06 05:09:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, I'm happy. I cleaned up the generated code a little bit more (up to 185 d/s :), and did a little bit of cleaning to the code generator itself. It passes the dhrystone test KO, and it seems to be OK for the GB as well. In the words of Roy, "Worked twice, ship it!" - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4wzyOUejL3SuzxEgRAi1VAKCY9/NTnWKf691uLGn1P2upb2P2fgCeIdjO 9Ez7Nn8mLIv52JweP1WhCWg= =UTJg -----END PGP SIGNATURE----- |
From: Michael H. <mic...@ea...> - 2000-03-06 01:32:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is slightly off topic, but... I've decided that the dhrystone test only shows whether you have hardware assisted mul/div/block operations or not :) I ran a profiler over sdcc-z80's version of dhry.c, and about 15% of the time is spent in mul, 15% in div, and another 20% in memcpy/strcpy/strcmp. Sigh. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4wwnJUejL3SuzxEgRArssAKCgwDb0BNWrI+tKp7BvuhfiDuGgVQCeJ//z +hZAvA1LQRM9wK8n+ojJ2eQ= =iiQH -----END PGP SIGNATURE----- |
From: Michael H. <mic...@ea...> - 2000-03-06 01:27:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmm. sdcc-mcs51 segfaults when compiling galaxy.c as well, but in a different place. And electric-fence cant find anything... Hmm. I've put a copy of the latest gbdk-lib (libc for the Gameboy + Z80) up on gbdk's sourceforge page which includes a copy of galaxy.c if anyone is intersted. I'm going to have a look at the Z80 port - see if it's broken or not from the work I've been doing on the gb. - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4wwiGUejL3SuzxEgRAtSxAJ9FZ9eU1sUtJ0Cz/selhLdGFEDCOwCgg5uM 70H67nOWth+FCdKGsQBkEXY= =mRqP -----END PGP SIGNATURE----- |
From: Michael H. <mic...@ea...> - 2000-03-05 23:47:11
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > however the fix for "&a[n]" was a little easier the lavaluereq flag > would be incremented On the gb, something like: const unsigned char *film[] = { &door1_tiles[0x0C*0], &door2_tiles[0x0C*0], &door3_tiles[0x0C*0], ... Only sets the first byte. i.e it generates: ld de,#film + 0 ld a,#<(_door1_tiles+0) ld (de),a ld de,#film + 2 ld a,#<(_door1_tiles+0) ld (de),a That was this morning - now I do not know. Also something is trashing memory since this morning - compiling galaxy.c in the gbdk package (theres a tarball on sourceforge under gbdk) segfaults with a corrupted symbol. I dont know whos fault is it yet :) Has anyone seen this before? Is it truly trashed memory? Here is gdb's backtrace: (gdb) backtrace #0 addSet (list=0x20, item=0x8101550) at SDCCset.c:133 #1 0x805c973 in allocIntoSeg (sym=0x20) at SDCCmem.c:250 #2 0x805cb3e in allocGlobal (sym=0x8101550) at SDCCmem.c:363 #3 0x805d501 in allocVariables (symChain=0x8101550) at SDCCmem.c:748 #4 0x8049607 in yyparse () at SDCC.y:128 You can see that sym in (2) is currupted... > in this case fixed it and checked things in ...fixed a couple of other > stuff too. > > s51 is abending with memory fault when I use "-r " option so cannot > use it from the debugger ..looking into this... > > Michael anyplans for a z80 library ..or do you have them separate from > the compiler. The gbdk-lib package on cvs.gbdk.sourceforge.net has support for the z80 as well. I'm not sure how to handle this yet :) We can always hack something together for 2.2.0 or tell them to get the libs seperatly. > I will fix the makefiles for the z80 assembler & linker sothat they > build with .configure .... I'd prefer not to - amost all of the rules are in Makefile.common and are inherieted from there. Using a shared rules file makes the Makefiles more maintainable & cleaner. Blah blah. Trying to release gbdk3-2.92 today - I just have to try and keep up with Sandeep :) - -- Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4wvEOUejL3SuzxEgRAlyVAKCqDuatqrCwMgkjTzExfKwAtWmpxgCfYXAt utjogDc5imd7G6n+jnTJh/o= =ry7K -----END PGP SIGNATURE----- |
From: Sandeep D. <sa...@dd...> - 2000-03-05 23:43:25
|
Hi Michael , > From: "Sandeep Dutta" <sa...@dd...> > > > Downloaded the latest tree & got a clean build ..:-) we are very very > > close. > > i have tried to compile it under cygwin, but i cannot find s51.exe (is it > not compiled ?) > the source was located under c:\usr\local > You have to do >make realclean >./configure >make > BTW Author, in the folder device\examples are some files (cpu_tool.c > cpu_tools.h and main8051.c) i guess the version i posted to thorsten OKR Web > page. these files need to be updated, as they contain some bugs i have > already fixed. one is with buffers for serial rx/tx > 127 bytes. it does not > work with V2.19Ga and the serial buffers get corrupted. maybe this has to do > with the signed/unsigned comparision problem reported from "Dafni & Robert > Berger" a week ago. if anybody can tell me how i can update these files > would be nice. > I forgot to mention you have to use --float-reent option also...the latest tree compiles the libraries okay with the options..but beaware that dhrystone may not run on 8051 because of the severely limited stack space. As for updating the examples please register and obtain an usedid from sourceforge & I will be glad to add you in the developer list so that you can update the files yourself..... Sandeep > > Hope this helps if i haven't done something wrong .... now continuing with > the ethernet schematics .. > > Michael > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/mailman/listinfo/sdcc-devel |