Jump to content
Sign in to follow this  
wally

Increment Char[] As Long

Recommended Posts

Hello,

i have SB V 6.32 and i'm trying to increment some of the elements of a char[] as they are a double. My code is:

 

char buff[0x20];

void main()
{

buff[0]++;
long *plong = buff + 8;
while (true)
{
	(*plong)++;
}
}

 

I was expecting that incrementing (*plong) i get the bytes buff[8] to buff[11] incremented as they are a long, but that's not working.

 

The compiled code is the following:

 

char buff[0x20];

void main()

{

buff[0]++;
0003  1283 	 BCF STATUS, RP0
0004  1303 	 BCF STATUS, RP1
0005  0AA0 	 INCF gbl_buff, F

long *plong = buff + 8;
0006  3000 	 MOVLW HIGH(gbl_buff+D'0')
0007  00C1 	 MOVWF main_1_plong+D'1'
0008  3020 	 MOVLW LOW(gbl_buff+D'0')
0009  00C2 	 MOVWF CompTempVar52
000A  3008 	 MOVLW 0x08
000B  0742 	 ADDWF CompTempVar52, W
000C  00C0 	 MOVWF main_1_plong
000D  1803 	 BTFSC STATUS,C
000E  0AC1 	 INCF main_1_plong+D'1', F
000F        label268436481

while (true)
002A  280F 	 GOTO	label268436481

{
	(*plong)++;
000F  1383 	 BCF STATUS,IRP
0010  1841 	 BTFSC main_1_plong+D'1',0
0011  1783 	 BSF STATUS,IRP
0012  0840 	 MOVF main_1_plong, W
0013  0084 	 MOVWF FSR
0014  0A80 	 INCF INDF, F
0015  1D03 	 BTFSS STATUS,Z
0016  281A 	 GOTO	label268436486
0017  0A84 	 INCF FSR, F
0018  0A80 	 INCF INDF, F
0019  0384 	 DECF FSR, F
001A        label268436486
001A  1D03 	 BTFSS STATUS,Z
001B  2821 	 GOTO	label268436487
001C  0A84 	 INCF FSR, F
001D  0A84 	 INCF FSR, F
001E  0A80 	 INCF INDF, F
001F  0384 	 DECF FSR, F
0020  0384 	 DECF FSR, F
0021        label268436487
0021  1D03 	 BTFSS STATUS,Z
0022  280F 	 GOTO	label268436481
0023  0A84 	 INCF FSR, F
0024  0A84 	 INCF FSR, F
0025  0A84 	 INCF FSR, F
0026  0A80 	 INCF INDF, F
0027  0384 	 DECF FSR, F
0028  0384 	 DECF FSR, F
0029  0384 	 DECF FSR, F

}
}

 

Is there an error in my code?

 

Thank's,

 

Walter

Share this post


Link to post
Share on other sites

wally,

 

Its not a problem in you code, but a compiler issue in BoostC V6.32.

Incremement 32bit data through a pointer only increments the low 16bits.

 

BTW: Whats happened to your avatar, it used to look like a nice robot arm, now to me it looks a blur.

 

Regards

Dave

Share this post


Link to post
Share on other sites
wally,

 

Its not a problem in you code, but a compiler issue in BoostC V6.32.

Incremement 32bit data through a pointer only increments the low 16bits.

 

BTW: Whats happened to your avatar, it used to look like a nice robot arm, now to me it looks a blur.

 

Regards

Dave

 

Perfect, so i'm not getting crazy ;) . Do you plan to fix this little issue in the next release?

 

My new avatar is a picture of one of my RC planes that now is 'dead' :) .

I have to take a picture better than this since it is not really nice.

 

Thank's,

 

Walter

Share this post


Link to post
Share on other sites

We don't plan to change this compiler behaviour. The reason why only the low 8 bits of a pointer get changed is because of the limitation that an object (like variable or array) must fit into one bank. This way compiler generates very efficient code.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
We don't plan to change this compiler behaviour. The reason why only the low 8 bits of a pointer get changed is because of the limitation that an object (like variable or array) must fit into one bank. This way compiler generates very efficient code.

 

Regards,

Pavel

 

Ok, so this is not exactly an issue but a "working way" of the compiler. I think that this is not completely correct because i was expecting to have a certain code, and i obtained a different one. By the way, do you think that a solution will be to implement an inline assembly function doing that?

 

Thak you,

 

Walter

Share this post


Link to post
Share on other sites

Wally,

 

We don't plan to change this compiler behaviour. The reason why only the low 8 bits of a pointer get changed is because of the limitation that an object (like variable or array) must fit into one bank. This way compiler generates very efficient code.
This is not actually the problem.

The problem is not changing the pointer value, but the value of what it points at.

 

Ok, so this is not exactly an issue but a "working way" of the compiler. I think that this is not completely correct because i was expecting to have a certain code, and i obtained a different one. By the way, do you think that a solution will be to implement an inline assembly function doing that?
Any solution will probably not make it into the next release at that is very close.

 

Regards

Dave

Share this post


Link to post
Share on other sites
We don't plan to change this compiler behaviour. The reason why only the low 8 bits of a pointer get changed is because of the limitation that an object (like variable or array) must fit into one bank. This way compiler generates very efficient code.

 

I want to correct myself as I misunderstood the problem. My comments are valid for pointer changes but when an object accessed trough a pointer gets changes there should be no limitations. I will review and work on this problem.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
I want to correct myself as I misunderstood the problem. My comments are valid for pointer changes but when an object accessed trough a pointer gets changes there should be no limitations. I will review and work on this problem.

 

Perfect.

 

Any solution will probably not make it into the next release at that is very close.

 

No problem, a little workaround will solve the problem for the moment.

 

Thank's,

 

Walter

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...