I am kind of confused about using the _at_ keyword to assign a specific address to a variable.
so for example :
extern xdata char variable _at_ 0x000f;
it fills 3 bytes in xram . can any one explain how is the compiler handling these sequence. Thank you !
Are you sure that line of code is exactly what you are compiling?
It seems neither of you read the manual and realized the glaring mistake.
BTW it fills 3 bytes in xram is definitely wrong, but not the issue
Erik
Ok, I give up. What is the glaring mistake?
the _at_ must be in the declaration of the variable, not in an extern ref, that does not make whatever module the variable is in know where to put it
ohhhhhhh... i think i found my mistake, i will test my code in the morning.. and i'll let you know. Thanks alot !
That's quite a common newbie misunderstanding of 'extern'.
I suggest that you consult a proper 'C' reference (preferably the standard) and learn what 'extern' actually means. You could just compile the above code and fire up your debugger instead, but you wouldn't really learn anything that way.
Actually, putting the _at_ in the extern usually is a mistake - because the extern usually should be just a declaration and not the definition
Before WW3 erupts again, I decided to see what it gives with the ARM's RealView compiler.
Inserting this declaration,
extern int variable __attribute__((__at(0x8000))) ;
Generated this warning:
main.c(315): warning: #1207-D: attribute "__at" ignored
(variable is defined somewhere else). So, Jack, this is so much according to the standard, how come the compiler generates a warning?
The extern keyword is part of the standard.
The __at keyword is not.
So when you combine the two, the combination will not be part of the standard. In this, I agree with Erik. People should not push their luck too much.
Another important thing is that embedded compilers (besides regularly adding non-standard features to better map to the processor and embedded use) are notorious for being less standards-compliant than "PC compilers". This comes for the much smaller customer base. Less people to catch bugs and design oops. But also often less resources to maintain the compiler.
M$ has a way larger budget to keep their compilers updated. And their track record still shows how hard they have had with standards compliance.
Why should "the standard" contain any information on how a C compiler handles non-standard extensions?
i found my mistake, it is as you've just said, i used the _at_ in a extern declaration. I'm a newbie and i have alot to learn. Thank you all !!
...that does not make whatever module the variable is in know where to put it
Despite your protestation, Jack, it seems that Erik was right this time around. Have you noticed the warning generated by the RealView compiler?
Despite your protestation, Jack, it seems that Erik was right this time around.
Let's look at what he actually said:
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.
not in an extern ref
Wrong - the example given isn't an 'extern ref'.
that does not make whatever module the variable is in know where to put it
Wrong - the toolchain knows exactly where to put it.
Have you noticed the warning generated by the RealView compiler?
Your use of a compiler extension in a compiler I am not familiar with is entirely your own problem. I suggest you check the compiler documentation.
'extern' is not a non-standard extension. It's probably better if you don't snip away the context like that.
'extern' is not a non-standard extension.
Come on. You know that I was not referring to extern.
It's probably better if you don't snip away the context like that.
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?