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

Thomas Schäfer schaefer at mabel.info
Thu Nov 22 23:12:38 PST 2007


Hi Richard,

it's V7.14B Standard. Will generate the .i file and send you off list.

regards

Richard schrieb:
> 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)
> 
> _______________________________________________
> Icc-avr mailing list
> Icc-avr at imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-avr



More information about the Icc-avr mailing list