Jump to content
Sign in to follow this  
harrt

Boostc 6.31 Garbage Code Generation

Recommended Posts

6.31 generates this garbage

 

if(eerd(i) != ~i) {

0050 082B MOVF eetest_00000_1_i, W

0051 00AE MOVWF eerd_00000_arg_a

0052 2029 CALL eerd_00000

0053 01AD CLRF CompTempVar10

0054 092B COMF eetest_00000_1_i, W

0055 00AC MOVWF CompTempVar9

0056 09AD COMF CompTempVar10, F

0057 0828 MOVF CompTempVarRet0, W

0058 062C XORWF CompTempVar9, W

0059 1903 BTFSC STATUS,Z

005A 082D MOVF CompTempVar10, W

005B 1903 BTFSC STATUS,Z

005C 285F GOTO label268435774

005F label268435774

 

AUTOI_LED = 1;

005D 1707 BSF gbl_AUTOI_LED,6

 

} else {

005E 2860 GOTO label268435778

0060 label268435778

 

AUTOI_LED = 0;

005F 1307 BCF gbl_AUTOI_LED,6

 

eerd returns unsigned char and i is unsigned char.

 

If the result of the XORWF comparison is zero it loads CompTempVar10 which is always 0xff so the second BTFSC always skips regardless of the comparison result.

Share this post


Link to post
Share on other sites
6.31 generates this garbage...

 

I don't see any error here. The result of ~i gets promoted to 16 bits and because i is unsigned char the high byte of the result is always 0xFF. Can you provide sample value of i and return value of eerd which you think give wrong result?

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
6.31 generates this garbage...

 

The result of ~i gets promoted to 16 bits

 

 

Why is this done? both arguments are unsigned char. I would expect like for like comparison.

Would this be done if the ~ operator was not used?

Share this post


Link to post
Share on other sites
6.31 generates this garbage...

 

The result of ~i gets promoted to 16 bits

 

 

Why is this done? both arguments are unsigned char. I would expect like for like comparison.

Would this be done if the ~ operator was not used?

 

Because this is how C works. Try similar code on any "big" compiler like MSVC++ or GCC and you'll see that the result of the ~ operation gets promoted.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
Because this is how C works. Try similar code on any "big" compiler like MSVC++ or GCC and you'll see that the result of the ~ operation gets promoted.

 

Regards,

Pavel

 

Sorry for quoting the bit about garbage, it was unintentional, I guess my cut and paste scissors need sharpening.

 

I've just looked through some code, it seems strange that other bitwise operations dont promote.

Would it be possible to have some pragma to turn this off?

Share this post


Link to post
Share on other sites
Because this is how C works. Try similar code on any "big" compiler like MSVC++ or GCC and you'll see that the result of the ~ operation gets promoted.

 

Regards,

Pavel

 

Had a look in the standard

 

It seems this is what happens with unary operators

 

quoting from ISO/IEC 9899

 

6.5.3.3 Unary arithmetic operators

 

4 The result of the ~ operator is the bitwise complement of its (promoted) operand (that is,

each bit in the result is set if and only if the corresponding bit in the converted operand is

not set). The integer promotions are performed on the operand, and the result has the

promoted type. If the promoted type is an unsigned type, the expression ~E is equivalent

to the maximum value representable in that type minus E.

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