Local variables (even if designated as xdata) are in code space

I think you're mixing up where the pointer is (most likely in data space) with where it points to (xdata).

The pointer at hand is uninitalized, and has automatic storage, so its value is random garbage. It's impossible to derive any useful conclusion from where it might seem to point.

I think you're mixing up where the pointer is (most likely in data space) with where it points to (xdata).

The pointer at hand is uninitalized, and has automatic storage, so its value is random garbage. It's impossible to derive any useful conclusion from where it might seem to point.

Thanks Hans,
I don't believe it's an issue with misunderstanding the location of the pointer versus the target of the pointer. I've verified that I actually get incorrect behavior (pulling 0s rather than the expected data) when I declare the pointer within a function rather than as a global.

Thanks,
Chris

But the pointer you've shown is, as already noted, uninitialised!
Therefore its behaviour is undefined, which means that anything goes - there is no such thing as "incorrect" here.

I didn't post the actual code, which does initialize the pointer. I still don't know why the compiler would place the location of the actual pointer variable (NOT the target) in code space. As I've mentioned, using a global produces the correct behavior while a local does not. Here is, essentially, the actual code:

#define BASE 0x1000

void blah (unsigned char Offset)
{ unsigned char xdata *Address; Address = (BASE + Offset);

DATA1 = *(Address+3); DATA2 = *(Address+2); DATA3 = *(Address+1);
}

"essentially" is meaningless!

Unless it's the real code, copied & pasted from a genuine, compilable source, who knows what apparently "insignificant" changes you might have introduced in the translation...?!

Please note the instructions on how to post source code:
www.danlhenry.com/.../keil_code.png
and remember to check it in the 'Preview'

I verified that the code I posted reproduces the issue. It's not the code from my program, as I can't post that code here. Reposting with the proper formatting...

#define BASE 0x1000

void blah (unsigned char Offset)
{
        unsigned char xdata *Address;
        Address = (BASE + Offset);
        SPXB_MSTR_DATA1 = *(Address+3);
        SPXB_MSTR_DATA2 = *(Address+2);
        SPXB_MSTR_DATA3 = *(Address+1);
}

.

There you go again erik. Looking into that assembly.

.

(I was being sarcastic... remember? from a thread where some ppl didn't think looking into the underlying assembly was 'needed')

I knew that, but the eaters of fried pigeons that flew in through the window would not

Erik

It appears to be an issue with pointer + fixed offset. If I actually modify the pointer instead, I get the correct behavior. Though I still can't inspect the pointer or its target. I think that's due to optimizations, which is fairly reasonable. I'll respond again if I find out more.

Thanks all.

So, have you looked at the generated assembler code?

A lot of compilers would ignore your pointer variable, and just evaluate the real address for the individual memory accesses - all depending on how good the processor is at doing pointer manipulation.

In this case, it is porbably as cheap - or cheaper - for the compiler to join (BASE plus a constant offset) in the individual accesses (or as an decremented temp variable) and then add the Offset parameter before making the memory access.