This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why does _at_ destroy my pointers

some background code to look at

structure:

typedef struct tMyStruct
{
        DWORD s1;
        BYTE  s2;
} MY_STRUCT;

I have an external variable defined using this structure, Note that it is an array

extern MY_STRUCT xdata Var1[];

and here is the declaration

xdata volatile MY_STRUCT Var1[500];

I use a pointer array of the type MY_STRUCT to access and modify data within the Var1 Array

xdata MY_STRUCT *pVar1[4];

This code works just fine. I have the need now, to Force Var1 to be located at a specific address so I can overlay some other variables (that won't be used at the same time). I read up on using _at_ and declaring space for variables in assembly. and before I started overlaying I changed the declaration of Var1 to this:

xdata volatile MY_STRUCT Var1[500] _at_ (0x100);

The code compiles and runs but does not work properly. for some reason the pointers do not behave as before. If someone could tell me why I shouldn't be able to do this or how to fix it it would be great.

  • "I have the need (sic?) now, to Force Var1 to be located at a specific address so I can overlay some other variables"

    Why do you need to do that?

    Isn't the compiler's own overlaying good enough?

    Couldn't you use a union (or unions) instead?

  • I have solved this issue. After a day and a half of parsing forums, trying alternate coding methods I got it working. Both the _at_ and the Assembly method work. Unfortunately I posted this at the end of "The day and half" but only about a few hours prior to discovering my problem. If I come up with an EXACT cause of this issue I will post, for now the summary below may help someone.

    For some reason when I forced Var1 at an address that was being used by the linker locater to link the pointer array that was being used to point to Var1, it was almost as if the link wasn't happening. I believe (from what I can tell) that this caused the Link to take place after the link of the code that used the pointer, therefore the pointer was not linked to the proper address space or data type within the section of code that actually used it.

    To answer the questions you proposed Andy, for the sake of answering them.

    Why do you need to do that?
    Isn't the compiler's own overlaying good enough?

    I needed to do this because as I am adding functionality/features to existing code and there is no more memory left, and No the compilers overlaying is not good enough to do this on its own.

    Couldn't you use a union (or unions) instead?
    I could have if I were writing the code from the ground up and thought of this situation. But as I did not, I needed something fairly transparent to the current functioning system. Overwriting memory was much easier(granted unsafe) than redefining an entire base of code to create a union of two things that have no relationship to each other.