Why IAR produces different code size for Debug and release

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

1. I am using IAR for 8 bit MCU, IAR shared version: 8.3.2.5988

 

2. I have made code optimization and linker optimization settings same for both release and debug.

 

3. IAR by default on these keywords : DEBUG and NDEBUG  in debug and release mode respectively.

 

4. I searched for all the files even back end files but didn't find DEBUG & NDEBUG in my code or any other by default IAR file also.

 

5. But on building with space optimizations settings both have difference code sizes:

a) release:   7 600 bytes of readonly  code memory
    189 bytes of readonly  data memory
    335 bytes of readwrite data memory
    
B) Debug:   7 953 bytes of readonly  code memory
    189 bytes of readonly  data memory
    335 bytes of readwrite data memory    
    
    
6. What is causing so much change in memory?  For 8 bit MCU this is a lot.  

Last Edited: Thu. Aug 6, 2020 - 10:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You paid for the support, so ask IAR!

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

ki0bk wrote:

You paid for the support, so ask IAR!

 

Bad hair day?

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

ki0bk wrote:

You paid handsomely for the support, so ask IAR!

But are you using assert of any kind, they get #ifdef out in release code ?

 

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


 

@kiobk : Using 8KB free version with all the functionalities.  Above 8KB its cost. My MCU has 8KB of flash so no worries.

 

@ N.Winterbottom  No assert used

 

Last Edited: Thu. Aug 6, 2020 - 02:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

Why not write the smallest program possible, compile it, and then look at the generated code?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Vindhyachal Takniki wrote:
@ N.Winterbottom  No assert used

In that case it's almost certain to be IAR C_Library code that makes the difference.

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

But it can also be like GCC's -Os or -O2 for release and -Og for debug.

 

There must be a place in the settings where you can see compiler settings for the two (and change them like no WDT in debug) 

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

Vindhyachal Takniki wrote:
What is causing so much change in memory?
Surely IAR (like GCC) has "binary analysis" tools that can let you explore what is different between " 7 600 bytes of readonly  code memory " and " 7 953 bytes of readonly  code memory " ? I'd start with annotated listing assuming such things are available?

 

But at a guess I wonder if the "Debug" build does things like putting stack frame checks and memory allocation guard bands and stuff in the code that are not there for Release?

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

Vindhyachal Takniki wrote:
Using 8KB free version with all the functionalities

If you're doing a bona fide evaluation - with a genuine interest in purchase - then it would be a reasonable question to ask them and expect a reply from them as part of your evaluation.

 

If you're not intending to purchase - then why even bother? If you're just looking for free tools then, surely, GCC must be the way to go.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

I used to think the debug and release should make same code size or hex file size(at-least in MCU), since debug information stays in debugger control. (of course, until you use some ifdef DEBUG or assert command)

Will check Linker genreated map file of both and check. Since optimization is same in both.

 

@awneil, why not ask? Forum are there for queries no. 

Your replies always amuses me not on my queries but other person posts also. 

Ask urself why bother to reply on this query. Neither me nor this forum wants to pay you?

 

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

We don’t tend to get many people who use IAR for AVR. The IAR tax puts most people off and whilst the IAR compiler is good, it is only somewhat better than gcc.

Vindy, you might want to consider who contributes and who consumes.

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

Kartman wrote:
Vindy, you might want to consider who contributes and who consumes.

Well said.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

First, get a detailed map of both builds.

 

Now, it is "only" 8K, so manual investigation won't be onerous.

 

Lay those maps side-by-side.  What jumps out at you?

 

Library code was mentioned.  That map examination should allow a comparison of the size of each library element.  What does that show?

 

What about other items in the map?  All the same size?

 

