#2383 Dissassembler Problem

[Randy Yates]

The following is a section of MCS51 code (starting at _main) disassembled in
the s51 simulator:

0> disassemble 0x90 0 40
0x0090 c0 08 PUSH 08
0x0092 85 81 08 MOV 08,SP
0x0095 12 00 79 LCALL 0079
0x0098 7e 00 MOV R6,#00
0x009a 7f 00 MOV R7,#00
0x009c 8e 82 MOV DPL,R6
0x009e c0 07 PUSH 07
0x00a0 c0 06 PUSH 06
0x00a2 12 00 5c LCALL 005c
0x00a5 ad 82 MOV R5,DPL
0x00a7 7c 00 MOV R4,#00
0x00a9 c0 05 PUSH 05
0x00ab c0 04 PUSH 04
0x00ad 74 eb MOV A,#eb
0x00af c0 e0 PUSH ACC
0x00b1 74 10 MOV A,#10
0x00b3 c0 e0 PUSH ACC
0x00b5 74 80 MOV A,#80
0x00b7 c0 e0 PUSH ACC
0x00b9 12 01 10 LCALL 0110
0x00bc e5 81 MOV A,SP
0x00be 24 fb ADD A,#fb
0x00c0 f5 81 MOV SP,A
0x00c2 d0 06 POP 06
0x00c4 d0 07 POP 07
0x00c6 0e INC R6
0x00c7 be 00 01 CJNE R6,#00,00cb
0x00c8 00 NOP
0x00c9 01 0f AJMP 000f
0x00ca 0f INC R7
0x00cb ef MOV A,R7
0x00cc 60 ce JZ 009c
0x00ce 12 00 8c LCALL 008c
0x00d1 80 fe SJMP 00d1

The bug is at program address 0x00c8,
"NOP". The previous instruction at 0x00c7 was a three-byte instruction,
so why is the disassembler interpreting 0x00c8 as the next instruction?

The simulator was invoked as follows:

sdcc-s51 sim-even-parity.ihx -S out=/home/yada/default.dat

I am attaching the file sim-even-parity.ihx

This is under Fedora 21 using the fedora-packaged sdcc,

Name : sdcc
Arch : x86_64
Version : 3.3.0
Release : 1.fc20
Size : 49 M
Repo : installed
From repo : updates
Summary : Small Device C Compiler
URL : http://sdcc.sourceforge.net/
License : GPLv2+
Description : SDCC is a C compiler for 8051 class and similar microcontrollers.
: The package includes the compiler, assemblers and linkers, a
: device simulator and a core library. The processors supported (to
: a varying degree) include the 8051, ds390, z80, hc08, and PIC.

[Daniel Drotos]

[r9234] fixes this bug

[Randy Yates]

Daniel, thanks so much for that quick fix!

But..., I neglected to mention there is another bug in that same area. Namely the CJNE address is not reported correctly. That is, shouldn't

0x00c7 be 00 01 CJNE R6,#00,00cb

actually be

0x00c7 be 00 01 CJNE R6,#00,0001

?

[Daniel Drotos]

On Sat, 16 May 2015, Randy Yates wrote:

But..., I neglected to mention there is another bug in that same
area. Namely the CJNE address is not reported correctly. That is,
shouldn't

0x00c7 be 00 01 CJNE R6,#00,00cb

actually be

0x00c7 be 00 01 CJNE R6,#00,0001

Here 01 is a "relative address" which value is added to PC when
the jump happens. Disassembler calculates this and displays the real
target address where the jump will go to. This is by design, because I
think it is more informative and more "human readable".

Daniel