Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-1846768 ] ucsim - s51: Instruction 0x27 bug
|
From: SourceForge.net <no...@so...> - 2007-12-11 15:47:37
|
Bugs item #1846768, was opened at 2007-12-08 11:12 Message generated for change (Comment added) made by threinbacher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1846768&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Simulator Group: non bugs Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ucsim - s51: Instruction 0x27 bug Initial Comment: 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 ---------------------------------------------------------------------- Comment By: threinbacher (threinbacher) Date: 2007-12-11 15:47 Message: 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 ---------------------------------------------------------------------- Comment By: threinbacher (threinbacher) Date: 2007-12-08 14:06 Message: 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 ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-12-08 13:27 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1846768&group_id=599 |