Declaring static pointers.

[edson]

Greetings.
My microcontroller program uses arrays of strings. I want to store the
strings AND their pointers in ROM. I am able to initialize the arrays so
that the strings are put in ROM, but the compiler puts the pointers in
RAM. I would appreciate advice on how to initialize it so that both
pointers and strings are in ROM.

Here is the declaratin I use.

const char *myvariables[] = {"var1", "var2", "vr3", "variable4", "v5"};

Here I find that var1, var2 etc are in ROM but &var1, &var2 etc are in RAM.

Compiler is MSP430-GCC.

Advice appreciated.

 

[Franchie]

Greetings.
My microcontroller program uses arrays of strings. I want to store the
strings AND their pointers in ROM. I am able to initialize the arrays so
that the strings are put in ROM, but the compiler puts the pointers in
RAM. I would appreciate advice on how to initialize it so that both
pointers and strings are in ROM.

Here is the declaratin I use.

const char *myvariables[] = {"var1", "var2", "vr3", "variable4", "v5"};

Here I find that var1, var2 etc are in ROM but &var1, &var2 etc are in RAM.

Compiler is MSP430-GCC.

Advice appreciated.

Surely thats linker/hardware dependant?

The pointers are basically glorified numbers which happen to point to
the correct location in ROM where the data is stored.
The c compiler, however, does not know where these will be stored, as
that is the linkers choice. Thus simply put, the c compiler cannot
place the pointers in ROM.

The only way to get the pointers to be placed in ROM would be to
configure the linker to always place the variables in the correct
place in ROM, at a known address. This can probably be done with a
linker script (most things can). Then simply initialise the pointers
in your code (eg: const char *var1 = (char*)0xaddress ).

However, why do you need to have the pointers in ROM?
Even in your microcontroller setting, couldn't you use relative
addresses?
Alternatively, have a look at the relocation table the linker
produces, you will probably find most things in there...

Hope this helps,
Franchie

 

[Franchie]

You need to get rid of that idea. It may work some places, but not
all. For example, a pointer to my house might be:
"Go down this street two blocks, turn left, go one block,
turn right and it's the 3rd house on the left."
which you may note has a number, in fact several numbers,
directions, etc. It is not a number.

Surely the direction to your house is irrelevant at this point?

However, in the current context, we refer to an address in memory,
typically a *number* of bytes away from a given reference point.
In that sense, what is wrong with saying its a number??

Maybe you are right, though, and this is looking at computing too much
from a hardware standpoint, which is not ideal for high-level
programming.
In defence, the OP was asking about a micro-controller, which is
notoriously close to hardware ;-)

You need to get rid of that idea. It may work some places, but not all.

Just interested... where does the 'pointer = memory address' idea not
work? Isn't that the very definition of 'pointer'?

Thanks,
Franchie.

 

[Flash Gordon]

Franchie wrote, On 01/06/07 17:44:

Surely the direction to your house is irrelevant at this point?

However, in the current context, we refer to an address in memory,
typically a *number* of bytes away from a given reference point.
In that sense, what is wrong with saying its a number??

That fact that pointers are not always a count from a given reference in
*real* hardware.

Maybe you are right, though, and this is looking at computing too much
from a hardware standpoint, which is not ideal for high-level
programming.

It is not even correct for all hardware.

In defence, the OP was asking about a micro-controller, which is
notoriously close to hardware ;-)

Lots of the SW on micro-controllers is not close to the HW, only the
bits doing the actual interfacing are.

Just interested... where does the 'pointer = memory address' idea not
work? Isn't that the very definition of 'pointer'?

The cray vector machine where the high bits of a char or void pointer
indicate which octet in a 64 bit word, any of the x86 series of
processors in a mode where the pointer is segment and offset, and
probably lots of others.

 

[Flash Gordon]

edson wrote, On 01/06/07 13:49:

Greetings.
My microcontroller program uses arrays of strings. I want to store the
strings AND their pointers in ROM. I am able to initialize the arrays so
that the strings are put in ROM, but the compiler puts the pointers in
RAM. I would appreciate advice on how to initialize it so that both
pointers and strings are in ROM.

Here is the declaratin I use.

const char *myvariables[] = {"var1", "var2", "vr3", "variable4", "v5"};

Here I find that var1, var2 etc are in ROM but &var1, &var2 etc are in RAM.

Compiler is MSP430-GCC.

Try declaring the array const as well as what it points to.
const char *const myvariables[] = {"var1", "var2", "vr3", "variable4",
"v5"};

No guarantee it will work, but it is unlikely to work without doing this.

If this does not work I suggest asking on comp.arch.embedded

 

[Eric Sosman]

Franchie wrote On 06/01/07 12:44,:

Surely the direction to your house is irrelevant at this point?

However, in the current context, we refer to an address in memory,
typically a *number* of bytes away from a given reference point.
In that sense, what is wrong with saying its a number??

Maybe you are right, though, and this is looking at computing too much
from a hardware standpoint, which is not ideal for high-level
programming.
In defence, the OP was asking about a micro-controller, which is
notoriously close to hardware ;-)

