This is IMHO a compiler error, you should perhaps submit it to the tracker.
The immediate culprit is in what you've not shown, namely the declaration of wiz_write8(), which I'd guess is void wiz_write8(uint16_t, xdata uint8_t); The compiler is thus forced to pass the second parameter in xdata, and the mechanism for that, as you've noticed, breaks the first parameter in dptr; so I'd say you might be able to work this around by passing the second parameter without the __xdata qualifier (eating up potentially direct adressable __data space, though). Jan Waclawek PS. Just a sidenote: the comment in wiz.h:#define Sn_IR(ch) WIZ_SOCK_REG(ch, 0x0002) /* 1 byte */ lies - this is apparently an integer constant (i.e. 16 bit), which MAY be an address of a byte. ----- Original Message --------------- Subject: [Sdcc-user] programmer error or compiler bug? From: Peter Van Epp <[email protected]> Date: Wed, 19 May 2010 20:34:57 -0700 To: [email protected] > I'm trying to move some 8051 code from medium model (where it works) >to small model (where it compiles but doesn't work). I've isolated at least >one error but I'm not sure it it is a compiler error or a programmer error >of some kind. > >types.h:typedef unsigned char SOCKET; > >wiz_config.h:#define WIZ_COMMON_BASE 0x0000 >wiz.h:#define WIZ_SOCK_BASE (WIZ_COMMON_BASE + 0x4000) >wiz.h:#define WIZ_SOCK_SIZE (0x0100) >wiz.h:#define WIZ_SOCK_REG(ch, x) (WIZ_SOCK_BASE + ch * WIZ_SOCK_SIZE + x) >wiz.h:#define Sn_IR(ch) WIZ_SOCK_REG(ch, 0x0002) /* 1 byte */ > >/*---------------------------------------------------------------------------*/ >void wiz_setSn_IR (SOCKET xdata s, uint8 xdata val) >{ > >#if WIZ_USE_INTERRUPT > /* NOTE: If value has Sn_IR_SEND_OK set, > * we must do the write to the hardware! > */ > > vuint8 xdata tmpEA; > >unsigned char xdata buf[20]; > > if (val & Sn_IR_SEND_OK) { >sprintf(buf,"sw%x %x\r\n",s,val); >serial_print(buf); > wiz_write8 (Sn_IR(s), val); /* line 261 in the listing */ > } >... > >compiled with tonites snap (although the results are the same on several >different snaps from the last several weeks) with medium and small, the >gerenerated code is different and in small incorrect: > >"c:/program files/sdcc"/bin/sdcc -c wiz.c --model-medium --fverbose-asm >--i-code-in-asm > > 2793 ; wiz.c:261: wiz_write8 (Sn_IR(s), val); > 2794 ; [--2--56-] ic:21: iTemp15 [k25 > lr2 >1:22 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{const-int register}[r5 r6 ] = iTemp5 >[k10 lr9:21 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int xdata}[r5 r6 ] << 0x8 >{con >st-unsigned-char literal} > 2795 ; genLeftShift > 2796 ; genLeftShiftLiteral > 2797 ; genlshTwo > 0762 8D 06 2798 mov ar6,r5 > 0764 7D 00 2799 mov r5,#0x00 > 2800 ; [--2--56-] ic:22: iTemp16 [k26 > lr2 >2:24 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{const-int register}[r5 r6 ] = >iTemp15 > [k25 lr21:22 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{const-int register}[r5 r6 ] >+ 0x4002 {const-int literal} > 2801 ; genPlus > 2802 ; genPlusIncr > 0766 74 02 2803 mov a,#0x02 > 2804 ; Peephole 236.a used r5 instead of ar5 > 0768 2D 2805 add a,r5 > 0769 FD 2806 mov r5,a > 076A 74 40 2807 mov a,#0x40 > 2808 ; Peephole 236.b used r6 instead of ar6 > 076C 3E 2809 addc a,r6 > 076D FE 2810 mov r6,a > 2811 ; [--2--56-] ic:23: send iTemp16 > [k2 >6 lr22:24 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{const-int register}[r5 r6 >]{argr >eg = 1} > 2812 ; [--2--56-] ic:24: > _wiz_write8_PARM >_2 [k30 lr0:0 so:0]{ ia1 a2p0 re0 rm0 nos0 ru0 dp0}{unsigned-char xdata} := >iTem >p0 [k4 lr4:43 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{unsigned-char xdata}[r2 ] > 2813 ; genAssign > 076E 90s00r5D 2814 mov dptr,#_wiz_write8_PARM_2 > 0771 EA 2815 mov a,r2 > 0772 F0 2816 movx @dptr,a > 2817 ; [--2-----] ic:25: iTemp19 [k31 > lr2 >5:25 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{void fixed} = call _wiz_write8 [k22 >l >r0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{void function ( unsigned-int >xdata >, unsigned-char xdata) fixed} > 2818 ; genCall > 0773 8D 82 2819 mov dpl,r5 > 0775 8E 83 2820 mov dph,r6 > 0777 C0 02 2821 push ar2 > 0779 12s00r5B 2822 lcall _wiz_write8 > 077C D0 02 2823 pop ar2 > > The above code works correctly. However compiled with: > >"c:/program files/sdcc"/bin/sdcc -c wiz.c --fverbose-asm --i-code-in-asm > > 2791 ; wiz.c:261: wiz_write8 (Sn_IR(s), val); > 2792 ; [--2--56-] ic:21: iTemp15 [k25 > lr2 >1:22 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{const-int register}[r5 r6 ] = iTemp5 >[k10 lr9:21 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int xdata}[r5 r6 ] << 0x8 >{con >st-unsigned-char literal} > 2793 ; genLeftShift > 2794 ; genLeftShiftLiteral > 2795 ; genlshTwo > 075D 8D 06 2796 mov ar6,r5 > 075F 7D 00 2797 mov r5,#0x00 > 2798 ; [--2--56-] ic:22: iTemp16 [k26 > lr2 >2:24 so:0]{ ia0 a2p0 re0 rm0 nos0 ru1 dp0}{const-int register} = iTemp15 [k25 >lr >21:22 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{const-int register}[r5 r6 ] + >0x4002 > {const-int literal} > 2799 ; genPlus > 2800 ; genPlusIncr > 0761 74 02 2801 mov a,#0x02 > 2802 ; Peephole 236.a used r5 instead of ar5 > 0763 2D 2803 add a,r5 > 0764 F5 82 2804 mov dpl,a > 0766 74 40 2805 mov a,#0x40 > 2806 ; Peephole 236.b used r6 instead of ar6 > 0768 3E 2807 addc a,r6 > 0769 F5 83 2808 mov dph,a > 2809 ; [--2-----] ic:23: send iTemp16 > [k2 >6 lr22:24 so:0]{ ia0 a2p0 re0 rm0 nos0 ru1 dp0}{const-int register}{argreg = 1} > 2810 ; [--2-----] ic:24: > _wiz_write8_PARM >_2 [k30 lr0:0 so:0]{ ia1 a2p0 re0 rm0 nos0 ru0 dp0}{unsigned-char xdata} := >iTem >p0 [k4 lr4:43 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{unsigned-char xdata}[r2 ] > 2811 ; genAssign > 076B 90s00r5D 2812 mov dptr,#_wiz_write8_PARM_2 > 076E EA 2813 mov a,r2 > 076F F0 2814 movx @dptr,a > 2815 ; [--2-----] ic:25: iTemp19 [k31 > lr2 >5:25 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{void fixed} = call _wiz_write8 [k22 >l >r0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{void function ( unsigned-int >xdata >, unsigned-char xdata) fixed} > 2816 ; genCall > 0770 C0 02 2817 push ar2 > 0772 12s00r5B 2818 lcall _wiz_write8 > > > It doesn't work. It appears the reason is that at line 2804 and 2808 >above the argument values are moved to dpl and dph rather than back to r5 and >r6 as they are in the medium model case. Unfortunatly right after that dptr >is loaded with _wiz_write8_PARM_2 which overwrites the just calculated >parameter value that was saved in dptr with unfortunate results. > So is this a compiler bug that I should be reporting or bad C code >(neither the vendor's programmers or me are particularly good C programmers >and I think I may be the better of the two of us, which is a scary thought >:-)). > >Peter Van Epp > ------------------------------------------------------------------------------ _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
