[Icc-avr] Possible bug with post-increment?

Richard richard-lists at imagecraft.com
Thu Nov 22 11:22:42 PST 2007


Thomas, what version is this? Help->About tells. If it is a late version V7,

introduce an error at the end of this file, e.g. add
         foo
to the end. Then build and the compiler will 
leave the file <file>.i in the Output Directory. 
Send the .i file to me offlist and I will take a look at it.

It's a known bug in V6 as noted in the readme 
file, but it should be fixed now...

At 05:59 AM 11/22/2007, Thomas Schäfer wrote:
>Hi all,
>
>after a two day debug session, I think I have found a bug:
>
>I have a module global array of unsigned char and an index variable. I post
>increment the index while write access to the array, but it seem to pre
>increment the index.
>
>Here are some snippets of the code and the assembler listing:
>
>----
>static volatile unsigned char *ucASCIIBuf = 
>ucBinaryBuf; // Reuse binary buffer
>static volatile unsigned int usBufferPos;
>
>
>void writeBuffer(unsigned char value)
>{
>         ucASCIIBuf[usBufferPos++] |= value;
>}
>
>----
>.lst
>
>(0253)                 ucASCIIBuf[usBufferPos++] |= ucResult;
>      77A 9180 0167 LDS  R24,ascii.c:usBufferPos
>      77C 9190 0168 LDS  R25,ascii.c:usBufferPos+1
>      77E 9601      ADIW R24,1
>      77F 9390 0168 STS  ascii.c:usBufferPos+1,R25
>      781 9380 0167 STS  ascii.c:usBufferPos,R24
>      783 9020 0133 LDS  R2,ascii.c:ucASCIIBuf
>      785 9030 0134 LDS  R3,ascii.c:ucASCIIBuf+1
>      787 9040 0167 LDS  R4,ascii.c:usBufferPos
>      789 9050 0168 LDS  R5,ascii.c:usBufferPos+1
>      78B 0C42      ADD  R4,R2
>      78C 1C53      ADC  R5,R3
>      78D 01F2      MOVW R30,R4
>      78E 8020      LDD  R2,Z+0
>      78F 282C      OR   R2,R12
>      790 8220      STD  Z+0,R2
>
>
>If I explizit increment the index, everything works fine:
>
>----
>static volatile unsigned char *ucASCIIBuf = 
>ucBinaryBuf; // Reuse binary buffer
>static volatile unsigned int usBufferPos;
>
>
>void writeBuffer(unsigned char value)
>{
>         ucASCIIBuf[usBufferPos] |= value;
>         usBufferPos++;
>}
>
>----
>.lst
>
>(0253)                 ucASCIIBuf[usBufferPos] |= ucResult;
>      77A 9020 0133 LDS  R2,ascii.c:ucASCIIBuf
>      77C 9030 0134 LDS  R3,ascii.c:ucASCIIBuf+1
>      77E 9040 0167 LDS  R4,ascii.c:usBufferPos
>      780 9050 0168 LDS  R5,ascii.c:usBufferPos+1
>      782 0C42      ADD  R4,R2
>      783 1C53      ADC  R5,R3
>      784 01F2      MOVW R30,R4
>      785 8020      LDD  R2,Z+0
>      786 282C      OR   R2,R12
>      787 8220      STD  Z+0,R2
>(0254)                          usBufferPos++;
>      788 9180 0167 LDS  R24,ascii.c:usBufferPos
>      78A 9190 0168 LDS  R25,ascii.c:usBufferPos+1
>      78C 9601      ADIW R24,1
>      78D 9390 0168 STS  ascii.c:usBufferPos+1,R25
>      78F 9380 0167 STS  ascii.c:usBufferPos,R24
>
>----
>
>I use V7.14B standard.
>
>regards,
>Thomas
>
>_______________________________________________
>Icc-avr mailing list
>Icc-avr at imagecraft.com
>http://dragonsgate.net/mailman/listinfo/icc-avr

// richard (This email is for mailing lists. To 
reach me directly, please use richard at imagecraft.com) 




More information about the Icc-avr mailing list