473,290 Members | 1,861 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,290 software developers and data experts.

Declaring static pointers.

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.
Jun 1 '07 #1
15 2054
On Jun 1, 2:49 pm, edson <e...@eircom.netwrote:
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

Jun 1 '07 #2
Franchie wrote:
>
.... snip ...
>
The pointers are basically glorified numbers which happen to
point to the correct location in ROM where the data is stored.
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.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 1 '07 #3
On Jun 1, 5:55 pm, CBFalconer <cbfalco...@yahoo.comwrote:
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? :D

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.

Jun 1 '07 #4
Franchie wrote, On 01/06/07 17:44:
On Jun 1, 5:55 pm, CBFalconer <cbfalco...@yahoo.comwrote:
>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? :D

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.
>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'?
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
Jun 1 '07 #5
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
--
Flash Gordon
Jun 1 '07 #6
Franchie wrote On 06/01/07 12:44,:
On Jun 1, 5:55 pm, CBFalconer <cbfalco...@yahoo.comwrote:
>>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? :D

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.)
>>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'?
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.

--
Er*********@sun.com
Jun 1 '07 #7
On Jun 1, 7:42 pm, Eric Sosman <Eric.Sos...@sun.comwrote:
Franchie wrote On 06/01/07 12:44,:
On Jun 1, 5:55 pm, CBFalconer <cbfalco...@yahoo.comwrote:
>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? :D
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.)
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...

>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'?

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.

Jun 1 '07 #8
Flash Gordon wrote:
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.
Jun 1 '07 #9
Franchie wrote:
On Jun 1, 2:49 pm, edson <e...@eircom.netwrote:
>>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.
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
Jun 1 '07 #10
Franchie wrote On 06/01/07 15:06,:
On Jun 1, 7:42 pm, Eric Sosman <Eric.Sos...@sun.comwrote:
>>Franchie wrote On 06/01/07 12:44,:
>>>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.


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.

--
Er*********@sun.com

Jun 1 '07 #11
Eric Sosman <Er*********@sun.comwrites:
[...]
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 1 '07 #12
Keith Thompson wrote:
Eric Sosman <Er*********@sun.comwrites:
[...]
> 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!

--
Eric Sosman
es*****@acm-dot-org.invalid
Jun 2 '07 #13

"Franchie" <Fr******************@gmail.comha scritto nel messaggio
news:11**********************@u30g2000hsc.googlegr oups.com...
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.
Jun 2 '07 #14
Army1987 wrote:
"Franchie" <Fr******************@gmail.comha scritto nel messaggio
news:11**********************@u30g2000hsc.googlegr oups.com...
>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.
"I am not a number -- I am a free man!"
-- Number Six

--
Eric Sosman
es*****@acm-dot-org.invalid
Jun 2 '07 #15
"Army1987" <pl********@for.itwrites:
"Franchie" <Fr******************@gmail.comha scritto nel messaggio
news:11**********************@u30g2000hsc.googlegr oups.com...
>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.

Which is as much sense as "Army1987"
Jun 2 '07 #16

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: lou zion | last post by:
hi all, i've got a class that takes a parameterless function pointer as a parameter. i want to store that function pointer in a variable and i'm trying to figure out the syntax. i came up with...
4
by: Ant | last post by:
Hi I'm quite new to C#. I've been playing around with variables declared outside the scope of a method with & without the static keyword. What difference does declaring variables in either fashion...
1
by: Bern McCarty | last post by:
I am using MEC++ in VC 7.1. I had a method on a __gc object that looked like this: __property System::UInt32 get_MyProperty(void) { System::Byte __pin * pinBytes = &m_byteArray; // entire...
5
by: param | last post by:
Declaring struct as static is creating problem with newer version of CC compiler 5.7 in solaris. e.g. static struct new_str { int a; int b; };
4
by: GnG | last post by:
Hello all, Someone posted a similar question a while ago but there was no response. Does anyone know the answer? I have a managed C++ DLL which is used by a C# project. In that DLL, I have...
6
by: Jia | last post by:
Hi all, I have a class foo which has a static vector of pointers of type base class, and a static function to set this vector. #include <iostream> #include <vector> using namespace std;...
4
by: Josefo | last post by:
Hello, is someone so kind to tell me why I am getting the following errors ? vector_static_function.c:20: error: expected constructor, destructor, or type conversion before '.' token...
5
by: Markus Pitha | last post by:
Hello, I have a class "Menu". In this class I declare an object "Controller". Now I have a problem: Controller uses a ctor but I get the value I have to pass later in my program. The only way...
1
by: prisesh26 | last post by:
What is the difference between declaring a member variable as final static and static final? thanks
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: marcoviolo | last post by:
Dear all, I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.