Internal/External Memory Questions

Sorry for the newb questions, but I can't find the answers in either the UV2 or C51 manuals.
did you work through the examples in the getting started guide, if not, drop what you are doing and do so.

1) When UV2 gives the Program Data Size after building a project, is this JUST data (first 128 bytes), or is idata included in this total as well? I think it is all 256 bytes, but wanted to make sure.
I do not know about uV2, I do not use it, but the Keil tools give all info in a .M51 file produced by the linker

2) If all internal data memory is exceeded, is the data simply truncated there or is it moved to xdata or something else?
No, you get a linker error

3) I understand that access to xdata is slower than for internal RAM, but is it possible to put a quantification on "slower"?
This is entirely depending on which derivative and which XRAM (many uCs allow control of access speed). Also for sequential access the difference may be different from that for random access.

There is a simple way to find out:
try both, look at the generated assembler, with the datasheet for your uC as a reference count up the instruction cycles NOT instructions required, then multiply that by clocks per instruction cycle.

Erik

1) It's idata.

2) The linker will barf an error message at you.

3) Ballpark ? 2 to 5 times, more if your external memory has wait states.

Guys,
Thanks very much for the replies. I have one more follow-up question I was hoping someone could answer: if I exceed the 128 bytes of data space but do not explicitly locate this extra data in idata space, will I also get a linker error, or will the compiler simply place this data in idata space?

if I exceed the 128 bytes of data space but do not explicitly locate this extra data in idata space, will I also get a linker error
YES a linker error
or will the compiler simply place this data in idata space?
the compiler can not detect space usage and the linker can not change mov a,addr to

mov r0,#addr
mov a,@r0

which would upset each and every jmp in the whole module/program.

Anyhow, such an automatic action would be truly a nuisance, you would never know what was changed and what not.

"The '51 aint no PC" and thus you do NOT want "automatic relocation"

Erik

"the compiler can not detect space usage"

The compiler only sees a single "compilation unit" at a time.
So the compiler can - and does - detect the memory usage of each "compilation unit" in isolation - and reports it in the Listing file.

What the compiler cannot do is to see the entire application as a whole - only the Linker can do that.

Also, the Linker handles Overlaying; not the compiler - so the compiler can't tell what difference that might make...

"if I exceed the 128 bytes of data space but do not explicitly locate this extra data..."

Everything for which you don't explicitly state a memory space goes into the default memory space.

If you overflow the default space, you will get an error.

Think about it: how would the compiler know which variables to "spill over" into another memory space? What would it do when IDATA was also full...?

"I understand that access to xdata is slower than for internal RAM, but is it possible to put a quantification on "slower"?"

The problem isn't so much the sheer speed of the bus cycle as with an architectural limitation of the 8051. To access xdata, you have to load the DPTR register and use special MOVX instructions to move to or from the accumulator. Reading or writing a byte of xdata requires several instructions. And of course, you might have wanted that one-and-only DPTR for something else, which means to do the xdata access, you have to spill some register contents somewhere else.

So, it's hard to pin down exactly how much slower the access will be, since it depends a lot on the code.

Absolutely - using XDATA will not just give somewhat slower memory accesses, but also significantly larger code.

In a large application, I once saved several K of code space by simply moving one very frequently used variable from XDATA to DATA...