assign an absolute memory location

I think the sardine should change his monniker to Nit Pick

extern xdata char variable _at_ 0x000f;
the _at_ must be in the declaration of the variable
Wrong - it must be in the definition of the variable, as it is in the example given.
1) definition/declaration can be found as synonyms in any crossword handbook.
2) an extern is NOT a definition, it is a reference

not in an extern ref
Wrong - the example given isn't an 'extern ref'.
if tha example is not an external reference what is it then?

that does not make whatever module the variable is in know where to put it
Wrong - the toolchain knows exactly where to put it.
obviously it does not.

Erik

"1) definition/declaration can be found as synonyms in any crossword handbook."

C, however, makes a distinction between the two:

c-faq.com/.../decldef.html

"1) definition/declaration can be found as synonyms in any crossword handbook."

But, as already noted, we are not talking about crossword puzzles!
We are talking about the 'C' programming language, where the terms have specific, distinct meanings - and a thorough understanding of the distinction is key to this thread!

"2) an extern is NOT a definition, it is a reference"

No, it is not a reference, it is a declaration

I stand corrected re verbiage; however the reason I stated for the problem (extern combined with _at_) was correct and the OP changed accordingly and now states "it works".

Erik

'extern' is not a non-standard extension.

Come on. You know that I was not referring to extern.

Yes, but equally you know that I was not referring to __at__.

The context says that Erik should compile a line that contains not just one, but two blindingly obvious non-standard keywords and look at the resulting assembly, and that he would find the explanation for the results in "the standard".

Yes. The code posted does not behave the way he thinks it does, this is because of is his misunderstanding of 'extern'.

"Warning--A message emitted by a compiler to try and convince the programmer that some program construct is likely confusing, wrong, or dangerous. Because of the serious nature of warnings, most compilers have a provision to turn most of them off. The rest typically go to /dev/null."

Yes, but equally you know that I was not referring to __at__.

You were referring to a declaration that contains non-standard keywords, and basically by definition the standard cannot describe what the compiler should do with such a line.

Interestingly enough, the compiler documentation contains detailed examples on how to define variables using the _at_ keyword, and how to use these variables in a different source file than they were declared in.

You were referring to a declaration that contains non-standard keywords, and basically by definition the standard cannot describe what the compiler should do with such a line.

You are missing the point. The issue in hand is that the 'extern' keyword, when applied to a variable definition, does not make it an "extern ref".

Interestingly enough, the compiler documentation contains detailed examples on how to define variables using the _at_ keyword, and how to use these variables in a different source file than they were declared in.

I should hope the manual documents the usage of all non-standard extensions.

I stand corrected re verbiage

Thank goodness for that.

however the reason I stated for the problem (extern combined with _at_) was correct and the OP changed accordingly and now states "it works".

Well actually, the problem reported was this:

it fills 3 bytes in xram

And you replied:

it fills 3 bytes in xram is definitely wrong, but not the issue

Yet you are now claiming it was intended as a fix for the issue. Can you explain?

when the mistake is glaring, I usually provide a hint rather than a solution (I know that a hint will lead to better understanding if the asker work on the hint), then when both the OP and you gave up I posted

the _at_ must be ... not in an extern

and, amazing to you, I am sure, the 3 byte issue disappeared

Erik

Jack, Erik,
I need to apologize to you. My posted test above was wrong in the sense that when using the RealView compiler, one should make the declaration like this:

extern int variable __attribute__((at(0x8000))) ;

and not like the original version, which was

extern int variable __attribute__((__at(0x8000))) ;

when the first one is used - no warning is generated!