Comparing piece of code with and without if statement

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have small piece of code.

    uint8_t current_state;
    //Part1
    if((~PINB & (1<<PB0)) !=0)
    {
        current_state=1;
    }
    //Part2
    current_state=((~PINB & (1<<PB0)) !=0);

In this code, if I comment part1 and uncomment part2, the code size is 4 bytes more than the one if part2 is commented and part1 is uncommented.
I was expecting the other way. What is the reason for this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, what kind  of optimization are you using? And, what compiler???  It is hard to play the mind of the compiler.

A poor compiler might make poor decisions--what is obvious to you may be invisible to a compiler and vice-versa.

 

NOTE---these are not the same code functionality, the first may or may not assign a state, whereas the second example always sets it to something

The first has to only make state equal to 1, whereas the 2nd example  has  to make state equal to 0 or 1 (slightly more work to do?)

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Mon. Sep 13, 2021 - 08:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The way to know the difference is to look at the .lss

 

If I build something like your code (you didn't who enough context to know exactly how it was constructed like the scope of the variable!) then for the first I get:

int main(void)
{
#if 1
    //Part1
    if((~PINB & (1<<PB0)) !=0)
    {
        current_state=1;
    }
#else    
    //Part2
    current_state=((~PINB & (1<<PB0)) !=0);
#endif    
}

results in:

#if 1
    //Part1
    if((~PINB & (1<<PB0)) !=0)
  90:	18 99       	sbic	0x03, 0	; 3
  92:	03 c0       	rjmp	.+6      	; 0x9a <main+0xa>
    {
        current_state=1;
  94:	81 e0       	ldi	r24, 0x01	; 1
  96:	80 93 00 01 	sts	0x0100, r24	; 0x800100 <__DATA_REGION_ORIGIN__>

while the second results in:

    current_state=((~PINB & (1<<PB0)) !=0);
  90:	93 b1       	in	r25, 0x03	; 3
  92:	81 e0       	ldi	r24, 0x01	; 1
  94:	89 27       	eor	r24, r25
  96:	81 70       	andi	r24, 0x01	; 1
  98:	80 93 00 01 	sts	0x0100, r24	; 0x800100 <__DATA_REGION_ORIGIN__>

The difference is clear.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK got it. If currentState is initialized to 0, both code results in same size. Otherwise anyway currentState is undefined. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joneewheelock wrote:

OK got it. If currentState is initialized to 0, both code results in same size. Otherwise anyway currentState is undefined. 

Not true in the code I showed. I deliberately made the variable a global in BSS (to avoid optimization discard) and a side-effect is that it's guaranteed to be initialised to 0. Of course that does involve OTHER code no immediately visible here. In fact:

00000074 <__do_clear_bss>:
  74:	21 e0       	ldi	r18, 0x01	; 1
  76:	a0 e0       	ldi	r26, 0x00	; 0
  78:	b1 e0       	ldi	r27, 0x01	; 1
  7a:	01 c0       	rjmp	.+2      	; 0x7e <.do_clear_bss_start>

0000007c <.do_clear_bss_loop>:
  7c:	1d 92       	st	X+, r1

0000007e <.do_clear_bss_start>:
  7e:	a1 30       	cpi	r26, 0x01	; 1
  80:	b2 07       	cpc	r27, r18
  82:	e1 f7       	brne	.-8      	; 0x7c <.do_clear_bss_loop>

(but you get this for whichever version is used anyway simply as result of the fact that there is a BSS variable at all).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

joneewheelock wrote:

In this code, if I comment part1 and uncomment part2, the code size is 4 bytes more than the one if part2 is commented and part1 is uncommented.
I was expecting the other way. What is the reason for this?

 

What about the slam-dunk obvious answer that immediately came to your mind: different code has different size. End of story. (Not even mentioning that the two versions you presented don't do the same thing).

 

What is wrong with that obvious answer? Why the question?

Dessine-moi un mouton

Last Edited: Mon. Sep 20, 2021 - 05:22 AM