CCS :: View topic - MOVLF xC5 putting to wrong xC5

FAQ

Forum Help

Official CCS Support

Profile Log in to check your private messages Log in

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

MOVLF xC5 putting to wrong xC5

CCS Forum Index -> General CCS C Discussion

View previous topic :: View next topic

Author

Message

object01

Joined: 13 May 2004
Posts: 90
Location: Nashville, TN

MOVLF xC5 putting to wrong xC5

Posted: Tue May 10, 2005 4:49 pm

This line,

Code:

parserState = opcode;

compiles to

Code:

3D64: MOVLW 04
3D66: MOVWF xC5

.

(opcode is the 5th member of an enum)

The symbol map shows parserState at location 0x0C5. But instead, 0x6C5 is getting assigned the value 4. I can't imagine that this is anything other than a compiler bug, but I don't know how to go about working around it. Truthfully, I don't know enough about indirect addressing to be able to spot the problem.

Any suggestions?

--
Jeff S.

object01

Joined: 13 May 2004
Posts: 90
Location: Nashville, TN


Posted: Tue May 10, 2005 4:57 pm

(ok, so I got the subject line wrong...)

PCM programmer

Joined: 06 Sep 2003
Posts: 21708


Posted: Tue May 10, 2005 5:00 pm

Post a program that we can compile. Post your compiler version.

object01

Joined: 13 May 2004
Posts: 90
Location: Nashville, TN

Posted: Tue May 10, 2005 5:02 pm

PCM programmer wrote:

Post a program that we can compile. Post your compiler version.

I knew you were gonna say that.

I can't reproduce the problem yet using anything other than the ginormous program in question. If I trim it down the problem goes away. My compiler version is 3.223. I'll try reproducing it in something postable.

--
Jeff S.

object01

Joined: 13 May 2004
Posts: 90
Location: Nashville, TN

Posted: Tue May 10, 2005 7:48 pm

It's still tough to get this into a smaller, compilable program, but I found a workaround. The variables stopPoint and i are both unsigned int8.

Here's the listing of the erroneous section:

Code:

.................... // This line caused a compiler bug in PIC-C version 3.223.
.................... // The line below, parserState = opcode, was setting the
.................... // incorrect location in RAM due to a missing MOVLB instruction.
.................... // The compiler moved one value into the BSR to perform this line,
.................... // then didn't reset it to the proper value afterwards.
.................... // Splitting this statement into two lines made the compiler
.................... // execute another MOVLB instruction before the
.................... // parserState = opcode line.
.................... stopPoint = strlen(&(tdif->buffer[i])) + i;
383E: CLRF 03
3840: MOVF xCA,W
3842: ADDLW 7C
3844: MOVWF 01
3846: MOVLW 00
3848: ADDWFC 03,F
384A: MOVF 01,W
384C: MOVLB 5
384E: ADDWF xA4,W
3850: MOVLB 6
3852: MOVWF xA8
3854: MOVLB 5
3856: MOVF xA5,W
3858: ADDWFC 03,W
385A: MOVLB 6
385C: MOVWF xA9
385E: MOVWF xAC
3860: MOVFF 6A8,6AB
3864: MOVLB 0
3866: CALL 2D28
386A: MOVFF 01,6A9
386E: MOVF xCA,W
3870: MOVLB 6
3872: ADDWF 01,W
3874: MOVWF 01
3876: MOVLW 00
3878: ADDWFC 02,W
387A: MOVFF 01,CB
....................
.................... //stopPoint = strlen(&(tdif->buffer[i]));
.................... //stopPoint += i;
....................
.................... // Output one delimiter on next call
.................... outputDelimiter = TRUE;
387E: BSF 20.1
....................
.................... parserState = opcode;
3880: MOVLW 04
3882: MOVWF xC5

And here's the workaround. Breaking apart the stopPoint statement seemed to reintroduce the necessary MOVLB instruction.

Code:

.................... // This line caused a compiler bug in PIC-C version 3.223.
.................... // The line below, parserState = opcode, was setting the
.................... // incorrect location in RAM due to a missing MOVLB instruction.
.................... // The compiler moved one value into the BSR to perform this line,
.................... // then didn't reset it to the proper value afterwards.
.................... // Splitting this statement into two lines made the compiler
.................... // execute another MOVLB instruction before the
.................... // parserState = opcode line.
.................... //stopPoint = strlen(&(tdif->buffer[i])) + i;
....................
.................... stopPoint = strlen(&(tdif->buffer[i]));
383C: CLRF 03
383E: MOVF xCA,W
3840: ADDLW 7C
3842: MOVWF 01
3844: MOVLW 00
3846: ADDWFC 03,F
3848: MOVF 01,W
384A: MOVLB 5
384C: ADDWF xA4,W
384E: MOVLB 6
3850: MOVWF xA8
3852: MOVLB 5
3854: MOVF xA5,W
3856: ADDWFC 03,W
3858: MOVLB 6
385A: MOVWF xA9
385C: MOVWF xAC
385E: MOVFF 6A8,6AB
3862: MOVLB 0
3864: CALL 2D28
3868: MOVFF 01,CB
.................... stopPoint += i;
386C: MOVF xCA,W
386E: ADDWF xCB,F
....................
.................... // Output one delimiter on next call
.................... outputDelimiter = TRUE;
3870: BSF 20.1
....................
.................... parserState = opcode;
3872: MOVLW 04
3874: MOVWF xC5

Hopefully this might lend some insight into the problem. I'm gonna continue to try and get something more concise and compilable, now that I know what's causing the problem. However, it's important to note that this code used to work. Only after recently making a set of changes to separate source files in the project did it exhibit this problem.

--
Jeff S.

Display posts from previous:

	CCS Forum Index -> General CCS C Discussion	All times are GMT - 6 Hours
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum