From: Jerome B. <jer...@fr...> - 2001-04-24 21:01:28
|
Hi all, 1- Since Johan's recents changes in SDCCcse.c 1.29, the code below //*************************** struct sA{ unsigned char c1; unsigned char c2; union { struct { unsigned char c11; unsigned char c12; } sBa; struct { unsigned char c21; unsigned char c22; } sBb; } uB; }; volatile xdata struct sA data0; void fn1(void) { data0.uB.sBa.c12 = 0x63; } //*************************** compile like that //*************************** mov a,#0x02 add a,#_data0 mov r2,a ; Peephole 180 changed mov to clr clr a addc a,#(_data0 >> 8) mov r3,a mov a,#0x01 add a,r2 mov dpl,a ; Peephole 180 changed mov to clr clr a addc a,r3 mov dph,a mov a,#0x63 movx @dptr,a //*************************** Before the change the result of compilation was (more efficient): //*************************** mov dptr,#(_data0 + 0x0003) mov a,#0x63 movx @dptr,a //*************************** I propose change below in SDCCcse.c function findCheaperOp, I think it solves this bug with minimum of interference, //*************************** //Old line if (*opp) <--------------------------------------------------------------------- if ((*opp)&&(SPEC_USIGN(operandType (cop))==SPEC_USIGN(operandType (*opp)))) //New line <---------------------------------------------------- { if ((isGlobalInNearSpace (cop) && !isOperandLiteral (*opp)) || isOperandVolatile (*opp, FALSE) ) { *opp = NULL; return 0; } if (cop->key == (*opp)->key) { *opp = NULL; return 0; } if ((*opp)->isaddr != cop->isaddr && IS_ITEMP (cop)) { *opp = operandFromOperand (*opp); (*opp)->isaddr = cop->isaddr; } return 1; } *opp=NULL; // New line <--------------------------------------------------------------------- return 0; //*************************** If you are agree i can commit these changes. 2 - I've noticed some undesired changes in generated code, with last build of sdcc; i don't know exactly when they appear 2.1 - The source below need 2 spill loc rather than one few months ago : code char t1[2][2] = {"a","b"}; xdata char msg[17]; void fn1(void) reentrant { sprintf(msg,"%s",t1[0]); } SDCC creates 2 spill sloc0 and sloc1 register r5,r6,r7 aren't used. First iTemp3 is assigned to register r5,r6,r7 then iTemp5 is assigned to r0, r1. Then, since there isn't enough register, iTemp3 takes a spill, it leads into iTemp5 has to spill too since it uses r0 and r1 and it's a reentrant function then ptr register r0 and r1 are needed. The result is that iTemp3 and iTemp5 take a spill and r5,r6,r7 are free. I don't understand enough the spill algorithm to fix these things safely. (Arround function serialRegAssign in mcs51/ralloc.c) .dumprassgn ---------------------------------------------------------------- _entry($2) : proc _fn1 [k1 lr0:0 so:6]{ ia0 re0 rm0}{function void } iTemp0 [k4 lr3:4 so:0]{ ia0 re0 rm1}{_code * const array of const char }[remat] = &[_t1 [k3 lr0:0 so:0]{ ia0 re0 rm0}{array of array of const char }] iTemp1 [k5 lr4:9 so:0]{ ia0 re0 rm0}{_generic * const char }[r2 r3 r4 ] = (_generic * const char )iTemp0 [k4 lr3:4 so:0]{ ia0 re0 rm1}{_code * const array of const char }[remat] iTemp2 [k7 lr5:6 so:0]{ ia0 re0 rm1}{_code * const const char }[remat] = &[__str_0 [k6 lr0:0 so:0]{ ia0 re0 rm0}{array of const char }] iTemp3 [k8 lr6:10 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc0_1_0}[_fn1_sloc0_1_0] = (_generic * const char )iTemp2 [k7 lr5:6 so:0]{ ia0 re0 rm1}{_code * const const char }[remat] iTemp4 [k10 lr7:8 so:0]{ ia0 re0 rm1}{_far * char }[remat] = &[_msg [k9 lr0:0 so:0]{ ia0 re0 rm0}{array of char }] iTemp5 [k11 lr8:11 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc1_1_0}[_fn1_sloc1_1_0] = (_generic * const char )iTemp4 [k10 lr7:8 so:0]{ ia0 re0 rm1}{_far * char }[remat] push iTemp1 [k5 lr4:9 so:0]{ ia0 re0 rm0}{_generic * const char }[r2 r3 r4 ] push iTemp3 [k8 lr6:10 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc0_1_0}[_fn1_sloc0_1_0] push iTemp5 [k11 lr8:11 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc1_1_0}[_fn1_sloc1_1_0] iTemp6 [k12 lr12:12 so:0]{ ia0 re0 rm0}{int } = call _sprintf [k2 lr0:0 so:0]{ ia0 re0 rm0}{function int } //*************************** 2.2 - The source below : //*************************** if (u&0x04) return 0x20; //*************************** Compile like that: //*************************** mov a,#0x04 anl a,r2 ; Peephole 110 removed ljmp by inverse jump logic jz 00103$ 00106$: mov dpl,#0x20 //*************************** Few months ago the result was a bit more efficient: //*************************** ; Peephole 105 removed redundant mov mov a,r2 ; Peephole 111 removed ljmp by inverse jump logic jnb acc.2,00104$ 00133$: mov dpl,#0x20 //*************************** Regards Jerome |
From: Sandeep D. <sa...@dd...> - 2001-04-24 22:30:10
|
Hi Jerome, I think the fix looks good you can commit it. I will take a look at the other problems you mentioned. Regards Sandeep -----Original Message----- From: sdc...@li... [mailto:sdc...@li...]On Behalf Of Jerome Bessiere Sent: Tuesday, April 24, 2001 2:04 PM To: SDCC-devel Subject: [sdcc-devel]Re: Ignore cast bug and some others Hi all, 1- Since Johan's recents changes in SDCCcse.c 1.29, the code below //*************************** struct sA{ unsigned char c1; unsigned char c2; union { struct { unsigned char c11; unsigned char c12; } sBa; struct { unsigned char c21; unsigned char c22; } sBb; } uB; }; volatile xdata struct sA data0; void fn1(void) { data0.uB.sBa.c12 = 0x63; } //*************************** compile like that //*************************** mov a,#0x02 add a,#_data0 mov r2,a ; Peephole 180 changed mov to clr clr a addc a,#(_data0 >> 8) mov r3,a mov a,#0x01 add a,r2 mov dpl,a ; Peephole 180 changed mov to clr clr a addc a,r3 mov dph,a mov a,#0x63 movx @dptr,a //*************************** Before the change the result of compilation was (more efficient): //*************************** mov dptr,#(_data0 + 0x0003) mov a,#0x63 movx @dptr,a //*************************** I propose change below in SDCCcse.c function findCheaperOp, I think it solves this bug with minimum of interference, //*************************** //Old line if (*opp) <--------------------------------------------------------------------- if ((*opp)&&(SPEC_USIGN(operandType (cop))==SPEC_USIGN(operandType (*opp)))) //New line <---------------------------------------------------- { if ((isGlobalInNearSpace (cop) && !isOperandLiteral (*opp)) || isOperandVolatile (*opp, FALSE) ) { *opp = NULL; return 0; } if (cop->key == (*opp)->key) { *opp = NULL; return 0; } if ((*opp)->isaddr != cop->isaddr && IS_ITEMP (cop)) { *opp = operandFromOperand (*opp); (*opp)->isaddr = cop->isaddr; } return 1; } *opp=NULL; // New line <--------------------------------------------------------------------- return 0; //*************************** If you are agree i can commit these changes. 2 - I've noticed some undesired changes in generated code, with last build of sdcc; i don't know exactly when they appear 2.1 - The source below need 2 spill loc rather than one few months ago : code char t1[2][2] = {"a","b"}; xdata char msg[17]; void fn1(void) reentrant { sprintf(msg,"%s",t1[0]); } SDCC creates 2 spill sloc0 and sloc1 register r5,r6,r7 aren't used. First iTemp3 is assigned to register r5,r6,r7 then iTemp5 is assigned to r0, r1. Then, since there isn't enough register, iTemp3 takes a spill, it leads into iTemp5 has to spill too since it uses r0 and r1 and it's a reentrant function then ptr register r0 and r1 are needed. The result is that iTemp3 and iTemp5 take a spill and r5,r6,r7 are free. I don't understand enough the spill algorithm to fix these things safely. (Arround function serialRegAssign in mcs51/ralloc.c) ..dumprassgn ---------------------------------------------------------------- _entry($2) : proc _fn1 [k1 lr0:0 so:6]{ ia0 re0 rm0}{function void } iTemp0 [k4 lr3:4 so:0]{ ia0 re0 rm1}{_code * const array of const char }[remat] = &[_t1 [k3 lr0:0 so:0]{ ia0 re0 rm0}{array of array of const char }] iTemp1 [k5 lr4:9 so:0]{ ia0 re0 rm0}{_generic * const char }[r2 r3 r4 ] = (_generic * const char )iTemp0 [k4 lr3:4 so:0]{ ia0 re0 rm1}{_code * const array of const char }[remat] iTemp2 [k7 lr5:6 so:0]{ ia0 re0 rm1}{_code * const const char }[remat] = &[__str_0 [k6 lr0:0 so:0]{ ia0 re0 rm0}{array of const char }] iTemp3 [k8 lr6:10 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc0_1_0}[_fn1_sloc0_1_0] = (_generic * const char )iTemp2 [k7 lr5:6 so:0]{ ia0 re0 rm1}{_code * const const char }[remat] iTemp4 [k10 lr7:8 so:0]{ ia0 re0 rm1}{_far * char }[remat] = &[_msg [k9 lr0:0 so:0]{ ia0 re0 rm0}{array of char }] iTemp5 [k11 lr8:11 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc1_1_0}[_fn1_sloc1_1_0] = (_generic * const char )iTemp4 [k10 lr7:8 so:0]{ ia0 re0 rm1}{_far * char }[remat] push iTemp1 [k5 lr4:9 so:0]{ ia0 re0 rm0}{_generic * const char }[r2 r3 r4 ] push iTemp3 [k8 lr6:10 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc0_1_0}[_fn1_sloc0_1_0] push iTemp5 [k11 lr8:11 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc1_1_0}[_fn1_sloc1_1_0] iTemp6 [k12 lr12:12 so:0]{ ia0 re0 rm0}{int } = call _sprintf [k2 lr0:0 so:0]{ ia0 re0 rm0}{function int } //*************************** 2.2 - The source below : //*************************** if (u&0x04) return 0x20; //*************************** Compile like that: //*************************** mov a,#0x04 anl a,r2 ; Peephole 110 removed ljmp by inverse jump logic jz 00103$ 00106$: mov dpl,#0x20 //*************************** Few months ago the result was a bit more efficient: //*************************** ; Peephole 105 removed redundant mov mov a,r2 ; Peephole 111 removed ljmp by inverse jump logic jnb acc.2,00104$ 00133$: mov dpl,#0x20 //*************************** Regards Jerome _______________________________________________ sdcc-devel mailing list sdc...@li... http://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Johan K. <joh...@id...> - 2001-04-25 09:41:20
|
> Since Johan's recents changes in SDCCcse.c 1.29, the code below ... I already reverted that in 1.30, it was really ugly ... > I propose change below in SDCCcse.c function findCheaperOp, I think it > solves this bug with minimum of interference, > if ((*opp)&&(SPEC_USIGN(operandType (cop))==SPEC_USIGN(operandType > (*opp)))) // New line > *opp=NULL; // New line > If you are agree i can commit these changes. That was what I was really looking for. Didn't think it could be that simple. Johan |
From: Johan K. <joh...@id...> - 2001-04-27 15:17:09
|
> The source below : > if (u&0x04) return 0x20; > Compile like that: > mov a,#0x04 > anl a,r2 > ; Peephole 110 removed ljmp by inverse jump logic > jz 00103$ > 00106$: > mov dpl,#0x20 > Few months ago the result was a bit more efficient: > ; Peephole 105 removed redundant mov > mov a,r2 > ; Peephole 111 removed ljmp by inverse jump logic > jnb acc.2,00104$ > 00133$: > mov dpl,#0x20 That is because I removed the "IS_LITERAL(rtype) ||" from ralloc.c:isBitwiseOptimizable() because of: #if 1 // fixed in ralloc.c isBitwiseOptimizable() 20010321 void bug34(unsigned char datain) { datain&=0x39; if (datain) putchar ('1'); else putchar ('0'); } #endif Where datain was changed to a conditional because it was followed by an IFX. I undid the "fix" in isBitwiseOptimizable() and added an extra clause in ralloc.c:packRegisters() that demands that the IFX usage is the only one. I am not yet 100% happy with this, it solves the bug34 case and your optimisation report. The best way would be to test if this icode is used only once for IFX in this block instead of just the next icode. Also I have a feeling this could be done also for IS_ARITHMETIC_OP Regards, Johan |
From: Sandeep D. <sa...@dd...> - 2001-04-29 23:00:31
|
I fixed the register allocation problem that you mentioned. I updated all the ralloc.c files to handle this situation. Sandeep -----Original Message----- From: sdc...@li... [mailto:sdc...@li...]On Behalf Of Jerome Bessiere Sent: Tuesday, April 24, 2001 2:04 PM To: SDCC-devel Subject: [sdcc-devel]Re: Ignore cast bug and some others Hi all, 1- Since Johan's recents changes in SDCCcse.c 1.29, the code below //*************************** struct sA{ unsigned char c1; unsigned char c2; union { struct { unsigned char c11; unsigned char c12; } sBa; struct { unsigned char c21; unsigned char c22; } sBb; } uB; }; volatile xdata struct sA data0; void fn1(void) { data0.uB.sBa.c12 = 0x63; } //*************************** compile like that //*************************** mov a,#0x02 add a,#_data0 mov r2,a ; Peephole 180 changed mov to clr clr a addc a,#(_data0 >> 8) mov r3,a mov a,#0x01 add a,r2 mov dpl,a ; Peephole 180 changed mov to clr clr a addc a,r3 mov dph,a mov a,#0x63 movx @dptr,a //*************************** Before the change the result of compilation was (more efficient): //*************************** mov dptr,#(_data0 + 0x0003) mov a,#0x63 movx @dptr,a //*************************** I propose change below in SDCCcse.c function findCheaperOp, I think it solves this bug with minimum of interference, //*************************** //Old line if (*opp) <--------------------------------------------------------------------- if ((*opp)&&(SPEC_USIGN(operandType (cop))==SPEC_USIGN(operandType (*opp)))) //New line <---------------------------------------------------- { if ((isGlobalInNearSpace (cop) && !isOperandLiteral (*opp)) || isOperandVolatile (*opp, FALSE) ) { *opp = NULL; return 0; } if (cop->key == (*opp)->key) { *opp = NULL; return 0; } if ((*opp)->isaddr != cop->isaddr && IS_ITEMP (cop)) { *opp = operandFromOperand (*opp); (*opp)->isaddr = cop->isaddr; } return 1; } *opp=NULL; // New line <--------------------------------------------------------------------- return 0; //*************************** If you are agree i can commit these changes. 2 - I've noticed some undesired changes in generated code, with last build of sdcc; i don't know exactly when they appear 2.1 - The source below need 2 spill loc rather than one few months ago : code char t1[2][2] = {"a","b"}; xdata char msg[17]; void fn1(void) reentrant { sprintf(msg,"%s",t1[0]); } SDCC creates 2 spill sloc0 and sloc1 register r5,r6,r7 aren't used. First iTemp3 is assigned to register r5,r6,r7 then iTemp5 is assigned to r0, r1. Then, since there isn't enough register, iTemp3 takes a spill, it leads into iTemp5 has to spill too since it uses r0 and r1 and it's a reentrant function then ptr register r0 and r1 are needed. The result is that iTemp3 and iTemp5 take a spill and r5,r6,r7 are free. I don't understand enough the spill algorithm to fix these things safely. (Arround function serialRegAssign in mcs51/ralloc.c) ..dumprassgn ---------------------------------------------------------------- _entry($2) : proc _fn1 [k1 lr0:0 so:6]{ ia0 re0 rm0}{function void } iTemp0 [k4 lr3:4 so:0]{ ia0 re0 rm1}{_code * const array of const char }[remat] = &[_t1 [k3 lr0:0 so:0]{ ia0 re0 rm0}{array of array of const char }] iTemp1 [k5 lr4:9 so:0]{ ia0 re0 rm0}{_generic * const char }[r2 r3 r4 ] = (_generic * const char )iTemp0 [k4 lr3:4 so:0]{ ia0 re0 rm1}{_code * const array of const char }[remat] iTemp2 [k7 lr5:6 so:0]{ ia0 re0 rm1}{_code * const const char }[remat] = &[__str_0 [k6 lr0:0 so:0]{ ia0 re0 rm0}{array of const char }] iTemp3 [k8 lr6:10 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc0_1_0}[_fn1_sloc0_1_0] = (_generic * const char )iTemp2 [k7 lr5:6 so:0]{ ia0 re0 rm1}{_code * const const char }[remat] iTemp4 [k10 lr7:8 so:0]{ ia0 re0 rm1}{_far * char }[remat] = &[_msg [k9 lr0:0 so:0]{ ia0 re0 rm0}{array of char }] iTemp5 [k11 lr8:11 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc1_1_0}[_fn1_sloc1_1_0] = (_generic * const char )iTemp4 [k10 lr7:8 so:0]{ ia0 re0 rm1}{_far * char }[remat] push iTemp1 [k5 lr4:9 so:0]{ ia0 re0 rm0}{_generic * const char }[r2 r3 r4 ] push iTemp3 [k8 lr6:10 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc0_1_0}[_fn1_sloc0_1_0] push iTemp5 [k11 lr8:11 so:0]{ ia0 re0 rm0}{_generic * const char }{ sir@ _fn1_sloc1_1_0}[_fn1_sloc1_1_0] iTemp6 [k12 lr12:12 so:0]{ ia0 re0 rm0}{int } = call _sprintf [k2 lr0:0 so:0]{ ia0 re0 rm0}{function int } //*************************** 2.2 - The source below : //*************************** if (u&0x04) return 0x20; //*************************** Compile like that: //*************************** mov a,#0x04 anl a,r2 ; Peephole 110 removed ljmp by inverse jump logic jz 00103$ 00106$: mov dpl,#0x20 //*************************** Few months ago the result was a bit more efficient: //*************************** ; Peephole 105 removed redundant mov mov a,r2 ; Peephole 111 removed ljmp by inverse jump logic jnb acc.2,00104$ 00133$: mov dpl,#0x20 //*************************** Regards Jerome _______________________________________________ sdcc-devel mailing list sdc...@li... http://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Johan K. <joh...@id...> - 2001-04-30 16:22:47
|
It doesn't work for the ds390. While trying to isolate the problem I noticed a very strange bug.: #include <stdio.h> #include <time.h> void PrintTime (struct tm *rtcTime, char verbose) { if (verbose) { time_t calendarTime = mktime (rtcTime); printf ("Seconds since 00:00:00 Jan 01 1970: %ld\n", calendarTime); } } Both printf-parameters are assigned to the same registers. It happens in both mcs51 and ds390 before and after your fix. Regards, Johan ----- Original Message ----- From: Sandeep Dutta <sa...@dd...> To: <sdc...@li...> Sent: Monday, April 30, 2001 12:54 AM Subject: RE: [sdcc-devel]Re: Ignore cast bug and some others > I fixed the register allocation problem that you mentioned. > I updated all the ralloc.c files to handle this situation. > > Sandeep |
From: Sandeep D. <sa...@dd...> - 2001-04-30 16:53:08
|
Will take look at this 2nite. Johan. Sandeep -----Original Message----- From: sdc...@li... [mailto:sdc...@li...]On Behalf Of Johan Knol Sent: Monday, April 30, 2001 9:23 AM To: sdc...@li... Subject: Re: [sdcc-devel]Re: Ignore cast bug and some others It doesn't work for the ds390. While trying to isolate the problem I noticed a very strange bug.: #include <stdio.h> #include <time.h> void PrintTime (struct tm *rtcTime, char verbose) { if (verbose) { time_t calendarTime = mktime (rtcTime); printf ("Seconds since 00:00:00 Jan 01 1970: %ld\n", calendarTime); } } Both printf-parameters are assigned to the same registers. It happens in both mcs51 and ds390 before and after your fix. Regards, Johan ----- Original Message ----- From: Sandeep Dutta <sa...@dd...> To: <sdc...@li...> Sent: Monday, April 30, 2001 12:54 AM Subject: RE: [sdcc-devel]Re: Ignore cast bug and some others > I fixed the register allocation problem that you mentioned. > I updated all the ralloc.c files to handle this situation. > > Sandeep _______________________________________________ sdcc-devel mailing list sdc...@li... http://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Johan K. <joh...@id...> - 2001-05-01 19:16:38
|
Must have been a long night, or a tough problem, or maybe you just did took a look at it :) ----- Original Message ----- From: Sandeep Dutta <sa...@dd...> To: <sdc...@li...> Sent: Monday, April 30, 2001 6:47 PM Subject: RE: [sdcc-devel]Re: Ignore cast bug and some others > Will take look at this 2nite. Johan. > > Sandeep > > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Johan Knol > Sent: Monday, April 30, 2001 9:23 AM > To: sdc...@li... > Subject: Re: [sdcc-devel]Re: Ignore cast bug and some others > > > It doesn't work for the ds390. While trying to isolate the problem I noticed > a very strange bug.: > > #include <stdio.h> > #include <time.h> > > void PrintTime (struct tm *rtcTime, char verbose) { > if (verbose) { > time_t calendarTime = mktime (rtcTime); > printf ("Seconds since 00:00:00 Jan 01 1970: %ld\n", calendarTime); > } > } > > Both printf-parameters are assigned to the same registers. It happens in > both mcs51 and ds390 before and after your fix. > > Regards, > Johan > > > ----- Original Message ----- > From: Sandeep Dutta <sa...@dd...> > To: <sdc...@li...> > Sent: Monday, April 30, 2001 12:54 AM > Subject: RE: [sdcc-devel]Re: Ignore cast bug and some others > > > > I fixed the register allocation problem that you mentioned. > > I updated all the ralloc.c files to handle this situation. > > > > Sandeep > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Sandeep D. <sa...@dd...> - 2001-05-01 21:10:22
|
Sorry got back home pretty late from work. I think we should undo the last change I did. Will take a look at this ASAP. Sandeep -----Original Message----- From: sdc...@li... [mailto:sdc...@li...]On Behalf Of Johan Knol Sent: Tuesday, May 01, 2001 12:16 PM To: sdc...@li... Subject: Re: [sdcc-devel]Re: Ignore cast bug and some others Must have been a long night, or a tough problem, or maybe you just did took a look at it :) ----- Original Message ----- From: Sandeep Dutta <sa...@dd...> To: <sdc...@li...> Sent: Monday, April 30, 2001 6:47 PM Subject: RE: [sdcc-devel]Re: Ignore cast bug and some others > Will take look at this 2nite. Johan. > > Sandeep > > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Johan Knol > Sent: Monday, April 30, 2001 9:23 AM > To: sdc...@li... > Subject: Re: [sdcc-devel]Re: Ignore cast bug and some others > > > It doesn't work for the ds390. While trying to isolate the problem I noticed > a very strange bug.: > > #include <stdio.h> > #include <time.h> > > void PrintTime (struct tm *rtcTime, char verbose) { > if (verbose) { > time_t calendarTime = mktime (rtcTime); > printf ("Seconds since 00:00:00 Jan 01 1970: %ld\n", calendarTime); > } > } > > Both printf-parameters are assigned to the same registers. It happens in > both mcs51 and ds390 before and after your fix. > > Regards, > Johan > > > ----- Original Message ----- > From: Sandeep Dutta <sa...@dd...> > To: <sdc...@li...> > Sent: Monday, April 30, 2001 12:54 AM > Subject: RE: [sdcc-devel]Re: Ignore cast bug and some others > > > > I fixed the register allocation problem that you mentioned. > > I updated all the ralloc.c files to handle this situation. > > > > Sandeep > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > _______________________________________________ sdcc-devel mailing list sdc...@li... http://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Sandeep D. <sa...@dd...> - 2001-05-02 04:31:38
|
Hi Johan, Fixed and committed , It was actually problem with packForPush, effecting the ds390 & mcs51 ports. The register allocation, should improve with the fix I made previously. Desperately need that regression test suite from Michael. Sandeep -----Original Message----- From: sdc...@li... [mailto:sdc...@li...]On Behalf Of Johan Knol Sent: Tuesday, May 01, 2001 12:16 PM To: sdc...@li... Subject: Re: [sdcc-devel]Re: Ignore cast bug and some others Must have been a long night, or a tough problem, or maybe you just did took a look at it :) ----- Original Message ----- From: Sandeep Dutta <sa...@dd...> To: <sdc...@li...> Sent: Monday, April 30, 2001 6:47 PM Subject: RE: [sdcc-devel]Re: Ignore cast bug and some others > Will take look at this 2nite. Johan. > > Sandeep > > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Johan Knol > Sent: Monday, April 30, 2001 9:23 AM > To: sdc...@li... > Subject: Re: [sdcc-devel]Re: Ignore cast bug and some others > > > It doesn't work for the ds390. While trying to isolate the problem I noticed > a very strange bug.: > > #include <stdio.h> > #include <time.h> > > void PrintTime (struct tm *rtcTime, char verbose) { > if (verbose) { > time_t calendarTime = mktime (rtcTime); > printf ("Seconds since 00:00:00 Jan 01 1970: %ld\n", calendarTime); > } > } > > Both printf-parameters are assigned to the same registers. It happens in > both mcs51 and ds390 before and after your fix. > > Regards, > Johan > > > ----- Original Message ----- > From: Sandeep Dutta <sa...@dd...> > To: <sdc...@li...> > Sent: Monday, April 30, 2001 12:54 AM > Subject: RE: [sdcc-devel]Re: Ignore cast bug and some others > > > > I fixed the register allocation problem that you mentioned. > > I updated all the ralloc.c files to handle this situation. > > > > Sandeep > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > _______________________________________________ sdcc-devel mailing list sdc...@li... http://lists.sourceforge.net/lists/listinfo/sdcc-devel |
From: Johan K. <joh...@id...> - 2001-05-02 15:39:28
|
> Fixed and committed , It was actually problem with packForPush, > effecting the ds390 & mcs51 ports. Confirmed, thanks. > The register allocation, should improve with the fix I made previously. I am sure it does, but for now it disables the ds390 port. The code generator complains about three operands in far space and produces bogus code. Kevin used to be a wizard on that, I hope he is still alive and reads this. > Desperately need that regression test suite from Michael. Yes, but for now, once in a while, I build de device/example/ds390 examples and check if they produce reasonable output. Right now readmac and ow390 won't compile. I will try to isolate the problem Johan |
From: Kevin V. <kv...@lu...> - 2001-05-02 16:55:42
|
On 02-May-2001 Johan Knol wrote: > I hope he is still alive and reads > this. Up to my eyeballs in PowerPC fun (did you know the PowerPC has an eieio instruction? "Enable In-order Execution of I/O"), but still alive. I'm looking at the "3 operands in far space" problem in ownetu.c. Peace, Kevin |
From: Kevin V. <ke...@vi...> - 2001-05-02 20:36:06
|
On 02-May-2001 Kevin Vigor wrote: > I'm looking at the "3 operands in far space" problem in ownetu.c. Fixed; also fixed an invalid code generation problem demonstrated by readmac.c. Peace, Kevin |
From: Johan K. <joh...@id...> - 2001-05-03 11:52:28
|
Hi, Kevin! Nice to have you back! Both the readmac and the ow390 compile again. They do not run however. The problem is that i (sloc6) in the for loop in readmac.c:94 isn't updated after the djnz (the loop is inversed since there is no other usage for i nor a function call). The test in gen.c:ifxForOp() sees an IFX in the next icode and thus returns the IFX. An extra clause: "bitVectnBitsOn(OP_USES(IC_RESULT(ic)))==1 &&", like I did in packRegisters(), seems to fix this. It makes sense to me, but I am not 100% sure. I haven't comitted this yet. Johan ----- Original Message ----- From: Kevin Vigor <ke...@vi...> To: <sdc...@li...> Sent: Wednesday, May 02, 2001 10:36 PM Subject: Re: [sdcc-devel]Re: Ignore cast bug and some others > > On 02-May-2001 Kevin Vigor wrote: > > I'm looking at the "3 operands in far space" problem in ownetu.c. > > Fixed; also fixed an invalid code generation problem demonstrated by > readmac.c. > > Peace, > Kevin > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Kevin V. <kv...@lu...> - 2001-05-03 21:45:47
|
On 03-May-2001 Johan Knol wrote: > The problem is that i (sloc6) in the for loop in readmac.c:94 isn't > updated > after the djnz (the loop is inversed since there is no other usage for > i nor > a function call). I just committed what I think is a better fix for this (fixing ds390/gen.c:genDjnz to properly handle the case of operands that have to accessed indirect via the accumulator). Let me know what you think. Peace, Kevin |
From: Johan K. <joh...@id...> - 2001-05-04 15:03:16
|
> > The problem is that i (sloc6) in the for loop in readmac.c:94 isn't > > updated > > after the djnz (the loop is inversed since there is no other usage for > > i nor > > a function call). > > I just committed what I think is a better fix for this (fixing > ds390/gen.c:genDjnz to properly handle the case of operands that have to > accessed indirect via the accumulator). > > Let me know what you think. It looks great. Thanks. Johan |