If anything, the micro-device world is *more* likely
to have addresses that are not simple numbers than is the
world of general-purpose computing. For example, the O.P.
has asked about two distinct kinds of memory with different
behaviors; memory on general-purpose machines is usually
homogeneous. Is there an a priori reason to believe that
these two kinds of memory should be integrated under one
comprehensive addressing scheme? (It appears that they
are so integrated on the O.P.'s machine, but I'm asking
about the logical necessity of such an integration.)

A few examples, some far-fetched but none impossible:

- ROM and RAM might exist in completely different
address spaces, accessed by different instruction
opcodes (perhaps with different timings to allow
for differently-performing memories). The address
0x4242 selects different data depending on whether
it's used in a LOADRAM or a LOADROM instruction.

- The large ROM region uses 32-bit addresses while
the tiny RAM uses 8-bit addresses. Some opcodes
can take advantage of the narrowness of a RAM
address to squeeze it into an instruction word
without using a separate pointer register.

- A system-wide "mode bit" determines whether addresses
in a certain range refer to ROM or to RAM; you can't
tell whether LOADFROM 0x4242 will fetch from ROM or
from RAM until you specify the mode bit's value.
(I once owned a Z80-based machine that used exactly
this scheme.)

Just interested... where does the 'pointer = memory address' idea not
work? Isn't that the very definition of 'pointer'?

There is obviously more to a C pointer than "address:"

double trouble = 42.0;
double *p = &trouble;
void *q = p;
assert (p == q); /* must succeed */
assert (*p == *q); /* doesn't even compile */

Clearly, p and q "point to the same address," yet just as
clearly they are not the same.

 

[Franchie]

Franchie wrote On 06/01/07 12:44,:







If anything, the micro-device world is *more* likely
to have addresses that are not simple numbers than is the
world of general-purpose computing. For example, the O.P.
has asked about two distinct kinds of memory with different
behaviors; memory on general-purpose machines is usually
homogeneous. Is there an a priori reason to believe that
these two kinds of memory should be integrated under one
comprehensive addressing scheme? (It appears that they
are so integrated on the O.P.'s machine, but I'm asking
about the logical necessity of such an integration.)

A few examples, some far-fetched but none impossible:

- ROM and RAM might exist in completely different
address spaces, accessed by different instruction
opcodes (perhaps with different timings to allow
for differently-performing memories). The address
0x4242 selects different data depending on whether
it's used in a LOADRAM or a LOADROM instruction.

- The large ROM region uses 32-bit addresses while
the tiny RAM uses 8-bit addresses. Some opcodes
can take advantage of the narrowness of a RAM
address to squeeze it into an instruction word
without using a separate pointer register.

- A system-wide "mode bit" determines whether addresses
in a certain range refer to ROM or to RAM; you can't
tell whether LOADFROM 0x4242 will fetch from ROM or
from RAM until you specify the mode bit's value.
(I once owned a Z80-based machine that used exactly
this scheme.)

Okay, thanks for the clarification.

One could argue that addressing the 0x4242 (change memory bank, or
equivalent) changes the reference point of the pointer, outside which
the latter ceases to have any physical meaning. But I won't since it
would be pretty futile and irrelevant, and since I think we in fact
agree.

Perhaps I am using the word 'number' too loosely. I meant it as a
series of bits that have a particular significance to the target,
which everything eventually boils down to anyway. So in that respect,
how can a 'pointer' not be such an object? So, sorry for not using a
technical term as rigorously as I should...

There is obviously more to a C pointer than "address:"

double trouble = 42.0;
double *p = &trouble;
void *q = p;
assert (p == q); /* must succeed */
assert (*p == *q); /* doesn't even compile */

Clearly, p and q "point to the same address," yet just as
clearly they are not the same.

Right, a good first year computing course example.
They have the same value (p==q) since they point to the same address,
but are not the same since they are stored in a different part of
memory (*p!=*q), etc...
(just to say I have some vague recollection of that course ;-)).

Thanks for the correction in any case,
Franchie.

 

[edson]

edson wrote, On 01/06/07 13:49:

Greetings.
My microcontroller program uses arrays of strings. I want to store the
strings AND their pointers in ROM. I am able to initialize the arrays
so that the strings are put in ROM, but the compiler puts the pointers
in RAM. I would appreciate advice on how to initialize it so that both
pointers and strings are in ROM.

Here is the declaratin I use.

const char *myvariables[] = {"var1", "var2", "vr3", "variable4", "v5"};

Here I find that var1, var2 etc are in ROM but &var1, &var2 etc are in
RAM.

Compiler is MSP430-GCC.

Try declaring the array const as well as what it points to.
const char *const myvariables[] = {"var1", "var2", "vr3", "variable4",
"v5"};

No guarantee it will work, but it is unlikely to work without doing this.

If this does not work I suggest asking on comp.arch.embedded

Yes. That works alright.
'Thanking you.

 

[edson]

