How to initialize Absolute variables in code memory?

 How to initialize Absolute variables in code memory?

I am using Keil V7.07 C compiler. Problem Regarding Absolute Variable Initialization.

An Absolute Variable Can be defined as:

unsigned char code xyz _at_ 0xFE01;

A Normal Variable can be initialized as:

unsigned char code xyz = 76;

Is there any possibility that an absolute variable in code memory can be initialized ?? like

unsigned char code xyz _at_ 0xFE01 = 76; OR
unsigned char code xyz = 76 _at_ 0xFE01;

Above both methods are wrong. On Page 104 (C51 Users Guide), it is clearly written that Absolute Variables cannot be initialized. Is there any other way to initialize absolute variables?

 Look in the online manual

http://www.keil.com/support/man/docs/c51/c51_le_absvarloc.htm

There's a link at the bottom of the page that tells you how to do it...

 RE: Look in the online manual

Actually, the link tells you how to initialise an absolutely-located variable:
http://www.keil.com/support/docs/937.htm

What you want is to absolutely-locate an initialised variable - for which you need to follow the link from that article to:
http://www.keil.com/support/docs/301.htm

 RE: Look in the online manual

There is a very, naah extremely simple way to do it in Keil:

do it in assembler

That, of course, sticktolanguagephilia sufferers can not handle.

Erik

 RE: Look in the online manual

There is a very, naah extremely simple way to do it in Keil:

do it with the linker

That, of course, learntousethetoolsphilia sufferers can handle.

 RE: Look in the online manual

do it with the linker
Simple, if you know the tools in detail, if you, like many/most, are relying on the IDE to do your job for you, using assembler is waaaaay less demanding in the respect of "tool knowledge expansion".
You, Mr. smoked sardine, of course, know everything there is to know about the tools and, as such, would, do it (as you feel it is right) with the linker. I, however, would rather do it in assembler, since that keeps everything in the same place (the source file subdirectory). Doing it with the linker, while perfectly legit, put (one) variable(s) outside the place where all other definitions reside.

Erik

 RE: Look in the online manual

Simple, if you know the tools in detail, if you, like many/most, are relying on the IDE to do your job for you, using assembler is waaaaay less demanding in the respect of "tool knowledge expansion".

It's hard to extract much sense from the above sentence, but you seem to be saying that it is easier to learn how to use the assembler than to look in the linker manual to find out how to locate a variable.

I rely on the IDE to do *its* job, which it does very well, not *my* job. I also rely on the linker to do *its* job, which includes locating the position of variables.

You, Mr. smoked sardine, of course, know everything there is to know about the tools

I appreciate the compliment but I actually refer to the manual quite frequently.

Doing it with the linker, while perfectly legit, put (one) variable(s) outside the place where all other definitions reside.

No it doesn't.

 Oh yes it does!

Erik: "Doing it with the linker, while perfectly legit, put (one) variable(s) outside the place where all other definitions reside."

Sprat: "No it doesn't."

Oh yes it does!

One of the biggest problems of IDEs (especially in commercial projects) is documenting the settings that are made through the graphical interface!

I usually end up having to take screenshots!

:-(

Applying change control to IDE project files can also be tricky (uVision isn't too bad, actually).

 RE: Oh yes it does!

Development systems with binary IDE files are pure hell :(

A minimum requirement for an IDE is that 'cvs diff' (or similar for other source versioning systems) should be able to give reasonable feedback about differences to a project.

 RE: Oh yes it does!

Erik: "Doing it with the linker, while perfectly legit, put (one) variable(s) outside the place where all other definitions reside."

Sprat: "No it doesn't."

Oh yes it does!

Ok then, where *does* the variable definition reside?

 RE: Ok then, where *does* the variable definition reside?

This is not just about the "definition" in the source language sense - it's about the complete specification form the overall system perspective.

In effect, you have a "partial" definition in the source code. That definition is sufficient to allow the code to access the variable, but is not sufficient to provide a complete definition from the overall system perspective - in particular, it doesn't tell you either that the specific location of this variable is important, nor what that location is.

Generally, it is "better" (in particular, easier to maintain), if everything about a particular "object" is defined in a single place...

 RE: Ok then, where *does* the variable definition reside?

This is not just about...

<Snip>

So, where *does* the variable definition reside?

 RE: So, where *does* the variable definition reside?

Like I said, the complete definition is split between 2 places:

1. The source code - contains the type & initialisation;

2. The linker directives - set the specific location.

For this particular requirement, neither of these provides a complete definition at the overall system level.

Doing it in assembler could provide a single, complete definition.

 RE: So, where *does* the variable definition reside?

Like I said, the complete definition is split between 2 places:

1. The source code - contains the type & initialisation;

2. The linker directives - set the specific location.

I think you'll find that (1) contains all the imformation associated with any conventional interpretation of the expression 'variable definition'.

For this particular requirement, neither of these provides a complete definition at the overall system level.

The location of a variable is quite dissociated from its definition no matter how you wish to try and dress it up. This all started with an assertion that:

Doing it with the linker, while perfectly legit, put (one) variable(s) outside the place where all other definitions reside.

To which I responded 'No it doesn't'. This seems to me to be a perfectly accurate correction.