While working with some memory-mapped I/O, I came across some behavior which may be construed as a bug. I declared my memory-mapped stuff as an unsized array of char's in xdata. C51 produced no errors, but the array was positioned at address 0x0000. The linker then reported a L107 error due to overlap with the normal xdata variables. I fixed the problem by specifying a size to the array, but this smells like the wrong behavior to me. Am I all wet? Remove the "//" on line 5 to fix the bug.
/* Keil v6.14 memory space bug(?) demonstration */ #define NUM // 1 char xdata test1[NUM] _at_ 0x1E00; char xdata test2[NUM] _at_ 0x1F00; char xdata test3; void main(void) { char x; x = test1[0x13]; x = test2[0x25]; x = test3; }
Hmmm... But what does an "unsized" array actually mean? It's really just a pointer, isn't it? So why not just say
char xdata *p = 0x1E00 // Pointer to XDATA location 0x1E00
A declaration like
char xdata test1[];
char xdata test1[] = "stuff";
So, if the compiler doesn't actually allocate any storage, how can it place it at any particular location!? Thanks for the reply! Well, it may sound kind of silly, but I think a zero-byte field at a specific address is legitimate in this case. My solution was to give the declaration a size - and this worked just fine. However, I still think it's kind of a bug in that the compiler dropped the 0-byte-long array at address 0, not the address I gave it.
But what does an "unsized" array actually mean? It's really just a pointer, isn't it? So why not just say
Note that you can explicitly specify both the location of the pointer, and the memory space which it addresses; eg,
char data * xdata str; /* ptr in xdata to data char */ int xdata * data numtab; /* ptr in data to xdata int */ long code * idata powtab; /* ptr in idata to code long */
... or use the XBYTE, etc, absolute memory access macros?