Locating code at a certain address

All this sounds like a discussion on comp.lang.c.moderated this Saturday when a poster asks:

"how does one align a static struct to a 4kb boundry? [sic]"

We get two radically different answers from two renowned C experts:

Dan Pop replies "In standard C, one doesn't."
Jack Klein says "One doesn't, in standard C."

I had to utter a little chuckle. Of course, help was provided on how to do it with the proper elements in a typical toolchain (e.g., assembler, linker, and yes the compiler too -- but with #pragma). In fact, I've got a PowerPC compiler here that has a pragma for specifying special alignment.

Now back to the request of extending the _at_ extension specifically, Jon says "yes, it is on the list of features to add".

Well, kudos to Keil for listening to their customers, but I also have to give kudos to all those customers who solve these kinds of problems day in and day out without the need for language extensions or extended language extensions. At least we won't have this to talk about any longer.

Jon, I have to wonder if this OMF extension could be switched on at the command lines of the compiler and linker, so that for the vast majority of users not requiring the _at_-initializer feature, it would be "transparent".

All this sounds like a discussion on comp.lang.c.moderated this Saturday when a poster asks:

"how does one align a static struct to a 4kb boundry? [sic]"

We get two radically different answers from two renowned C experts:

Dan Pop replies "In standard C, one doesn't."
Jack Klein says "One doesn't, in standard C."

I had to utter a little chuckle. Of course, help was provided on how to do it with the proper elements in a typical toolchain (e.g., assembler, linker, and yes the compiler too -- but with #pragma). In fact, I've got a PowerPC compiler here that has a pragma for specifying special alignment.

Now back to the request of extending the _at_ extension specifically, Jon says "yes, it is on the list of features to add".

Well, kudos to Keil for listening to their customers, but I also have to give kudos to all those customers who solve these kinds of problems day in and day out without the need for language extensions or extended language extensions. At least we won't have this to talk about any longer.

Jon, I have to wonder if this OMF extension could be switched on at the command lines of the compiler and linker, so that for the vast majority of users not requiring the _at_-initializer feature, it would be "transparent".

Jon, I have to wonder if this OMF extension could be switched on at the command lines of the compiler and linker, so that for the vast majority of users not requiring the _at_-initializer feature, it would be "transparent".

Yes, but do we really need to add another command-line directive and checkbox in uVision?

Jon

"Yes, but do we really need to add another command-line directive and checkbox in uVision?"

The alternative being what -- always generating the new OMF51+ format only? Or is it that the command-line (and checkbox) is an idiotic way to support old and new OMF51 formats?

Sorry, I was merely making a suggestion for how to keep developers and tool vendors happy during the 3-5 year catch-up period and not "look like the bad guy". I did not necessarily intend to say "you must use a command line switch", but rather to suggest keeping support for the standard OMF51 format by default so nobody's tools break until they absolutely must have this _at_-initializer thing.

By the way, if you need an example of what an embedded customer/developer is willing to tolerate as far as the number of command-line options, take a look at gcc! :-)

http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Option-Summary.html#Option%20Summary

Dan,

I didn't mean to offend you with that post.

The alternative being what -- always generating the new OMF51+ format only?

New records would only be generated if the _at_ = {x, y, z }; is used. So, if you don't use that, there would be no problems.

If you have an emulator that doesn't support the absolute assignment record...don't use that...#ifdef it out.

GCC sure does have a lot of options. I had to get a GCC port up and running the other day and it took me a while to figure out if I was generating the best code or the worst.

Our compiler option list is starting to look like the GCC option list. The problem is that many users start by setting all kinds of options (without understanding all the ramifications) and that just gets them into trouble. And, that's what I want to avoid.

Jon

"New records would only be generated if the _at_ = {x, y, z }; is used. So, if you don't use that, there would be no problems."

Ah, I see -- excellent, and no need for options.

"If you have an emulator that doesn't support the absolute assignment record...don't use that...#ifdef it out."

Plus, if in emulator does not support that new record type, it's quite likely that a little emulator command script could initialize those memory locations as if they had been initialized during code load.

"GCC sure does have a lot of options. I had to get a GCC port up and running the other day and it took me a while to figure out if I was generating the best code or the worst."

What? You mean it wasn't intuitively obvious? ;-)

"Our compiler option list is starting to look like the GCC option list. The problem is that many users start by setting all kinds of options (without understanding all the ramifications) and that just gets them into trouble. And, that's what I want to avoid."

Absolutely! The presence of new records only if the _at_-initializer is used certainly avoids that. Thanks for sharing your notion of how the OMF51 compatibility issue would be addressed.

/Dan Henry