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

C 7.5 compiler bug

I tried to submit this via the email to tech support page but it gave me a 500 error.
I have a hard time believing that I am the only person this has happened to, but clearly
this is a compiler bug in Keil 8051 version 7.5 compiler.
I hope that someone can get this to the correct person at Keil.

4747   1          if(chksum != CWORD[0xF800])
4748   1              {
4749   2              cstate=1;
4750   2              }
4751   1          if(chksum != CWORD[0xF900])
4752   1              {
4753   2              cstate=1;
4754   2              }
4755   1          if(chksum != CWORD[0xFA00])
4756   1              {
4757   2              cstate=1;
4758   2              }
4759   1          if(chksum != CWORD[0xFB00])
4760   1              {
4761   2              cstate=1;
4762   2              }
4763   1          if(chksum != CWORD[0xFC00])
4764   1              {
4765   2              cstate=1;
4766   2              }
4767   1          if(chksum != CWORD[0xFd00])
4768   1              {
4769   2              cstate=1;
4770   2              }
4771   1
4772   1          if(chksum != CWORD[0xFE00])
4773   1              {
4774   2              cstate=1;
4775   2              }


                                           ; SOURCE LINE # 4747
0645 90F000            MOV     DPTR,#0F000H <<<<<<<<<<<< should be F800
0648 7800        R     MOV     R0,#LOW chksum
064A E6                MOV     A,@R0
064B FE                MOV     R6,A
064C 08                INC     R0
C51 COMPILER V7.50   MEDBEST040_LCD                                                        10/03/2012 12:30:27 PAGE 300

064D E6                MOV     A,@R0
064E FF                MOV     R7,A
064F 7401              MOV     A,#01H
0651 93                MOVC    A,@A+DPTR
0652 6F                XRL     A,R7
0653 7003              JNZ     ?C1279
0655 E4                CLR     A
0656 93                MOVC    A,@A+DPTR
0657 6E                XRL     A,R6
0658         ?C1279:
0658 6006              JZ      ?C0032
                                           ; SOURCE LINE # 4748
                                           ; SOURCE LINE # 4751
0660 90F200            MOV     DPTR,#0F200H   <<<<<<<<<<<<<<<<<<< should be F900
...
                                           ; SOURCE LINE # 4755
0674 90F400            MOV     DPTR,#0F400H   <<<<<<<<<<<<<<<<<<< should be FA00
...
                                           ; SOURCE LINE # 4759
068F 90F600            MOV     DPTR,#0F600H   <<<<<<<<<<<<<<<<<<< should be FB00
...
                                           ; SOURCE LINE # 4763
06AA 90F800            MOV     DPTR,#0F800H   <<<<<<<<<<<<<<<<<<< should be FC00
...
                                           ; SOURCE LINE # 4767
06BE 90FA00            MOV     DPTR,#0FA00H   <<<<<<<<<<<<<<<<<<< should be FD00
...
                                           ; SOURCE LINE # 4772
06D9 90FC00            MOV     DPTR,#0FC00H   <<<<<<<<<<<<<<<<<<< should be FE00



 While this works.
15430  01          FLSCL=0x01;               // enable flash write/erase
15431  01          PSCTL=0x01;                     // BUGG  NOT 2, which would erase flash, but 1write to flash
15432  01          *write_ptr=CBYTE[0xFA00];
15433  01          PSCTL = 0x00;              // MOVX writes target XRAM
15434  01          FLSCL=0;                // disable flash write


 000C 75B701            MOV     FLSCL,#01H
                                           ; SOURCE LINE # 15431
000F 758F01            MOV     PSCTL,#01H
                                           ; SOURCE LINE # 15432
0012 90FA00            MOV     DPTR,#0FA00H
0015 E4                CLR     A
0016 93                MOVC    A,@A+DPTR
0017 8F82              MOV     DPL,R7
0019 8E83              MOV     DPH,R6
001B F0                MOVX    @DPTR,A
                                           ; SOURCE LINE # 15433
