This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Compiling differences between C51 v7.03 and v8.06

Hello!

I have uVision that compiles fine with the C51 v7.03 compiler and the related package, but not complete with the 8.06. I used two different Keil installations. All files are in the same folder.

In the 8.06 I get linker errors like "object does not fit in to pdata page" and "0080H". This looks like the compiler was thinking the PDATA was only 128 bytes, but it is set to 256 bytes in the startup.a51. Any clue what's different in the newer Keil package?

Also there is a warning in 8.06 (which does not show in 7.03) "converting non-pointer to pointer" on this

ptr_xdata = sPtr_obj->Adresse;


while the vars are set like this:

uchar uc_set_obj( uchar pdata *ptr_Set)
{
   uchar i;
   uchar xdata *ptr_xdata;
   struct stOBJADR code *sPtr_obj;

   sPtr_obj=&Obj[*ptr_Set];
   .
   .
   .
   ptr_xdata = sPtr_obj->Adresse;
}


The struct stOBJADR has a member "uint Adresse;"

I can see no wrong use of the pointers. I just want to be sure that the warning does not affect the code to not work correctly.

Parents
  • Because it does not really work to access a pointer address value inside a struct that is pointed to by a pointer.

    It should work just fine as long as proper attention is paid to things like operator precedence. This functionality is well-defined and definitely not compiler-specific. If it does not work, then there is either a mistake in the C code or a bug in the compiler. The former is usually much more likely than the latter.

    It should be something like

    No. It shouldn't be something like X - this leads to bugs. The syntax for doing that is very clear and if you would not insist on ignoring how to work with pointers in C, you would probably know how to do it.

    Have you read up on pointer-specific operators, especially the "Member access from pointer" operator, "->" ?

    ptr_xdata = *(sPtr_obj->Adresse)
    

    What is this supposed to do ?

    1. Copy the value of the structure member Adresse to ptr_xdata ?
    2. Copy the address of the structure member Adresse to ptr_xdata ?
    3. Copy the contents of the memory address pointed to by the structure member Aresse to ptr_xdata ?

    We had severe problems in the past calming down the compiler when using such a way.

    The compiler should have absolutely no trouble parsing a trivial operation like that, provided it is fed with the correct code.

    The chance is 50:50 that it will work.

    Compilers don't roll dice. Provided that you didn't switch compilers somewhere in the middle, there should be no statistics involved. The code is either correct, or it is not.

Reply
  • Because it does not really work to access a pointer address value inside a struct that is pointed to by a pointer.

    It should work just fine as long as proper attention is paid to things like operator precedence. This functionality is well-defined and definitely not compiler-specific. If it does not work, then there is either a mistake in the C code or a bug in the compiler. The former is usually much more likely than the latter.

    It should be something like

    No. It shouldn't be something like X - this leads to bugs. The syntax for doing that is very clear and if you would not insist on ignoring how to work with pointers in C, you would probably know how to do it.

    Have you read up on pointer-specific operators, especially the "Member access from pointer" operator, "->" ?

    ptr_xdata = *(sPtr_obj->Adresse)
    

    What is this supposed to do ?

    1. Copy the value of the structure member Adresse to ptr_xdata ?
    2. Copy the address of the structure member Adresse to ptr_xdata ?
    3. Copy the contents of the memory address pointed to by the structure member Aresse to ptr_xdata ?

    We had severe problems in the past calming down the compiler when using such a way.

    The compiler should have absolutely no trouble parsing a trivial operation like that, provided it is fed with the correct code.

    The chance is 50:50 that it will work.

    Compilers don't roll dice. Provided that you didn't switch compilers somewhere in the middle, there should be no statistics involved. The code is either correct, or it is not.

Children
No data