Re: [avr-gcc-list] Peculiar code size problem
Hello David,
Thank you for your reply. Yes this seem to be the problem Current working
program with delay call size turned out to be 7092 bytes. With your suggestion
of "noinlie" attribute the code is now 7086 bytes. Thank you for your help.
This seems to have solved the problem and also answered my query. This may also
help others who have similar problem. Thanks once again.
Regards,
Nayani
From: David A. Lyons
To: Parthasaradhi Nayani
Cc: "avr-gcc-list@nongnu.org"
Sent: Monday, March 19, 2012 5:46 AM
Subject: Re: [avr-gcc-list] Peculiar code size problem
The smaller size might be making the compiler decide to inline the function at
some call sites where it didn't before. You could experiment with
"-fno-inline-small-functions" (compiler option) and/or
"__attribute__((noinline))" on your function declaration:
void pulse_en (void) __attribute__((noinline));
void pulse_en (void)
{
...
}
Cheers,
--Dave___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Peculiar code size problem
Dear Eric, Yes indeed, the total code bloated, though the function size actually reduced. Perhaps my first post was not clear on this point. I can mail you the entire code, should you wish to see it. Please let me know so I can do the needful. I am wondering as to what this cause is and any method to detect it or at the least prevent code bloat. Thank you for your time. Regards, Nayani From: "Weddington, Eric" Sent: Monday, March 19, 2012 1:44 AM Subject: RE: [avr-gcc-list] Peculiar code size problem Your function pulse_en reduced in size as expected. However, your overall code size increased. Without access to the rest of your code, we cannot tell what causes the overall size increase. Eric___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Peculiar code size problem
The smaller size might be making the compiler decide to inline the function at
some call sites where it didn't before. You could experiment with
"-fno-inline-small-functions" (compiler option) and/or
"__attribute__((noinline))" on your function declaration:
void pulse_en (void) __attribute__((noinline));
void pulse_en (void)
{
...
}
Cheers,
--Dave
On Mar 17, 2012, at 9:17 PM, Parthasaradhi Nayani wrote:
>
> Hi all,
> I am working on an ATMEGA8. Since my code was getting close to 8K, I thought
> I would tweak the code. I have a function listed below
>
> void pulse_en (void)
> {
> set_EN; // Set EN
> _delay_loop_1 (255);
> clr_EN; // clear EN
> _delay_loop_1 (255);
> }
> Since the delay after the "clr" instruction had no meaning, I commented the
> line and compiled the code hoping I would save a couple of bytes. But to my
> surprise the code size increased to 7172 bytes compared to 7148 bytes with
> the function call in place. I looked at the list file and found that the
> function gets shifted to a different location with and without the function
> call. Here are the list file snippets
>
> With the call in place:
>
> 351
>
>
> pulse_en:
> 352 .LFB23:
> 353 .LM47:
> 354 /* prologue: function */
> 355 /* frame size = 0 */
> 356 .LM48:
> 357 0128 C29Asbi 56-32,2
> 358 .LBB80:
> 359 .LBB81:
> 360 .LM49:
> 361 012a 8FEFldi r24,lo8(-1)
> 362 012c 982Fmov r25,r24
> 363 .LVL17:
> 364 /* #APP */
> 365 ; 83
> "c:/winavr-20100110/lib/gcc/../../avr/include/util/delay_basic.h" 1
> 366 012e 9A951: dec r25
> 367 0130 01F4brne 1b
> 368 ; 0 "" 2
> 369 /* #NOAPP */
> 370 .LBE81:
> 371 .LBE80:
> 372 .LM50:
> 373 0132 C298cbi 56-32,2
> 374 .LBB82:
> 375 .LBB83:
> 376 .LM51:
> 377 /* #APP */
> 378 ; 83
> "c:/winavr-20100110/lib/gcc/../../avr/include/util/delay_basic.h" 1
> 379 0134 8A951: dec r24
> 380 0136 01F4brne 1b
> 381 ; 0 "" 2
> 382 .LVL18:
> 383 /* epilogue start */
> 384 /* #NOAPP */
> 385 .LBE83:
> 386 .LBE82:
> 387 .LM52:
> 388 0138 0895ret
>
> Without the call:
> 621 .LFE21:
> 623 .global pulse_en
> 625 pulse_en:
> 626 .LFB23:
> 627 .LM87:
> 628 /* prologue: function */
> 629 /* frame size = 0 */
> 630 .LM88:
> 631 01c2 C29Asbi 56-32,2
> 632 .LBB146:
> 633 .LBB147:
> 634 .LM89:
> 635 01c4 8FEFldi r24,lo8(-1)
> 636 .LVL36:
> 637 /* #APP */
> 638 ; 83
> "c:/winavr-20100110/lib/gcc/../../avr/include/util/delay_basic.h" 1
> 639 01c6 8A951: dec r24
> 640 01c8 01F4brne 1b
> 641 ; 0 "" 2
> 642 /* #NOAPP */
> 643 .LBE147:
> 644
>
>
> .LBE146:
> 645 .LM90:
> 646 01ca C298cbi 56-32,2
> 647 /* epilogue start */
> 648 .LM91:
> 649 01cc 0895ret
>
>
> Will some one please let me know why this is happening? If such is the case,
> perhaps extra code is being generated for other function too.
> I am using: avr-gcc (WinAVR 20100110) 4.3.3
>
> Thank you for your time.
>
> Regards,
> Nayani
>
> ___
> AVR-GCC-list mailing list
> AVR-GCC-list@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Peculiar code size problem
Your function pulse_en reduced in size as expected. However, your
overall code size increased.
Without access to the rest of your code, we cannot tell what causes the
overall size increase.
Eric
> -Original Message-
> From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-
> gcc-list-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of
> Parthasaradhi Nayani
> Sent: Saturday, March 17, 2012 10:17 PM
> To: avr-gcc-list@nongnu.org
> Subject: [avr-gcc-list] Peculiar code size problem
>
>
>
> Hi all,
> I am working on an ATMEGA8. Since my code was getting close to 8K, I
thought I
> would tweak the code. I have a function listed below
>
>
> void pulse_en (void)
> {
> set_EN; // Set EN
> _delay_loop_1 (255);
> clr_EN; // clear EN
> _delay_loop_1 (255);
> }
> Since the delay after the "clr" instruction had no meaning, I
commented the
> line and compiled the code hoping I would save a couple of bytes. But
to my
> surprise the code size increased to 7172 bytes compared to 7148 bytes
with the
> function call in place. I looked at the list file and found that the
function
> gets shifted to a different location with and without the function
call. Here
> are the list file snippets
>
> With the call in place:
>
> 351 pulse_en:
> 352 .LFB23:
> 353 .LM47:
> 354 /* prologue: function */
> 355 /* frame size = 0 */
> 356 .LM48:
> 357 0128 C29A sbi 56-32,2
> 358 .LBB80:
> 359 .LBB81:
> 360 .LM49:
> 361 012a 8FEF ldi r24,lo8(-1)
> 362 012c 982F mov r25,r24
> 363 .LVL17:
> 364 /* #APP */
> 365 ; 83 "c:/winavr-
> 20100110/lib/gcc/../../avr/include/util/delay_basic.h" 1
> 366 012e 9A95 1: dec r25
> 367 0130 01F4 brne 1b
> 368 ; 0 "" 2
> 369 /* #NOAPP */
> 370 .LBE81:
> 371 .LBE80:
> 372 .LM50:
> 373 0132 C298 cbi 56-32,2
> 374 .LBB82:
> 375 .LBB83:
> 376 .LM51:
> 377 /* #APP */
> 378 ; 83 "c:/winavr-
> 20100110/lib/gcc/../../avr/include/util/delay_basic.h" 1
> 379 0134 8A95 1: dec r24
> 380 0136 01F4 brne 1b
> 381 ; 0 "" 2
> 382 .LVL18:
> 383 /* epilogue start */
> 384 /* #NOAPP */
> 385 .LBE83:
> 386 .LBE82:
> 387 .LM52:
> 388 0138 0895 ret
>
> Without the call:
> 621 .LFE21:
> 623 .global pulse_en
> 625 pulse_en:
> 626 .LFB23:
> 627 .LM87:
> 628 /* prologue: function */
> 629 /* frame size = 0 */
> 630 .LM88:
> 631 01c2 C29A sbi 56-32,2
> 632 .LBB146:
> 633 .LBB147:
> 634 .LM89:
> 635 01c4 8FEF ldi r24,lo8(-1)
> 636 .LVL36:
> 637 /* #APP */
> 638 ; 83 "c:/winavr-
> 20100110/lib/gcc/../../avr/include/util/delay_basic.h" 1
> 639 01c6 8A95 1: dec r24
> 640 01c8 01F4 brne 1b
> 641 ; 0 "" 2
> 642 /* #NOAPP */
> 643 .LBE147:
> 644 .LBE146:
> 645 .LM90:
> 646 01ca C298 cbi 56-32,2
> 647 /* epilogue start */
> 648 .LM91:
> 649 01cc 0895 ret
>
>
> Will some one please let me know why this is happening? If such is the
case,
> perhaps extra code is being generated for other function too.
> I am using: avr-gcc (WinAVR 20100110) 4.3.3
>
> Thank you for your time.
>
> Regards,
> Nayani
>
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Peculiar code size problem
Hi all,
I am working on an ATMEGA8. Since my code was getting close to 8K, I thought I
would tweak the code. I have a function listed below
void pulse_en (void)
{
set_EN; // Set EN
_delay_loop_1 (255);
clr_EN; // clear EN
_delay_loop_1 (255);
}
Since the delay after the "clr" instruction had no meaning, I commented the
line and compiled the code hoping I would save a couple of bytes. But to my
surprise the code size increased to 7172 bytes compared to 7148 bytes with the
function call in place. I looked at the list file and found that the function
gets shifted to a different location with and without the function call. Here
are the list file snippets
With the call in place:
351 pulse_en:
352 .LFB23:
353 .LM47:
354 /* prologue: function */
355 /* frame size = 0 */
356 .LM48:
357 0128 C29A sbi 56-32,2
358 .LBB80:
359 .LBB81:
360 .LM49:
361 012a 8FEF ldi r24,lo8(-1)
362 012c 982F mov r25,r24
363 .LVL17:
364 /* #APP */
365 ; 83
"c:/winavr-20100110/lib/gcc/../../avr/include/util/delay_basic.h" 1
366 012e 9A95 1: dec r25
367 0130 01F4 brne 1b
368 ; 0 "" 2
369 /* #NOAPP */
370 .LBE81:
371 .LBE80:
372 .LM50:
373 0132 C298 cbi 56-32,2
374 .LBB82:
375 .LBB83:
376 .LM51:
377 /* #APP */
378 ; 83
"c:/winavr-20100110/lib/gcc/../../avr/include/util/delay_basic.h" 1
379 0134 8A95 1: dec r24
380 0136 01F4 brne 1b
381 ; 0 "" 2
382 .LVL18:
383 /* epilogue start */
384 /* #NOAPP */
385 .LBE83:
386 .LBE82:
387 .LM52:
388 0138 0895 ret
Without the call:
621 .LFE21:
623 .globalpulse_en
625 pulse_en:
626 .LFB23:
627 .LM87:
628 /* prologue: function */
629 /* frame size = 0 */
630 .LM88:
631 01c2 C29A sbi 56-32,2
632 .LBB146:
633 .LBB147:
634 .LM89:
635 01c4 8FEF ldi r24,lo8(-1)
636 .LVL36:
637 /* #APP */
638 ; 83
"c:/winavr-20100110/lib/gcc/../../avr/include/util/delay_basic.h" 1
639 01c6 8A95 1: dec r24
640 01c8 01F4 brne 1b
641 ; 0 "" 2
642 /* #NOAPP */
643 .LBE147:
644 .LBE146:
645 .LM90:
646 01ca C298 cbi 56-32,2
647 /* epilogue start */
648 .LM91:
649 01cc 0895 ret
Will some one please let me know why this is happening? If such is the case,
perhaps extra code is being generated for other function too.
I am using: avr-gcc (WinAVR 20100110) 4.3.3
Thank you for your time.
Regards,
Nayani___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
