Re: [hatari-devel] Diassembly output

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On lauantai 25 tammikuu 2014, Miro Kropáček wrote:
> > What "uae" disassembler shows to you?
> > 
> > (I'm interested about both what instructions it shows,
> > and what are their opcodes (hex values).)
> 
> Precisely this:
> > d pc
>
> $001680 : 6000                                 DC.W      $6000
> $001682 : fffe                                 DC.W      $fffe

If you just start hatari with the binary and invoke debugger
when that binary is loaded by GEMDOS, can it at that point
disassemble this part of code?

I.e. does the disassembler corrupt it's internal state during
usage and stop showing correctly instructions it has earlier
shown right, or does it go wrong right at the beginning?


> $001684 : 2240                                 DC.W      $2240
> $001686 : 41fa                                 DC.W      $41fa
> $001688 : 0112                                 DC.W      $0112
> $00168a : 2080                                 DC.W      $2080
> $00168c : 45fa                                 DC.W      $45fa
> $00168e : 0110                                 DC.W      $0110
> 
> > setopt --disasm uae
> 
> Selected UAE CPU core internal disassembler.
> fdc enable drive=0 on
> fdc enable drive=1 off

Nicolas, could you fix this FDC spam for command line option parsing?


> > d pc
> 
> 00001680: 6000 fffe 2240 41fa 0112 BT .W #$fffe == 00001680 (TRUE)

Ok, so this is 2 words, Branch if True [1] with 16 bit displacement.

[1] However, M68K PRM says that False and True conditions are NOT
    applicable to Bcc instructions?

I've spent now couple of hours reading 68kDisass.c, and while
the bitmasks seem fine for detecting the instructions...
--------------------------
   { MC_ALL, {0xf0ff, 0x6000}, {2}, {ofDisp}, "Bcb"},
   { MC_ALL, {0xf000, 0x6000}, {1}, {ofDisp}, "Bcb.S"},
   { MC_020, {0xf0ff, 0x60FF}, {4}, {ofDisp}, "Bcb.L"},
--------------------------

(Bcc with word arg needs to be checked first so that it's not
confused with one that has displacement in instruction word.)

....I haven't yet found out how it detects the instruction size.
If it gets that wrong, I guess it won't accept it:
--------------------------
    // This test will decline a displacement with the wrong word offset   
    if((opcode[0] & 0xF000) == 0x6000)                                    
    {                                                                     
             val = opcode[0] & 0xFF;                                       
             if(val == 0x00 && size != 2) goto more;                       
             if(val == 0xFF && size != 4) goto more;                       
    }
--------------------------


> 00001684: 2240 41fa 0112 2080 45fa MOVEA.L D0,A1
> 00001686: 41fa 0112 2080 45fa 0110 LEA.L (PC,$0112) == $0000179a,A0
> 0000168a: 2080 45fa 0110 142a 0002 MOVE.L D0,(A0)
> 0000168c: 45fa 0110 142a 0002 eb0a LEA.L (PC,$0110) == $0000179e,A2
> 00001690: 142a 0002 eb0a 0002 0008 MOVE.B (A2,$0002) == $00000a8d,D2
> 00001694: eb0a 0002 0008 4283 162a LSL.B #$00000005,D2
> 00001696: 0002 0008 4283 162a 0003 OR.B #$08,D2

Does it matter from where you start disassembling, for whether
it gets into sync with instructions?


	- Eero