What might be left is 5K of a big main().  Big, but not that hard to spend less time than you did com[posing your query finding the differences in the compiler-generated code.  What a short cut?  Go down say 1000.  Still a match?  Then go another 1000.

 

A decent compare program on the code listings can be used.  Watch out for "false hits" if the compiler uses heuristic algorithms -- even successive builds might not be the same.

 

BTW does the toolchain docs lay out differences between debug and release? [My first guess woud be some scaffolding for monitor functions.]

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

awneil wrote:
If you're just looking for free tools then, surely, GCC must be the way to go.

Surely, it isn't THAT obvious.  Maybe for fanboys.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Out of curiosity which other free C compilers are there for the AVR?

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

sparrow2 wrote:

Out of curiosity which other free C compilers are there for the AVR?

Microchips xc8 has a free version

 

Edit: looks like that also gcc, I thought they used clang, but a quick project showed avr-gcc

Last Edited: Fri. Aug 7, 2020 - 05:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Out of curiosity which other free C compilers are there for the AVR?

 

Rust?

https://www.avrfreaks.net/forum/...

 

Platform io I think does AVR and is free.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

LLVM seems to be coming to fruition. 

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

Grannus wrote:
... I thought they used clang, ...
MPLAB XC8 v2 for PIC

 

"Dare to be naïve." - Buckminster Fuller

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

theusch wrote:

awneil wrote:
If you're just looking for free tools then, surely, GCC must be the way to go.

Surely, it isn't THAT obvious.  Maybe for fanboys.

sparrow2 wrote:
Out of curiosity which other free C compilers are there for the AVR?

My point is that it seems to veer into fanboy area to recommend changing horses in the middle of the stream.  If OP has ~8K app and tools installed and operational, and apparently the app working, under what set of criteria can you justify starting with a new toolchain?  A person-month, perhaps?

 

I'd still like OP to run through the checklist I posted, to see where that toolchain changed direction size-wise.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I seem to remember debug and release builds handle memory allocation differently.  I worked on a BIG piece of C++ code that would crash if certain features were accessed in a release build, but would work fine in a debug build, so finding the problem with the debugger was a no go.  Of course, when we put print statements around where the bug appeared to be it would move somewhere else, surely a memory problem.  We ran all kinds of expensive memory checkers and such on it and they never found anything after taking all night to run.  Finally, the bug moved to a part of the code that was very rarely used, and probably lives there still.  Nobody ever figured out what was going on, even the smart guys.  At one point we had to give Intel a debug build, which did what they wanted but was bigger and a little slower than what they were used to from us, and caused problems internal to Intel because they documented code size and parity of the binary or something bizarre, and didn't like it when we changed builds.  But it kept the wafers flowing through the fab, and that was where the money was, so they lived with it.

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


Did linker map file search here are results, left is debug and right is release. Files names are changed to aaa.o (please avoid)

Although compiler and linker optimization are same in both settings . These all aaa.o  files are my added, none of them are by default IAR added though, and in all their C files no DEBUG/NDEBUG I have added.

Checking each now.

 

 

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


I once had a discussion with Keil engineer, he said this though:

 

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

Get yourself a new diff tool - that one's rubbish, why aren't similar lines aligned to each other?

 

Also the summary is no good, you need the extended map showing the address and size of each module the linker has placed.

 

I'm still betting that it's the IAR C-Library that different.

 

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

So take the listing of the generated code for aaaaaa.o and see where the 9 (!) bytes of difference are.

 

As it is an odd number, I'd guess some kind of scaffolding such as routine name or ID.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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


 

 

 

A related question in 2008

https://www.avrfreaks.net/forum/...

 

And others; questions identical to this one?

1. I have made code in IAR which I have attached.

2. I have made same debug & release optimization setting i.e High, Speed, No size constraint.

Surprisingly code generated in both are different even if optimization settings are same even if there is no additional code in debug or release.

3. Code is just:

Code:

#include "stm8s.h"

int main( void )
{
  return 0;
}



4. Size in debug :

read only code memory = 106 bytes

read only data memory = 128 byte

read write data memory = 256 bytes


5. Size in release:

read only code memory = 63 bytes

read only data memory = 128 byte

read write data memory = 256 bytes

...

https://forum.allaboutcircuits.c...

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Sat. Aug 8, 2020 - 01:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


 

 

 

 

https://mcuoneclipse.com/2012/06/01/debug-vs-release/

this is what i thought it should be, debug and release should not make any different in hex code generated for code.  But its different here. will see in listing file.

 

Last Edited: Sat. Aug 8, 2020 - 01:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I already suggested guards bands and stack frame checking. Did you look? As Lee suggests I'd take one of the files where there are discrepancies like aaaaaaa.o that is 1614 versus 1484 and study the specific differences. 

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


response from IAR team.

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

So you had your answer back in #7.