## Re: [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to icode level

 Re: [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to icode level From: Johan Knol - 2001-02-21 16:02:23 ```I am working on it. geniCodeMultiply could never have worked the way it is, escpessially for signed chars. I am allmost finnished. Johan ----- Original Message ----- From: Sandeep Dutta To: Sent: Wednesday, February 21, 2001 4:56 PM Subject: RE: [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to icode level > Hi Johan > > You are right, the packregs in 8051 patches up the multiply. > I think it will be smart for geniCodeMultiply to fix this up, > since almost all the 8bitters provide 8x8=16 multiplies. > > Sandeep > > -----Original Message----- > From: sdcc-devel-admin@... > [mailto:sdcc-devel-admin@...]On Behalf Of Johan Knol > Sent: Tuesday, February 20, 2001 10:35 AM > To: sdcc-devel@... > Subject: [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to > icode level > > > Since this problem still isn't solved, I have isolated the problem. > > int add(char a, char b) { > return a*b; > } > > produces the following icodes in .dumpraw0 > > proc _add{function unsigned int} > _add_a_1_1{unsigned char} = recv > iTemp1{unsigned char} = _add_a_1_1{unsigned char} + _add_PARM_2{unsigned > char} > iTemp2{unsigned int} = (unsigned int)iTemp1{unsigned char} > ret iTemp2{unsigned int} > > So, iTemp1 is calculated using 8 bit arithmetic > > But fortunately after the iTemp1 is optimized out (in packRegsForOneuse) and > registers are assigned, .dumprassg shows this: > > proc_add{function unsigned int} > iTemp0{unsigned char}{sir@ _add_a_1_1}[r2] = recv > iTemp2{unsigned int}[r2 r3] = iTemp0{unsigned char}{sir@ _add_a_1_1}[r2] + > _add_PARM_2{unsigned char} > ret iTemp [..]{..}{unsigned int}[r2 r3 > > So everything falls back into places and the calculation is done in 16 bit; > in genPlus() "getDataSize(IC_RESULT(ic))==2". > > I don't know if these are really two bugs that fortunately compensate for > each other. > > However, since the ds390 lacks the packRegsForOneuse() iTemp1 isn't > optimized out and indeed 100+200=44 and 100*200=32. > > I hope this helps someone to solve the problem. > > Regards, > Johan > > > > > > _______________________________________________ > sdcc-devel mailing list > sdcc-devel@... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > _______________________________________________ > sdcc-devel mailing list > sdcc-devel@... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > ```

 [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to icode level From: Johan Knol - 2001-02-20 18:34:27 ```Since this problem still isn't solved, I have isolated the problem. int add(char a, char b) { return a*b; } produces the following icodes in .dumpraw0 proc _add{function unsigned int} _add_a_1_1{unsigned char} = recv iTemp1{unsigned char} = _add_a_1_1{unsigned char} + _add_PARM_2{unsigned char} iTemp2{unsigned int} = (unsigned int)iTemp1{unsigned char} ret iTemp2{unsigned int} So, iTemp1 is calculated using 8 bit arithmetic But fortunately after the iTemp1 is optimized out (in packRegsForOneuse) and registers are assigned, .dumprassg shows this: proc_add{function unsigned int} iTemp0{unsigned char}{sir@ _add_a_1_1}[r2] = recv iTemp2{unsigned int}[r2 r3] = iTemp0{unsigned char}{sir@ _add_a_1_1}[r2] + _add_PARM_2{unsigned char} ret iTemp [..]{..}{unsigned int}[r2 r3 So everything falls back into places and the calculation is done in 16 bit; in genPlus() "getDataSize(IC_RESULT(ic))==2". I don't know if these are really two bugs that fortunately compensate for each other. However, since the ds390 lacks the packRegsForOneuse() iTemp1 isn't optimized out and indeed 100+200=44 and 100*200=32. I hope this helps someone to solve the problem. Regards, Johan ```
 RE: [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to icode level From: Sandeep Dutta - 2001-02-21 15:56:48 ```Hi Johan You are right, the packregs in 8051 patches up the multiply. I think it will be smart for geniCodeMultiply to fix this up, since almost all the 8bitters provide 8x8=16 multiplies. Sandeep -----Original Message----- From: sdcc-devel-admin@... [mailto:sdcc-devel-admin@...]On Behalf Of Johan Knol Sent: Tuesday, February 20, 2001 10:35 AM To: sdcc-devel@... Subject: [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to icode level Since this problem still isn't solved, I have isolated the problem. int add(char a, char b) { return a*b; } produces the following icodes in .dumpraw0 proc _add{function unsigned int} _add_a_1_1{unsigned char} = recv iTemp1{unsigned char} = _add_a_1_1{unsigned char} + _add_PARM_2{unsigned char} iTemp2{unsigned int} = (unsigned int)iTemp1{unsigned char} ret iTemp2{unsigned int} So, iTemp1 is calculated using 8 bit arithmetic But fortunately after the iTemp1 is optimized out (in packRegsForOneuse) and registers are assigned, .dumprassg shows this: proc_add{function unsigned int} iTemp0{unsigned char}{sir@ _add_a_1_1}[r2] = recv iTemp2{unsigned int}[r2 r3] = iTemp0{unsigned char}{sir@ _add_a_1_1}[r2] + _add_PARM_2{unsigned char} ret iTemp [..]{..}{unsigned int}[r2 r3 So everything falls back into places and the calculation is done in 16 bit; in genPlus() "getDataSize(IC_RESULT(ic))==2". I don't know if these are really two bugs that fortunately compensate for each other. However, since the ds390 lacks the packRegsForOneuse() iTemp1 isn't optimized out and indeed 100+200=44 and 100*200=32. I hope this helps someone to solve the problem. Regards, Johan _______________________________________________ sdcc-devel mailing list sdcc-devel@... http://lists.sourceforge.net/lists/listinfo/sdcc-devel ```
 Re: [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to icode level From: Johan Knol - 2001-02-21 16:02:23 ```I am working on it. geniCodeMultiply could never have worked the way it is, escpessially for signed chars. I am allmost finnished. Johan ----- Original Message ----- From: Sandeep Dutta To: Sent: Wednesday, February 21, 2001 4:56 PM Subject: RE: [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to icode level > Hi Johan > > You are right, the packregs in 8051 patches up the multiply. > I think it will be smart for geniCodeMultiply to fix this up, > since almost all the 8bitters provide 8x8=16 multiplies. > > Sandeep > > -----Original Message----- > From: sdcc-devel-admin@... > [mailto:sdcc-devel-admin@...]On Behalf Of Johan Knol > Sent: Tuesday, February 20, 2001 10:35 AM > To: sdcc-devel@... > Subject: [sdcc-devel]100+200=44 and 100*200=32 problem stripped down to > icode level > > > Since this problem still isn't solved, I have isolated the problem. > > int add(char a, char b) { > return a*b; > } > > produces the following icodes in .dumpraw0 > > proc _add{function unsigned int} > _add_a_1_1{unsigned char} = recv > iTemp1{unsigned char} = _add_a_1_1{unsigned char} + _add_PARM_2{unsigned > char} > iTemp2{unsigned int} = (unsigned int)iTemp1{unsigned char} > ret iTemp2{unsigned int} > > So, iTemp1 is calculated using 8 bit arithmetic > > But fortunately after the iTemp1 is optimized out (in packRegsForOneuse) and > registers are assigned, .dumprassg shows this: > > proc_add{function unsigned int} > iTemp0{unsigned char}{sir@ _add_a_1_1}[r2] = recv > iTemp2{unsigned int}[r2 r3] = iTemp0{unsigned char}{sir@ _add_a_1_1}[r2] + > _add_PARM_2{unsigned char} > ret iTemp [..]{..}{unsigned int}[r2 r3 > > So everything falls back into places and the calculation is done in 16 bit; > in genPlus() "getDataSize(IC_RESULT(ic))==2". > > I don't know if these are really two bugs that fortunately compensate for > each other. > > However, since the ds390 lacks the packRegsForOneuse() iTemp1 isn't > optimized out and indeed 100+200=44 and 100*200=32. > > I hope this helps someone to solve the problem. > > Regards, > Johan > > > > > > _______________________________________________ > sdcc-devel mailing list > sdcc-devel@... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > _______________________________________________ > sdcc-devel mailing list > sdcc-devel@... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > ```