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.
How can one locate a table of constants at a certain address in C ?
"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