Well, we've just had another question about initialising constant data defined with _at http://www.keil.com/forum/docs/thread1162.asp This is a very frequently-asked question, which begs the further question, "why can't symbols defined with _at_ be initialised??" After all, there's obviously a lot of people out there wanting to do it. I gather that the Raisonance compiler does allow this. http://www.8052.com/forum/read.phtml?id=13182&top=
Typically I'd use a small A51 file that declared an absolutely located segment, and db the required data in place. Of course, this _should_ be possible in C; I'm not sure of the reason for this particular limitation.
"Of course, this _should_ be possible in C" No, it should not! The allocation of absolute addresses is not the job of a Compiler - it is the Linker's job (or, strictly, the Locator's job - but the functions are commonly combined these days).
"The allocation of absolute addresses is not the job of a Compiler - it is the Linker's job (or, strictly, the Locator's job - but the functions are commonly combined these days)." I couldn't care less if my cat has to do it as long as it can be done. This _at_ with initialisers issue rumbles on and on. It seems like the most frequently asked question on the forum and is therefore presumably the most desired missing feature in Keil. Come on Keil, when are you going to implement it? Stefan
I was trying to think up reason why you want to declare constants at absolute locations This feature would be convenient for any shared constant created by an external program. For example, you might have a CRC over your code. You might also some sort of table of calibration constants or control parameters, which have default values (built into the code), but known locations so it's easy to update them with a flash programmer without having to rebuild the code. You might have some sort of version / product identification string read by another device. All such problems have solutions (thoroughly discussed on the forum). But while you can object "you can do it some other way", that overlooks the fact that _at_ itself is a mere convenience extension. You might not expire without being able to have _at_ and an initializer, but you wouldn't expire without _at_ at all. Given that _at_ exists, though, it's annoying to have a half-implemented feature. I'd rather have "long long" support, though (along with some other C99 features). Or better control over object placement within segments. Or a better interface for managing projects with multiple results (libraries and executables) in uVision. Or a "medium" memory model where auto variables and temporaries go into overlaid data, and file scope and statics go into xdata, by default.
"But while you can object "you can do it some other way", that overlooks the fact that _at_ itself is a mere convenience extension." Indeed, but given the fact that Keil is a tool for programming in an embedded environment it is a very appropriate extension. Just the sort of thing one would expect to find in such an implementation of 'C'. There have to be non-portable and/or hardware specific features to make the embedded 'C' compiler useable - otherwise we'd have to code the majority of projects in assembler. We need to be able to do in 'C' pretty much anything that can be achieved in assembler. "Given that _at_ exists, though, it's annoying to have a half-implemented feature." Oh yes. Oh yes indeed. Stefan