Why can't symbols defined with _at_ be initialised!?

"I think your question is of no importance."

Take a look back through the last year's posts - you'll see that it's been asked at least half a dozen times. I think it was important to them, and to all the others who worked it out for themselves without ever asking on this forum.

"Is it really that difficult to initialize whatever you want at the start of your program?"

It is if you want your constants in CODE!!
But why should you have to do this, when the Compiler handles all other initialisations automatically!?

Excuse me, I couldn't imagine it was so hard for you to have an initializing block in your code. Probably, a little practice will help.
M.

An unusual way of intruducing yourself :-))
That's why I try to think twice before posting messages.

I obviously wasn't clear when I said, "...if you want your constants in CODE!!"

What I meant was that your suggestion cannot be used if the initialisations are required in the 8051's CODE memory space - because there is no instruction to write to CODE space! (it's normally ROM)

I think one of the previous posts which asked this question did actually give a reason. I can't remember for sure, but it might've been that they wanted a "signature" in the ROM at a known location?

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