Jump to content
Sign in to follow this  
twomers

Xoring Bug?

Recommended Posts

Hi there,

 

I believe I've found a bug in SourceBoost. I am generating parity bits and obviously began debugging before downloading to a PIC. However, the parity bits that I calculated by hand did not compare with the ones that SourceBoost showed in the debugger. I am using preprocessor functions to do the parity generation but just for debugging these I made a regular function to monitor whether it was my calculations which were wrong. Anyway, here is a snap-shot of the dubugging process. On the right is the watch window where you can see the packet that I'm transmitting and the individual bits that I'm XORing. There are two 1's and 5 0's so the expected result of the XORing would be 0. However it is given as 1. Here is some source demonstrating the error:

#include <system.h>

#pragma DATA _CONFIG, _PWRTE_OFF & _WDT_OFF & _HS_OSC & _CP_OFF

//Set clock frequency
#pragma CLOCK_FREQ  4000000

char get_p1( unsigned int packet ) {
 bit a, b, c, d, e, f, g;
 a = packet.2;
 b = packet.5;
 c = packet.6;
 d = packet.9;
 e = packet.10;
 f = packet.13;
 g = packet.14;
 bool xored = a^b^c^e^f^g;
 return xored; // I put a break point here.
}

void main( void )
 unsigned int packet = 86;

 while( true ) {
get_p1( 0x56 );
 }
}

 

Now, I haven't been able to download this to a PIC to see if it is just a debugging error. I'm using a PIC16F876. If someone has the time it would be much appreciated if they could test it. However, and it's more efficient, this does work as expected:

#define GET_P1(packet) \
 packet.1  = 0;		 \
 packet.1 ^= packet.2;  \
 packet.1 ^= packet.5;  \
 packet.1 ^= packet.6;  \
 packet.1 ^= packet.9;  \
 packet.1 ^= packet.10; \
 packet.1 ^= packet.13; \
 packet.1 ^= packet.14;

post-3919-1202561286_thumb.jpg

Share this post


Link to post
Share on other sites
Hi there,

 

I believe I've found a bug in SourceBoost. I am generating parity bits and obviously began debugging before downloading to a PIC. However, the parity bits that I calculated by hand did not compare with the ones that SourceBoost showed in the debugger. I am using preprocessor functions to do the parity generation but just for debugging these I made a regular function to monitor whether it was my calculations which were wrong. Anyway, here is a snap-shot of the dubugging process. On the right is the watch window where you can see the packet that I'm transmitting and the individual bits that I'm XORing. There are two 1's and 5 0's so the expected result of the XORing would be 0. However it is given as 1. Here is some source demonstrating the error:

#include <system.h>

#pragma DATA _CONFIG, _PWRTE_OFF & _WDT_OFF & _HS_OSC & _CP_OFF

//Set clock frequency
#pragma CLOCK_FREQ  4000000

char get_p1( unsigned int packet ) {
 bit a, b, c, d, e, f, g;
 a = packet.2;
 b = packet.5;
 c = packet.6;
 d = packet.9;
 e = packet.10;
 f = packet.13;
 g = packet.14;
 bool xored = a^b^c^e^f^g;
 return xored; // I put a break point here.
}

void main( void )
 unsigned int packet = 86;

 while( true ) {
get_p1( 0x56 );
 }
}

 

It would appear that a^b^c^e^f^g is compiling to something like ( a^b ) |c|e|f|g.

 

Orin.

Edited by Orin

Share this post


Link to post
Share on other sites

Also, another bug report, for the editor only, though:

//  packet.15 ^= packet.0;  \
 packet.15 ^= packet.1;  \
 packet.15 ^= packet.3;  \
 packet.15 ^= packet.7;  \

That's all highlighted in green. The \ that one might use for #define preprocessor stuff has the same effect in comments. However errors are flagged when compiling.

Share this post


Link to post
Share on other sites

This was a compiler bug when incorrect code was generated for XOR operation between bit and non-bit operands. Now fixed. Fix will be available in the coming release. Thanks for reporting.

 

Regards,

Pavel

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...