001C E4                CLR     A
001D F58F              MOV     PSCTL,A
                                           ; SOURCE LINE # 15434
001F F5B7              MOV     FLSCL,A

Parents
  • Is this a quantum-jitter case?

    Nothing remotely as exotic.

    The adage "No such thing as fool-proof --- Nature will just make better fools!" is, at the core of it, an application of Murphy's Law, which in turn is really just common sense applied to the field of engineering:

    1) If there's any way something can possibly go wrong, it will go wrong.

    2) If there's any way something can be misused by a fool, some fool will do so.

    3) If there's any remote possibility a document might be misunderstood, some fool will misunderstand it.

    4) If existing fools really aren't up to tasks 2) or 3), Nature will make better ones.

Reply
  • Is this a quantum-jitter case?

    Nothing remotely as exotic.

    The adage "No such thing as fool-proof --- Nature will just make better fools!" is, at the core of it, an application of Murphy's Law, which in turn is really just common sense applied to the field of engineering:

    1) If there's any way something can possibly go wrong, it will go wrong.

    2) If there's any way something can be misused by a fool, some fool will do so.

    3) If there's any remote possibility a document might be misunderstood, some fool will misunderstand it.

    4) If existing fools really aren't up to tasks 2) or 3), Nature will make better ones.

Children
  • And the big problem here is that Murphy was an optimist.

  • ROTFLMAO!

    O.k. Here are the rules for the silabs 040

    A read movx always reads from memory. A movc always reads from flash/info. An instruction fetch always reads from memory (never info page) A write movx changes targets flash/info or memory based on the state of PSCTL[0]

    Applying those 4 rules will tell you what happens at any point in your matrix (and some points outside your matrix ;) except for where PSCTL = 0x2 which is truly undefined (PSCTL = 0x3 for erases)

    MURPHY LIVES... to paraphrase a line from 'V'..

    Additionally, I am going to share one of my debugging hassles early on with the Silabs parts,
    to make a point about what undefined means:

    True story with a silabs part: (all of them actually, but I found it on the 320)

    Silabs says a divide by 0 instruction i.e. executing a div with one operand is 0, is undefined.
    Intel says that a divide by 0 instruction i.e. executing a div with one operand is 0 is also undefined.

    HOWEVER:

    Intel implemented that to return a 0
    Silabs implemented that to return a 0xFF, thus violating the standard legacy setting from Intel.

    What happened is that code that ran on an intel part, mysteriously broke on the silabs part, resulting in the end user of our hardware getting a +450 volt shock.

    The product we were reverse engineering ran on intel parts, and I basically disassembled the roms, and transcribed them into C. Additionally the port of the intel code in assembly to the silabs part also broke, but I did not do that until much later.

    Now granted: it was sloppy code on my part , so no flames here, I should have checked for the divide by 0. When I found the problem, I did that, and it went away, BUT the silabs part *should* have faithfully copied the functionality of the intel part. And by normal math rules, a number divided by 0 is ALWAYS 0, so it worked just fine on the intel code.

    Silabs *should* have certainly documented what would happen in the instruction description.

    Being it was an 8051 the automatic assumption ..(I know, to assume anything is to make an "ASS out of U and ME")..is that instructions will operate identically the same as the original 8051 standard by Intel.

  • And by normal math rules, a number divided by 0 is ALWAYS 0, so it worked just fine on the intel code.

    NO. It is NEVER zero. Not in a million years.

    Presuming one insists on allowing it at all, then by normal math rules a (non-zero) number divided by zero is infinity. Coming from that point of view, it's actually SiLabs that came closer to getting this right, here, by giving you the closest thing to infinity that fits into an 8-bit unsigned result: 255.

    Silabs *should* have certainly documented what would happen in the instruction description.

    They did, by specifying that the behaviour is undefined. Which is essentially the standard technical legalese rendition of your mom yanking your back from the stove and yelling at you: "Do not do that!"