| Details |
Message |
|
Read-Only
Author
Sutton Mehaffey
Posted
28-Nov-2001 16:55 GMT
Toolset
C51
|
 data type bug or not.... Sutton Mehaffey
I've noticed that the following definitions generate different data
results. Perhaps, I'm overlooking something.
#define TEMP (*(unsigned char xdata *) 0x10F0))
unsigned char xdata sutton2, *sutton;
unsigned char xdata * xdata sutton3;
sutton = &TEMP;
sutton3 = &TEMP;
sutton2 = TEMP;
If XDATA location 0x10F0 has 0x35, then the following compilation
occurs:
'sutton' has the value X:10F0, which is correct.
'sutton2' has the value 0x35, which is correct.
'sutton3' has the value D:10F0, which is not correct.
To complicate things, if I swap the 'sutton2' and 'sutton' declarations to:
unsigned char xdata *sutton, sutton2;
then 'sutton' has the value D:10F0, which is not correct.
There is no DATA location 10F0, therefore garbage is the result.
The source code generated for *sutton being first in the declaration
list is a 2 byte XDATA pointer, which points to the DATA area.
If *sutton is not the first declaration in the list, it is a 3 byte pointer
(which works correctly) that points to XDATA.
Anyone know what the problem is and why the sutton3 declaration
listed above does not force the compiler to generate a pointer that
points to XDATA?
Thanks
Sutton Mehaffey
Lookout Portable Security
sutton@lookoutportablesecurity.com
|
|
|
Read-Only
Author
Alex Ruiz
Posted
28-Nov-2001 17:53 GMT
Toolset
C51
|
RE: data type bug or not.... Alex Ruiz
The following code works great for me.:
C Compiler: C51.exe V6.20c
#include <intrins.h>
#define TEMP (*(unsigned char xdata *) 0x10F0)
void main ( void ) {
unsigned char xdata *sutton, sutton2, xdata *sutton3;
sutton = &TEMP;
sutton3 = &TEMP;
sutton2 = TEMP;
_nop_();
}
Ah sutton and sutton3 will point to the defined XDATA TEMP, X:10F0h.
*sutton, sutton2 and *sutton3 will have the same data from the X:10F0h address.
|
|
|
Read-Only
Author
Sutton Mehaffey
Posted
28-Nov-2001 22:43 GMT
Toolset
C51
|
RE: data type bug or not.... Sutton Mehaffey
I ran the exact same code and sutton and sutton3 contain D:10F0 and sutton2 is correct and holds the value from X:10F0. So, I don't know the problem. Maybe an emulator problem, which is what I am using to view results.
|
|
|
Read-Only
Author
Sutton Mehaffey
Posted
28-Nov-2001 22:47 GMT
Toolset
C51
|
RE: data type bug or not.... Sutton Mehaffey
What version of the compiler are you using? Maybe there is a difference in mine. I'm using 6.01.
|
|
|
Read-Only
Author
Alex Ruiz
Posted
29-Nov-2001 01:21 GMT
Toolset
C51
|
RE: data type bug or not.... Alex Ruiz
Yup! I'm running the lastest version.
C Compiler: C51.exe V6.20c
|
|
|
Read-Only
Author
Jon Ward
Posted
29-Nov-2001 15:15 GMT
Toolset
C51
|
RE: data type bug or not.... Jon Ward
Maybe an emulator problem, which is what I am using to view results.
Which emulator are you using?
Have you contacted the emulator vendor to see if they have updated software?
Jon
|
|
|
Read-Only
Author
Andrew Neil
Posted
29-Nov-2001 01:09 GMT
Toolset
C51
|
RE: data type bug or not.... Andrew Neil
What exactly are you trying to achieve?
Have you carefully considered:
1. the distinction between "Generic" and "memory-specific" pointers;
2. the Keil syntax for specifying both the location of a pointer, and the memory space which it addresses;
3. the fact that XDATA memory-specific pointers are 2 bytes, while idata, data, bdata, & pdata memory-specific pointers are one byte;
4. Generic pointers are always 3 bytes.
I'm afraid I don't have time to wade through all your layers of multiple indirection, but I suspect that your problem lies in one (or more?) of the above.
|
|
|
Read-Only
Author
tom mazowiesky
Posted
29-Nov-2001 16:01 GMT
Toolset
C51
|
RE: data type bug or not.... tom mazowiesky
I tried the following:
unsigned char xdata TEMP _at_ 0x10f0;
unsigned char xdata sutton2, *sutton;
unsigned char xdata * xdata sutton3;
void main (void)
{
sutton = &TEMP;
sutton3 = &TEMP;
sutton2 = TEMP;
}
looked at the generated code, and at the simulator. Both worked fine. I used the _at_ language extension as a test, but the original code using the #define also worked correctly.
|
|
