Locating code at a certain address

"The problem arises from your try to use the compiler to do things that are not a compiler's job. Arguably, the error is that the _at_ keyword even exists, not the way it's implemented."

Well, I disagree with this. The Keil compiler is intended to address a specific problem - programming embedded systems. Extensions such as the _at_ keyword are very useful and appropriate in this environment.

Unfortunately your solution is too restrictive - every time the code is modified the linker will probably place the constants at a different address. I would have to modify the utility that merges the constants with the code to read the .map file for each build, I would have to issue the .map file along with each build etc etc, and the possibility of error increases with each step.

Stefan

"The problem arises from your try to use the compiler to do things that are not a compiler's job. Arguably, the error is that the _at_ keyword even exists, not the way it's implemented."

Well, I disagree with this. The Keil compiler is intended to address a specific problem - programming embedded systems. Extensions such as the _at_ keyword are very useful and appropriate in this environment.

Unfortunately your solution is too restrictive - every time the code is modified the linker will probably place the constants at a different address. I would have to modify the utility that merges the constants with the code to read the .map file for each build, I would have to issue the .map file along with each build etc etc, and the possibility of error increases with each step.

Stefan

"...and the possibility of error increases with each step."

Of course my ever-unpopular response (you've heard it all before) is to incorporate software tools (sed, awk, perl, etc.) to automate your build process.

Extensions such as the _at_ keyword are very useful and appropriate in this environment.

Just because a feature is useful doesn't mean it's a good idea to add it. All the more so if the feature isn't strictly necessary to achieve the goal.

The same functionality you get with the rather limited _at_ feature can be had completely without it. You would put the relevant objects into named sections of their own, and then tell the linker that those sections are to be placed at certain absolute addresses. Done.

With that in mind, _at_ is really just syntactic sugar, and, as Jon pointed out in his reply, it's actually not all that sweet sugar, either.

Another thing to keep in mind is that if you insist on a fixed address for your configuration data, that means you put an unmovable obstacle somewhere inside the code memory range. This will result usually in a hole in code space usage, i.e. waste of precious resources --- something I would have guessed would bother you considerably.