I have a question about the behavior of some code I have written: Packet Packet_str; when I declare this structure in my main program and then check its memory location via a printf statement and hyperterminal it says it is 0000. This seems to cause problems in the program I am guessing that something thisnk that this is NULL, but... when i check to see if it is NULL or even (void *) 0 it is false but is true only when I check if it is 0x0000. One way I have been able to get around this is to create a variable which i do not use simply to make Packet_str at a different address than 0000. I have included the following code to help better understand my problem. Packet_str gets passed to this function which uses it under the var name MyPacI. Buffer is an unsigned char * in the Packet structure. Also Packet_str is passed in by reference. if( MyPacI->Buffer == NULL)/*false*/ printf("1:Unable to malloc memory!\n"); else if(MyPacI->Buffer == (void *) 0)/*false*/ printf("2:Unable to malloc memory!\n"); else if(MyPacI->Buffer == 0x0000)/*true*/ printf("3:Unable to malloc memory!\n"); the above is true when I do not make the dummy variable in main. If I make a Packet *dummy variable it offsets the Packet_str to memory location 0003 and all works correctly, but... if in main I set dummy = NULL it acts as if I never created the dummy variable. I only set dummy to NULL to avoid optimization on other compilers. It is not needed under keil. In short I am wondering why this all happens. Why do functions assume 0000 = NULL but not vise-versa, and is there another way to make Packet_str not be at address 0000 other than making an unused variable?
The problem here lies in the fact that the 8051 has a number of different address spaces (code, data, xdata). The Keil compiler supports both memory specific pointers (e.g., "U8 xdata* p"), which can only point to the declared address space, and 'generic' pointers ("U8* p"), which can point to any address space. To implement the generic pointer, Keil has to add a tag byte to the pointer to indicate which address space is pointed to. So, a generic pointer is three bytes long: tag + 16 bits of address. An xdata* is just 16 bits long, and a data* can be a mere 8 bits. If your definition of NULL is ((void*)0), then NULL is a generic pointer, and thus three bytes long. It will be 0x000000. A tag byte value of zero means data space, so this is really a pointer to i:0000. Xdata uses a tag value of 1. (Actually, it's the bank number + 1, if you have far memory.) A variable that lives at offset 0 in xdata would thus have a generic pointer value of 0x010000. So, ((void xdata*)0) != ((void*)0), because 0x010000 != 0x000000. The comparison directly with 0 is a comparison with a integer, not a pointer. The xdata pointer must thus be implicitly converted to an integer; a memory-specific pointer doesn't have a tag byte to worry about. So, ((void xdata*)0) == 0x0000. It may seem as though, in a specific-versus-generic comparison like this, that you could just ignore mismatched tag bytes, or force the generic tag to match the specific one. Using that rule would lead to false positives, though. Consider:
U8 data d _at_ 0; U8 xdata x _at_ 0; U8 *g; g = &d; if (g == &x) // true, if you ignore the tag { *g = 0; // not what you'd expect }
Yes, this clarifies alot for us. We just discovered this generic pointer behavoir earlier today by looking at the .lst code Now, I have a related question. I believe that malloc returns an xdata pointer: void xdata * malloc(param); We had many problems setting a generic pointer to the malloc. Can I cast the return from malloc like this: char *buffer; buffer = (char *)malloc(size); Does this work? It seems like it will cast the void xdata * to a generic.
The cast from a specific pointer to a generic pointer should work. Essentially, the code should just insert the tag byte for xdata along with value of the xdata*. I'd expect to see assembly code along the lines of
CALL _malloc MOV R2,AR6 MOV R1,AR7 MOV R3,#01H
"We just discovered this generic pointer behavoir earlier today by looking at the .lst code" Hmmm... maybe time to sit back and have a good read of the manual, then! It has a whole section on generic- and memory-specific pointers, and the conversion rules between them. BTW: Keil's use of the term "Generic Pointer" is not the same as the ANSI meaning...!
I see NULL pointers, I see malloc. Are you sure you should be programming a '51, not a PC. Erik
In C, it is *not* recommended to cast the return value of malloc() since it hides the error of omitting stdlib.h as an included system header file and the result of malloc() is assumed to return an int. But this cast wouldn't help you any way because you cannot change the memory space by a cast, it would be meaningless. If malloc() allocates from XDATA and you want it to allocate from IDATA, then change malloc.c. Better yet, use static allocations and *never* use malloc(). In 14 years of Keil/8051 development, I've never needed or desired to use malloc(). -- - Mark
Erik and Mark are spot on. malloc and embeded software do not go well together.