• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 21 subscribers
  • Views 1067 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Compiles & links differently only the 1st time...?!

Dave S.

I have a C16x project that exhibits a behaviour that I don't understand. Basically, if I un-archive a project into an empty subdirectory and do a "build all" I get a certain HEX file. However, all subsequent times I do a "build all" (without changing anything) I get a different HEX file. In other words, 2 HEX files from the same project. The process is very repeatable. Anyone have a clue as to why that might be? I'm not using anything that I know of that might cause a difference (such as using __TIME__ or __DATE__), and it's just different after the first build (it's always the same for the 2nd and subsequent builds).

Confused...
Dave.

Parents
  • 0 in reply to Andrew Neil

    Thanks everyone! Unchecking the "Global Register Colorization" checkbox on the compiler tab of the project options has given us the ability to create the same HEX file after every build (of the same code). I'm a little puzzled as to why the tools would think that one build was okay but another was better. Isn't functional (i.e., fits in memory and runs) okay? Are the extra runs of parts of the tools to get even faster & smaller executable code? Makes me wonder if it might be useful for the user to have the ability to enter options similar to board layout tools where the tools would run until a user defined point of diminishing returns was met (such as a min percentage of reduction in either size or speed, etc.). Just a comment... the prospect of not being able to [easily] recreate a HEX file from the source code is unsettling to me. I'm quite relieved now that we can repeatedly, reliably recreate the same HEX file from the same project. Thanks again!

Reply
  • 0 in reply to Andrew Neil

    Thanks everyone! Unchecking the "Global Register Colorization" checkbox on the compiler tab of the project options has given us the ability to create the same HEX file after every build (of the same code). I'm a little puzzled as to why the tools would think that one build was okay but another was better. Isn't functional (i.e., fits in memory and runs) okay? Are the extra runs of parts of the tools to get even faster & smaller executable code? Makes me wonder if it might be useful for the user to have the ability to enter options similar to board layout tools where the tools would run until a user defined point of diminishing returns was met (such as a min percentage of reduction in either size or speed, etc.). Just a comment... the prospect of not being able to [easily] recreate a HEX file from the source code is unsettling to me. I'm quite relieved now that we can repeatedly, reliably recreate the same HEX file from the same project. Thanks again!

Children
  • 0 in reply to Dave S.

    I'm quite relieved now that we can repeatedly, reliably recreate the same HEX file from the same project.

    Note, however, that different versions of Keil tools will most likely generate different code. So if you need to be able to rebuild the same HEX file after a while, you will have to use the same version of the Keil toolchain.

    Regards,
    Mike.

  • 0 in reply to Dave S.

    "Are the extra runs of parts of the tools to get even faster & smaller executable code?"

    Yes. It's an iterative process; and it can actually make quite a big difference.

    See my earlier explanation for how it comes to be different on the 1st build only.