Greetings.
My microcontroller program uses arrays of strings. I want to store the
strings AND their pointers in ROM. I am able to initialize the arrays so
that the strings are put in ROM, but the compiler puts the pointers in
RAM. I would appreciate advice on how to initialize it so that both
pointers and strings are in ROM.

Here is the declaratin I use.

const char *myvariables[] = {"var1", "var2", "vr3", "variable4", "v5"};

Here I find that var1, var2 etc are in ROM but &var1, &var2 etc are in RAM.

Compiler is MSP430-GCC.

Advice appreciated.

Surely thats linker/hardware dependant?

The pointers are basically glorified numbers which happen to point to
the correct location in ROM where the data is stored.
The c compiler, however, does not know where these will be stored, as
that is the linkers choice. Thus simply put, the c compiler cannot
place the pointers in ROM.

The only way to get the pointers to be placed in ROM would be to
configure the linker to always place the variables in the correct
place in ROM, at a known address. This can probably be done with a
linker script (most things can). Then simply initialise the pointers
in your code (eg: const char *var1 = (char*)0xaddress ).

However, why do you need to have the pointers in ROM?

To save RAM. My microcontroller has only 2K of RAM but it has 60K of
flash ROM. Every byte of RAM is precious.

 

[Eric Sosman]

Franchie wrote On 06/01/07 15:06,:

Right, a good first year computing course example.
They have the same value (p==q) since they point to the same address,
but are not the same since they are stored in a different part of
memory (*p!=*q), etc...
(just to say I have some vague recollection of that course ;-)).

Well, what I was *really* hinting at is that a C
pointer contains an important piece of information in
addition to an address or locator: it has a type, and
that's enough to refute "pointer = memory address." In
the example I gave, p holds not only the address of the
variable trouble, but also information about how many
bytes trouble occupies and how they are to be understood.
True, this information is usually not encoded explicitly
in the bits of the p's representation (just as an int
usually doesn't encode its own int-ness), but the type is
present nonetheless, and crucial to the use of the pointer!

By way of contrast, q is C's closest approximation to
a "pure" address: it is a pointer and it carries type
information, but the information for an "incomplete type"
is pretty sketchy, and is not enough to allow the compiler
to figure out how to access the pointed-to data. The
attempt to evaluate *q doesn't produce a value that's
different from *p: it produces a diagnostic message.
This was intended to illustrate that a bare address is
close to useless in C; even a scantily-clad address like
a void* is severely handicapped. A bare address (if you
could get hold of one somehow) would presumably be even
less useful; hence, once again we see that a pointer mus
be more than simply an address.

 

[Keith Thompson]

Well, what I was *really* hinting at is that a C
pointer contains an important piece of information in
addition to an address or locator: it has a type, and
that's enough to refute "pointer = memory address." In
the example I gave, p holds not only the address of the
variable trouble, but also information about how many
bytes trouble occupies and how they are to be understood.
True, this information is usually not encoded explicitly
in the bits of the p's representation (just as an int
usually doesn't encode its own int-ness), but the type is
present nonetheless, and crucial to the use of the pointer!

[...]

Yes, but the C standard uses the term "address" to mean a pointer
value, i.e., an "address" in the C sense includes type information.
See, for example, the unary "&" operator, which yields the address of
its argument.

 

[Eric Sosman]

Well, what I was *really* hinting at is that a C
pointer contains an important piece of information in
addition to an address or locator: it has a type, and
that's enough to refute "pointer = memory address." In
the example I gave, p holds not only the address of the
variable trouble, but also information about how many
bytes trouble occupies and how they are to be understood.
True, this information is usually not encoded explicitly
in the bits of the p's representation (just as an int
usually doesn't encode its own int-ness), but the type is
present nonetheless, and crucial to the use of the pointer!

[...]

Yes, but the C standard uses the term "address" to mean a pointer
value, i.e., an "address" in the C sense includes type information.
See, for example, the unary "&" operator, which yields the address of
its argument.

Yes, but (1) that's a flaw in the Standard and (2) that's
not the sense in which the questioner used "address."

By the way, I'll listen to no counter-arguments about (1).
The use of the word "address" to mean something more than it
had meant for many years before the C Standard or C itself came
along has been and will continue to be the source of exactly the
kind of "an address is just a number so a pointer is just a
number" confusion that besets the questioner. The Standard
should not have hijacked the term, but should have stuck to
"pointer" as the noun for C's construct. I was disappointed
when I saw the word used in a pre-ANSI draft, and I am firmly
resolved to remain disappointed, no matter the odds. Harrumph!

 

[Army1987]

Perhaps I am using the word 'number' too loosely. I meant it as a
series of bits that have a particular significance to the target,
which everything eventually boils down to anyway. So in that respect,
how can a 'pointer' not be such an object? So, sorry for not using a
technical term as rigorously as I should...

This makes as much sense as saying that my first name is
4715952025041661696.

 

[Eric Sosman]

This makes as much sense as saying that my first name is
4715952025041661696.

"I am not a number -- I am a free man!"
-- Number Six

 

[Richard]

This makes as much sense as saying that my first name is
4715952025041661696.

Which is as much sense as "Army1987"