#1411 ucsim - s51: Instruction 0x27 bug

closed-invalid
Simulator (19)
5
2013-05-25
2007-12-08
Anonymous
No

Hi All,

After executing the attached *.hex file i found a strange behaviour in UcSim.

The 31th Instruction (PC = 0x0327) is a:
ADD A, @R1

The initial situation is like this:

The IRAM content before executing the obove mentioned Instruction:

0x00 01 ff 00 00 00 00 01 00 ........
0x08 00 00 00 00 00 00 00 00 ........
0x10 00 00 00 00 00 00 ff 00 ........
0x18 00 00 00 00 00 00 00 00 ........
0x20 00 00 00 00 00 00 00 00 ........
0x28 00 00 00 00 00 00 00 00 ........
0x30 00 00 00 00 00 00 00 00 ........
0x38 00 00 00 00 00 00 00 00 ........
0x40 00 00 00 00 00 00 00 00 ........
0x48 00 00 00 00 00 00 00 00 ........
0x50 00 00 00 00 00 00 00 00 ........
0x58 00 00 00 00 00 00 00 00 ........
0x60 00 00 00 00 00 00 00 00 ........
0x68 00 00 00 00 00 00 00 00 ........
0x70 00 00 00 00 00 00 00 00 ........
0x78 00 00 00 00 00 00 00 00 ........
0x80 ff 07 00 00 00 00 00 00 ........
0x88 00 00 00 00 00 00 00 00 ........
0x90 ff 00 00 00 00 00 00 00 ........
0x98 00 00 00 00 00 00 00 00 ........
0xa0 ff 00 00 00 00 00 00 00 ........
0xa8 00 00 00 00 00 00 00 00 ........
0xb0 ff 00 00 00 00 00 00 00 ........
0xb8 00 00 00 00 00 00 00 00 ........
0xc0 00 00 00 00 00 00 00 00 ........
0xc8 00 00 00 00 00 00 00 00 ........
0xd0 c1 00 00 00 00 00 00 00 ........
0xd8 00 00 00 00 00 00 00 00 ........
0xe0 23 00 00 00 00 00 00 00 #.......
0xe8 00 00 00 00 00 00 00 00 ........
0xf0 00 00 00 00 00 00 00 00 ........
0xf8 00 00 00 00 00 00 00 00 ........

As we can see from the PSW value we are at Register Bank Zero. And R1 Contains 0xFF and the value of memory location 0xFF is 0x00.

This is what UCSIM produces after executing the obove described instruction:

0x00 01 ff 00 00 00 00 01 00 ........
0x08 00 00 00 00 00 00 00 00 ........
0x10 00 00 00 00 00 00 ff 00 ........
0x18 00 00 00 00 00 00 00 00 ........
0x20 00 00 00 00 00 00 00 00 ........
0x28 00 00 00 00 00 00 00 00 ........
0x30 00 00 00 00 00 00 00 00 ........
0x38 00 00 00 00 00 00 00 00 ........
0x40 00 00 00 00 00 00 00 00 ........
0x48 00 00 00 00 00 00 00 00 ........
0x50 00 00 00 00 00 00 00 00 ........
0x58 00 00 00 00 00 00 00 00 ........
0x60 00 00 00 00 00 00 00 00 ........
0x68 00 00 00 00 00 00 00 00 ........
0x70 00 00 00 00 00 00 00 00 ........
0x78 00 00 00 00 00 00 00 00 ........
0x80 ff 07 00 00 00 00 00 00 ........
0x88 00 00 00 00 00 00 00 00 ........
0x90 ff 00 00 00 00 00 00 00 ........
0x98 00 00 00 00 00 00 00 00 ........
0xa0 ff 00 00 00 00 00 00 00 ........
0xa8 00 00 00 00 00 00 00 00 ........
0xb0 ff 00 00 00 00 00 00 00 ........
0xb8 00 00 00 00 00 00 00 00 ........
0xc0 00 00 00 00 00 00 00 00 ........
0xc8 00 00 00 00 00 00 00 00 ........
0xd0 81 00 00 00 00 00 00 00 ........
0xd8 00 00 00 00 00 00 00 00 ........
0xe0 13 00 00 00 00 00 00 00 ........
0xe8 00 00 00 00 00 00 00 00 ........
0xf0 00 00 00 00 00 00 00 00 ........
0xf8 00 00 00 00 00 00 00 00 ........

This is how it should be IMHO....
I verified with Keil C51 Simulator/Debugger, it sets the IRAM like this:

0x00 01 ff 00 00 00 00 01 00 ........
0x08 00 00 00 00 00 00 00 00 ........
0x10 00 00 00 00 00 00 ff 00 ........
0x18 00 00 00 00 00 00 00 00 ........
0x20 00 00 00 00 00 00 00 00 ........
0x28 00 00 00 00 00 00 00 00 ........
0x30 00 00 00 00 00 00 00 00 ........
0x38 00 00 00 00 00 00 00 00 ........
0x40 00 00 00 00 00 00 00 00 ........
0x48 00 00 00 00 00 00 00 00 ........
0x50 00 00 00 00 00 00 00 00 ........
0x58 00 00 00 00 00 00 00 00 ........
0x60 00 00 00 00 00 00 00 00 ........
0x68 00 00 00 00 00 00 00 00 ........
0x70 00 00 00 00 00 00 00 00 ........
0x78 00 00 00 00 00 00 00 00 ........
0x80 ff 07 00 00 00 00 00 00 ........
0x88 00 00 00 00 00 00 00 00 ........
0x90 ff 00 00 00 00 00 00 00 ........
0x98 00 00 00 00 00 00 00 00 ........
0xa0 ff 00 00 00 00 00 00 00 ........
0xa8 00 00 00 00 00 00 00 00 ........
0xb0 ff 00 00 00 00 00 00 00 ........
0xb8 00 00 00 00 00 00 00 00 ........
0xc0 00 00 00 00 00 00 00 00 ........
0xc8 00 00 00 00 00 00 00 00 ........
0xd0 01 00 00 00 00 00 00 00 ........
0xd8 00 00 00 00 00 00 00 00 ........
0xe0 23 00 00 00 00 00 00 00 #.......
0xe8 00 00 00 00 00 00 00 00 ........
0xf0 00 00 00 00 00 00 00 00 ........
0xf8 00 00 00 00 00 00 00 00 ........

