Declaring static pointers.

Discussion in 'C Programming' started by edson, Jun 1, 2007.

  1. edson

    edson Guest

    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.
    edson, Jun 1, 2007
    #1
    1. Advertising

  2. edson

    Franchie Guest

    On Jun 1, 2:49 pm, edson <> wrote:
    > 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, Jun 1, 2007
    #2
    1. Advertising

  3. edson

    Franchie Guest

    On Jun 1, 5:55 pm, CBFalconer <> wrote:
    > 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.
    Franchie, Jun 1, 2007
    #3
  4. edson

    Flash Gordon Guest

    Franchie wrote, On 01/06/07 17:44:
    > On Jun 1, 5:55 pm, CBFalconer <> wrote:
    >> 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
    Flash Gordon, Jun 1, 2007
    #4
  5. edson

    Flash Gordon Guest

    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
    Flash Gordon, Jun 1, 2007
    #5
  6. edson

    Eric Sosman Guest

    Franchie wrote On 06/01/07 12:44,:
    > On Jun 1, 5:55 pm, CBFalconer <> wrote:
    >
    >>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.

    --
    Eric Sosman, Jun 1, 2007
    #6
  7. edson

    Franchie Guest

    On Jun 1, 7:42 pm, Eric Sosman <> wrote:
    > Franchie wrote On 06/01/07 12:44,:
    >
    >
    >
    > > On Jun 1, 5:55 pm, CBFalconer <> wrote:

    >
    > >>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.
    Franchie, Jun 1, 2007
    #7
  8. edson

    edson Guest

    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.
    edson, Jun 1, 2007
    #8
  9. edson

    edson Guest

    Franchie wrote:
    > On Jun 1, 2:49 pm, edson <> wrote:
    >
    >>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
    >
    edson, Jun 1, 2007
    #9
  10. edson

    Eric Sosman Guest

    Franchie wrote On 06/01/07 15:06,:
    > On Jun 1, 7:42 pm, Eric Sosman <> wrote:
    >
    >>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.

    --
    Eric Sosman, Jun 1, 2007
    #10
  11. Eric Sosman <> writes:
    [...]
    > 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) <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"
    Keith Thompson, Jun 1, 2007
    #11
  12. edson

    Eric Sosman Guest

    Keith Thompson wrote:
    > Eric Sosman <> writes:
    > [...]
    >> 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
    lid
    Eric Sosman, Jun 2, 2007
    #12
  13. edson

    Army1987 Guest

    "Franchie" <> ha scritto nel messaggio
    news:...
    > 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.
    Army1987, Jun 2, 2007
    #13
  14. edson

    Eric Sosman Guest

    [OT] Re: Declaring static pointers.

    Army1987 wrote:
    > "Franchie" <> ha scritto nel messaggio
    > news:...
    >> 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
    lid
    Eric Sosman, Jun 2, 2007
    #14
  15. edson

    Richard Guest

    "Army1987" <> writes:

    > "Franchie" <> ha scritto nel messaggio
    > news:...
    >> 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"
    Richard, Jun 2, 2007
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brandon
    Replies:
    2
    Views:
    476
    Arne Adams
    Aug 8, 2004
  2. Steve Lambert

    declaring array of pointers

    Steve Lambert, Sep 18, 2004, in forum: C Programming
    Replies:
    8
    Views:
    351
    Al Bowers
    Sep 19, 2004
  3. param
    Replies:
    5
    Views:
    321
    Jack Klein
    Jan 15, 2006
  4. Replies:
    1
    Views:
    478
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    651
Loading...

Share This Page