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
  • You don't seem to get it. I don't understand it, because it's confusing.

    In this case, it is actually the reverse. It is confusing because you don't understand it.

    A number of million students have thought that pointers are confusing. However, there are quite a lot of programmers in this world that do know about pointers now. And they can testify that as soon as they really did understand pointers, they no longer see them as confusing.

    It's just a question of getting the correct internal picture of the pointer concept. Before you have a working mental picture, they will be confusing. With the picture in place, you will think: gosh, that was easy.

    The reason so many programs fails because of pointer errors, is not because pointers are hard to grasp but because they are powerful and a more powerful tool is inherently more dangerous. People makes mistakes. When they make mistakes with pointers, bad things happens. So a developer should always be extra careful when working with pointers.

    Right now, we are trying to get you to change your internal view of pointers. A number of us believe that the terminology really is crucial to this task. If you see a pointer as a variable, with the normal properties of a variable (location, value, size, ...) then we believe you have a better chance to be able to switch your mental image of pointers, and be able to figure out their full potential. And their full potential really do require you to think about the address of the pointer, i.e. where it is stored. You really do have to understand why several steps of indirection is needed, or why programs must be able to modify the value of the pointer, and not just the value it points to.

Reply
  • You don't seem to get it. I don't understand it, because it's confusing.

    In this case, it is actually the reverse. It is confusing because you don't understand it.

    A number of million students have thought that pointers are confusing. However, there are quite a lot of programmers in this world that do know about pointers now. And they can testify that as soon as they really did understand pointers, they no longer see them as confusing.

    It's just a question of getting the correct internal picture of the pointer concept. Before you have a working mental picture, they will be confusing. With the picture in place, you will think: gosh, that was easy.

    The reason so many programs fails because of pointer errors, is not because pointers are hard to grasp but because they are powerful and a more powerful tool is inherently more dangerous. People makes mistakes. When they make mistakes with pointers, bad things happens. So a developer should always be extra careful when working with pointers.

    Right now, we are trying to get you to change your internal view of pointers. A number of us believe that the terminology really is crucial to this task. If you see a pointer as a variable, with the normal properties of a variable (location, value, size, ...) then we believe you have a better chance to be able to switch your mental image of pointers, and be able to figure out their full potential. And their full potential really do require you to think about the address of the pointer, i.e. where it is stored. You really do have to understand why several steps of indirection is needed, or why programs must be able to modify the value of the pointer, and not just the value it points to.

Children
No data