Could someone verify this on "real" Hardware....

Im using the ucsim S51 that is delivered with sdcc version:
sdcc-snapshot-i386-unknown-linux2.5-20071202-4974
My kernel Version is:
2.6.22.5-31-default | opensuse 10.3

lg from Vienna,
Thomas

Discussion

  • Nobody/Anonymous

     
    Attachments
  • Maarten Brock

    Maarten Brock - 2007-12-08
    • milestone: --> non_bugs
    • status: open --> pending-invalid
     
  • Maarten Brock

    Maarten Brock - 2007-12-08

    Logged In: YES
    user_id=888171
    Originator: NO

    Thomas,

    Please login next time.

    How did you start s51?
    How did you create this memory dump?
    And why don't you point out where the differences are?

    By default iram ends at 0x80 and the sfr space is not part of iram.
    Also, normally @R1 cannot access sfr space. The result is undefined.

    I assume that the memory dump above 0x80 is sfr space. Then you cannot conclude that the value of memory location 0xFF is 0x00. The 8051 has no memory at 0xFF. It doesn't even have an sfr at 0xFF.

    I cannot verify it on real hardware because I don't have an original intel 8051.

    Maarten

     
  • threinbacher

    threinbacher - 2007-12-08

    Logged In: YES
    user_id=1949775
    Originator: NO

    hi,

    I started S51 with t- 8051 and specified the hex file that i attached..

    Then i initialized the IRAM to zero, after that i single stepped the program and created at every step with dump sfr and dump iram a dump of internal data memory.

    Then i found out that UCsim, behaved different compared to Keil C51 Simulator in this particular case.

    As u can see in the above ram dump ucsim sets the PSW=0x81 and the ACC=0x13.

    Keil sets PSW=0x01 and ACC=0x23.

    Yeah i do now that the IRAM of 8051 ends with 0x7F (and > 0x80 is SFR), I just suggested that somebody should verify this on real hardware to clarify this difference between Keil C51 and UCSim....

    Thomas

     
  • threinbacher

    threinbacher - 2007-12-08
    • status: pending-invalid --> open-invalid
     
  • threinbacher

    threinbacher - 2007-12-11

    Logged In: YES
    user_id=1949775
    Originator: NO

    Hi all,

    @maarten:
    # "....I assume that the memory dump above 0x80 is sfr space. Then you cannot
    conclude that the value of memory location 0xFF is 0x00. The 8051 has no
    memory at 0xFF. It doesn't even have an sfr at 0xFF...."

    It seems to me that a read from an "nonexisting/nonused" SFR location leads ucSim to
    return a value of 0xF0 -> b11110000.

    In my opinion, that makes not that much sense. Reading from a "nonexisting/nonused" SFR location should either
    return 0x00 of 0xff but not something between...

    # "....Also, normally @R1 cannot access sfr space. The result is undefined....."

    Thats true, normally @Rx should not access sfr space.

    But what if it does?

    Since Rx can contain any value in the rage from 0x00 - 0xff i can access SFR space as well.

    According to the 8051 family user guide:
    "@Ri 8-bit internal data RAM location (0-255) addressed indirectly through register R1 or R0."

    Thomas

     
  • Maarten Brock

    Maarten Brock - 2007-12-17
    • assigned_to: nobody --> maartenbrock
    • status: open-invalid --> closed-invalid
     
  • Maarten Brock

    Maarten Brock - 2007-12-17

    Logged In: YES
    user_id=888171
    Originator: NO

    @Thomas:
    > In my opinion, that makes not that much sense. Reading from a
    > "nonexisting/nonused" SFR location should either
    > return 0x00 of 0xff but not something between...

    Try the real world. Reading from a nonexisting sfr/memory/whatever will not return something predefined like 0x00 or 0xFF.

    > Thats true, normally @Rx should not access sfr space.
    > But what if it does?

    That is one of many possibilities of undefined behaviour (I remember Chipcon CC1010 doing this, but they specified as such in their datasheet). But it's not something one can rely on.

    > Since Rx can contain any value in the rage from 0x00 - 0xff
    > i can access SFR space as well.

    No, that's not what the datasheet says. It says that the SFR's are accessed using direct access and indirect access can be used for internal RAM. The fact that the 8051 does not have enough RAM to fill the whole address space does not mean the unused half will be used for SFR access. It might just as well wrap around the address space by ignoring address-bit7. Or anything else.

    I'm closing this one now, because I don't want to keep the discussion open and I also do not want to implement anything in the simulator that is undefined for the original part. Moreover IMHO undefined behaviour cannot be a bug.

    Maarten

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks