Invalid addressing modes, assembler problems ..

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Invalid addressing modes, assembler problems ..

Postby AtariZoll » Mon Aug 11, 2014 6:46 am

As I see, for many is not clear what all addressing modes are valid for diverse CPUs in MC68K family.
See this thread, where problem popped up: viewtopic.php?f=3&t=26068&start=50

My question is: which is the latest Devpac Atari ST version ? I know about 3.10 as latest. And it allows not something like :
cmpi.l #data,d16(pc) - when 68030 processor is selected in options. But it is valid on 68030 according to my test on Falcon. And according to Motorola 68000 family data sheets.
Another instruction group is move . On 68000 destination can not be pc-relative addressing mode, but on 68030 it should be valid. And it is so in Motorola data sheets, but now the biggest surprise: there stays not that on 68000-68010 destination can not be pc-relative !
However, I'm sure that it can not be, and I have book from 1985 about 68000, where it is clearly visible that on 68000 move instructions can have 12 addressing modes for source, and only 9 addressing modes for destination. Where no pc-relative modes, of course.
Those 9 modes are: Dn, An, An@, An@+, An@-, an@(d), An@(d,ix), xxx.w, xxx.l .

My experience is that generally on 68000 destination in case of 2 operand instruction can not be pc-relative. This is why need 2 instructions instead 1 when doing pc-relative code: move.b #11,lab1(pc) is invalid. Instead must use: lea lab1(pc),a1 .... move.b #11,(a1) .
But many single operand instructions allow not pc-relative addressing too.
tst.b lab2(pc) is invalid on 68000, but valid on 68030, and in this case, Devpac 3.1 and even 3.0 does it right - gives message that not allowed only on 68000 .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
troed
Atari God
Atari God
Posts: 1447
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Invalid addressing modes, assembler problems ..

Postby troed » Mon Aug 11, 2014 9:05 am

The instruction [timing] table I take as "gospel" (due to the history of its maintainer) is yacht.txt. I'm sure he would be very interested in knowing about errors in it.

viewtopic.php?f=68&t=24710#p227267

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Mon Aug 11, 2014 11:09 am

I don't see in that yacht pr-relative source by move instructions.

Here are tables with cycles for move instructions for 68000 :
Not looking best without proper formatting, but may see that destination (horizontal row) has no
pc-relative addressing modes. Exactly same is in mentioned book from 1985.


These following two tables indicate the number of clock periods for the move
instruction. This data includes instruction fetch, operand reads, and operand
writes. The number of bus read and write cycles is shown in parenthesis
as (r/w).


Move Byte and Word Instruction Execution Times

Dest : Dn An (An) (An)+ -(An) d(An) d(An,ix) xxx.W xxx.L

Src:
Dn 4(1/0) 4(1/0) 8(1/1) 8(1/1) 8(1/1) 12(2/1) 14(2/1) 12(2/1) 16(3/1)
An 4(1/0) 4(1/0) 8(1/1) 8(1/1) 8(1/1) 12(2/1) 14(2/1) 12(2/1) 16(3/1)
(An) 8(2/0) 8(2/0) 12(2/1) 12(2/1) 12(2/1) 16(3/1) 18(3/1) 16(3/1) 20(4/1)
(An)+ 8(2/0) 8(2/0) 12(2/1) 12(2/1) 12(2/1) 16(3/1) 18(3/1) 16(3/1) 20(4/1)
-(An) 10(2/0) 10(2/0) 14(2/1) 14(2/1) 14(2/1) 18(3/1) 20(4/1) 18(3/1) 22(4/1)
d(An) 12(3/0) 12(3/0) 16(3/1) 16(3/1) 16(3/1) 20(4/1) 22(4/1) 20(4/1) 24(5/1)
d(An,ix) 14(3/0) 14(3/0) 18(3/1) 18(3/1) 18(3/1) 22(4/1) 24(4/1) 22(4/1) 26(5/1)
xxx.W 12(3/0) 12(3/0) 16(3/1) 16(3/1) 16(3/1) 20(4/1) 22(4/1) 20(4/1) 24(5/1)
xxx.L 16(4/0) 16(4/0) 20(4/1) 20(4/1) 20(4/1) 24(5/1) 26(5/1) 24(5/1) 28(6/1)
d(PC) 12(3/0) 12(3/0) 16(3/1) 16(3/1) 16(3/1) 20(4/1) 22(4/1) 20(4/1) 24(5/1)
d(PC,ix) 14(3/0) 14(3/0) 18(3/1) 18(3/1) 18(3/1) 22(4/1) 24(4/1) 22(4/1) 26(5/1)
#xxx 8(2/0) 8(2/0) 12(2/1) 12(2/1) 12(2/1) 16(3/1) 18(3/1) 16(3/1) 20(4/1)

The size of the index register (ix) does not affect execution time


Move Long Instruction Execute Times

Dest: Dn An (An) (An)+ -(An) d(An) d(An,ix) xxx.W xxx.L

Src:
Dn 4(1/0) 4(1/0) 12(1/2) 12(1/2) 12(1/2) 16(2/2) 18(2/2) 16(2/2) 20(3/2)
An 4(1/0) 4(1/0) 12(1/2) 12(1/2) 12(1/2) 16(2/2) 18(2/2) 16(2/2) 20(3/2)
(An) 12(3/0) 12(3/0) 20(3/2) 20(3/2) 20(3/2) 24(4/2) 26(4/2) 24(4/2) 28(5/2)
(An)+ 12(3/0) 12(3/0) 20(3/2) 20(3/2) 20(3/2) 24(4/2) 26(4/2) 24(4/2) 28(5/2)
-(An) 14(3/0) 14(3/0) 22(3/2) 22(3/2) 22(3/2) 26(4/2) 28(4/2) 26(4/2) 30(5/2)
d(An) 16(4/0) 16(4/0) 24(4/2) 24(4/2) 24(4/2) 28(5/2) 30(5/2) 28(5/2) 32(6/2)
d(An,ix)18(4/0) 18(4/0) 26(4/2) 26(4/2) 26(4/2) 30(5/2) 32(5/2) 30(5/2) 34(6/2)
xxx.W 16(4/0) 16(4/0) 24(4/2) 24(4/2) 24(4/2) 28(5/2) 30(5/2) 28(5/2) 32(6/2)
xxx.L 20(5/0) 20(5/0) 28(5/2) 28(5/2) 28(5/2) 32(6/2) 34(6/2) 32(6/2) 36(7/2)
d(PC) 16(4/0) 16(4/0) 24(4/2) 24(4/2) 24(4/2) 28(5/2) 30(5/2) 28(5/2) 32(5/2)
d(PC,ix) 18(4/0) 18(4/0) 26(4/2) 26(4/2) 26(4/2) 30(5/2) 32(5/2) 30(5/2) 34(6/2)
#xxx 12(3/0) 12(3/0) 20(3/2) 20(3/2) 20(3/2) 24(4/2) 26(4/2) 24(4/2) 28(5/2)

The size of the index register (ix) does not affect execution time
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Mon Aug 11, 2014 6:38 pm

Hello
according to "M68000 FAMILY PROGRAMMER’S REFERENCE MANUAL" M68000PRM.pdf on page 4-117, d(PC) are not allowed as a destination EA, not in 68000 and neither in 68020+ mode.
So Motorola correctly says that d(PC) can't be used as a destination.

Nicolas

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Mon Aug 11, 2014 7:37 pm

You mean this:
motMoveD.png

I must admit that was confused with that. Because An can be destination certainly. I used zillion times move d0,a0 for instance.
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Mon Aug 11, 2014 8:16 pm

AtariZoll wrote:You mean this:
I must admit that was confused with that. Because An can be destination certainly. I used zillion times move d0,a0 for instance.

Yes, that's this page.
But if you look a few pages after, you will see An as a destination is described in movea :)

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Tue Aug 12, 2014 7:47 am

Right. However, it is really hard to go through that Motorola doc. I don't know why they went on using separate mnemonics for movea, move, or cmp, cmpi when it is obvious in instruction which mode is used. Assemblers usually accept any form.

I tried to google some overview about not allowed addressing modes by specific instructions, but did not find anything. In my 68000 book also there is no info about that by instruction descriptions.

So, we are still not sure about many instruction addressing mode restrictions. Making whole table for all involved instruction could take pretty much time - considering that need to make tests on 68000 and 68030 at least. Or going through Motorola doc, hoping that there are no mistakes. For instance I see that by LSL, LSR data register can not be operand to be shifted - only memory alterable addressing modes ... ????
Really confusing, as we know that it works with data registers.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Tue Aug 12, 2014 8:32 am

AtariZoll wrote:Right. However, it is really hard to go through that Motorola doc. I don't know why they went on using separate mnemonics for movea, move, or cmp, cmpi when it is obvious in instruction which mode is used. Assemblers usually accept any form.

I tried to google some overview about not allowed addressing modes by specific instructions, but did not find anything. In my 68000 book also there is no info about that by instruction descriptions.

Assemblers accept any form for convenience, but I think Motorola separated them because they use different microcode and/or prefetch sequence. Also move "size" can be long, word or byte, but movea can only be long or word.
So, we are still not sure about many instruction addressing mode restrictions. Making whole table for all involved instruction could take pretty much time - considering that need to make tests on 68000 and 68030 at least. Or going through Motorola doc, hoping that there are no mistakes. For instance I see that by LSL, LSR data register can not be operand to be shifted - only memory alterable addressing modes ... ????
Really confusing, as we know that it works with data registers.

You misread the doc : on page 4-114 "register shift" is described and on page 4-115 "memory shift" is described.

So far, I never heard of a case where real cpu didn't respect Motorola's doc for addessing mode. I know WinUAE has a high compatibility with Amiga demos/games that sometimes use tricky combinations between cpu and HW, so I'm pretty sure the Motorola's doc can be considered as "validated" (Hatari shares the same cpu table as WinUAE, except for CMPI and BTST which were incorrect and fixed earlier)

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1965
Joined: Sun Jul 31, 2011 1:11 pm

Re: Invalid addressing modes, assembler problems ..

Postby Eero Tamminen » Tue Aug 12, 2014 7:07 pm

AtariZoll wrote:So, we are still not sure about many instruction addressing mode restrictions. Making whole table for all involved instruction could take pretty much time - considering that need to make tests on 68000 and 68030 at least. Or going through Motorola doc, hoping that there are no mistakes. For instance I see that by LSL, LSR data register can not be operand to be shifted - only memory alterable addressing modes ... ????
Really confusing, as we know that it works with data registers.


Write code that generates all combinations. Then run them on real machine with illegal instruction handler that sets variable telling that last tested instruction was illegal. Log what opcodes generated exceptions, then run those opcodes through disassembler to get your table.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Tue Aug 12, 2014 8:09 pm

Eero Tamminen wrote:...
Write code that generates all combinations. Then run them on real machine with illegal instruction handler that sets variable telling that last tested instruction was illegal. Log what opcodes generated exceptions, then run those opcodes through disassembler to get your table.


This is good idea, except part that I should do it :mrgreen:
All combinations mean 65536 . Will need lot of time to check all invalid ones - probably over 10000 will be invalid on any CPU.

Other way would be to write all instructions with pc-relative addressing, and try to assemble. In that case less than 100 is what I expect.
Well, it may happen that I will do it, when will have some more time and more health. But, there is one problem, big problem: what assembler to use, when Devpac 3, 3.10 will not assemble all allowed addressing modes, even when set to 68030 ???? As said in other thread, Devpac 3 gives message "addressing mode not allowed:" for cmpi.l #data,label(pc) , even when set to 68030, and as I tested, opcode of it (taken from POLEPOS) works on Falcon. So, what assembler to use, which will reliable assembling all possible instructions with pc-relative addressing, when set to 68030 ?
Other way would be to go through Motorola docs, and using their bit combination tables for instructions use dc.w % ....... instead mnemonics. And testing that on real HW. In any case, not some 1 afternoon work.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1724
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Invalid addressing modes, assembler problems ..

Postby Cyprian » Tue Aug 12, 2014 8:22 pm

AtariZoll wrote: So, what assembler to use, which will reliable assembling all possible instructions with pc-relative addressing, when set to 68030 ?

VASM properly compiles that code:

Code: Select all

data   SET $1234
   cmpi.l #data,label(pc)

   nop
label
Lynx II / Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Tue Aug 12, 2014 8:36 pm

AtariZoll wrote:Other way would be to go through Motorola docs, and using their bit combination tables for instructions use dc.w % ....... instead mnemonics. And testing that on real HW. In any case, not some 1 afternoon work.

As troed said above, the "yacht" table is very detailed and precise, it includes prefetch accesses and IIRC it was tested against real hardware to have a product compatible with a 68000 (in VHDL or similar, I don't remember the details)
So the work of testing all opcodes was already done.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Wed Aug 13, 2014 2:20 am

As said, in that Yacht tables , in case of move instruction 2 source addressing modes missing - pc-relative ones. Compare it with move tables I posted here.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Wed Aug 13, 2014 8:37 am

AtariZoll wrote:As said, in that Yacht tables , in case of move instruction 2 source addressing modes missing - pc-relative ones. Compare it with move tables I posted here.

Yes, Yacht table should be used to get precise prefetch informations *once* you ensured an addressing mode is correct. So PC cases are in fact handled in An case (they take the same time).
To really know if a mode is valid or not, you should refer to the Motorola doc, as far as I know this is the reference and I don't heard about a case that would be different between the doc and the real CPU.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Thu Aug 14, 2014 7:58 am

I made simple test program, which just tries all opcodes in order, starting from $0000 . Generating log file, which is 256 KB long, as for each opcode needs 4 bytes - 2 is opcode self, and ASCI "VA" if caused not illegal exception, or ASCI "IN" if caused illegal. This allows easy comparison of diverse log files, made on diverse HW or emulators. At end count of invalid opcodes is written as word.
I added some filter, to skip branching instructions, reset etc. But it happens that some values cause double bus errors, what halts CPU, or in case of emulators initializes restart, with cleared RAM (Steem) . Problem happens with $2E3E, $2E3F ... , so I limited for now test with $2E3E, just to see the results on real ST and emulators.
Count of invalids on real HW is $0BD4, Steem 3.2 - $0936 , Hatari 1.8 - $0A3B . Problematic cmp.l #data,label(pc) opcode is VA in Hatari, and IN on real HW, as is stated already. I looked so far only some opcodes detected as VA in Steem, which are IN on real HW. Range $1008-$100F :
move.b a0,d0 - of course it is invalid as no byte size allowed with address registers. So, there are Steem bugs in CPU emulation too .
All this needs more time for looking other differences.
Percentage of invalid opcodes is $0BD4*100/$2E3E = 25 % in this opcode area.

Here is src of proggy:

Code: Select all


* Program for testing validity of opcodes on CPU MC68000
* later may version for 68030

* This will generate log file with size of 265KB aprox
* Starting with opcode $0000, followed with ASCI "VA"
* if valid, or ASCI "IN" if invalid/illegal . So, for 1 istruction
* variant we need 4 bytes.  After that comes $0000 and word
* containing count of invalid opcodes. So, log file size is
* exactly $40004 bytes.


begin        clr.l  -(sp)
   move.w   #32,-(sp)
   trap  #1
   move.l   d0,iniSp

   move.w   #$2700,sr

*Saving all vectors :  8-$140

   lea   8.w,a0
   lea   vecsav(pc),a1
   moveq   #$4D,d1
.ves   move.l   (a0)+,(a1)+
   dbf   d1,.ves

* Setting all vectors to continue point:

   move.l   #cont,d2
   lea   8.w,a1
   moveq   #$4D,d1
.sev   move.l   d2,(a1)+
   dbf   d1,.sev

* Except   illegal, of course

   move.l   #illeg,$10.w

* Starting test :

   moveq   #0,d0     * starting with 0


loop   lea   stackend,sp

   lea   $E00000,a0
   move.l   a0,a1
   move.l   a0,a2
   move.l   a0,a3
   move.l   a0,a4
   move.l   a0,a5
   move.l   a0,a6    * Prevent accidental overwrites of self

   move.w   d0,opcod

   move.w   d0,exec

* Here must filter out all branch istructions, reset and ...

* branches, bsr ... :

   move.w   d0,d1
   and.w   #$F000,d1
   cmp.w   #$6000,d1   * first nibble is 6 always
   beq   cont

* DBcc test :
   move.w   d0,d1
   and.w   #%0101000011001000,d1
   cmp.w   #%0101000011001000,d1
   beq   cont

* JMP test :
   move.w   d0,d1
   and.w   #%0100111011000000,d1
   cmp.w   #%0100111011000000,d1
   beq   cont

* Above will not test JMP instruction, so need to test separately by need !

* JSR test :
   move.w   d0,d1
   and.w   #%0100111010000000,d1
   cmp.w   #%0100111010000000,d1
   beq   cont


* MOVE to SR :

   move.w   d0,d1
   and.w   #%0100011011000000,d1
   cmp.w   #%0100011011000000,d1
   beq   cont

* Reset :
   cmp.w   #$4E70,d0
   beq   cont

* rte
   cmp.w   #$4E73,d0
   beq   cont

* rts
   cmp.w   #$4E75,d0
   beq   cont

* rtr
   cmp.w   #$4E77,d0
   beq   cont

* stop
   cmp.w   #$4E72,d0
   beq   cont




exec   dc.w   0    *  here comes opcode for test

   trap   #0
   trap   #0
   trap   #0
   trap   #0
   trap   #0
   trap   #0
   trap   #0
   trap   #0    * ensure that jump to continue regardless from
* instructions length



cont   * instruction was executed

   move.l   logPos(pc),a1
   move.w   opcod(pc),d0
   move.w   d0,(a1)+
   move.w   #"VA",(a1)+
comvi   move.l   a1,logPos


   addq.w   #1,d0

   cmp.w   #$2E3E,d0    * here double bus error occurs
* So, for now it is test end
   beq   testEnd

   tst.w   d0
   bne   loop
* Test end

   bra   testEnd


illeg   
   move.l   logPos(pc),a1
   move.w   opcod(pc),d0
   move.w   d0,(a1)+
   move.w   #"IN",(a1)+
   addq.w   #1,invCnt
   bra.s        comvi
   

testEnd   nop
   nop


* Put count of invalids to end of logfile

   clr.w   logFile+$40000
   move.w   invCnt(pc),logFile+$40002


* Restore  all vectors :


   lea   8.w,a0
   lea   vecsav(pc),a1
   moveq   #$4D,d1
.ves   move.l   (a1)+,(a0)+
   dbf   d1,.ves


   lea   stackend,sp

   move.w   #$2300,sr

   clr.w   -(sp)
   pea   savnam(pc)
   move.w   #$3C,-(sp)
   trap   #1
   addq.l   #8,sp

   move.w   d0,d7
   
   
   pea   logFile
   pea   $40004
   move.w   d7,-(a7)
   move.w   #$40,-(a7)
   trap   #1
   lea   12(sp),sp

   move.w   d7,-(a7)
   move.w   #$3E,-(a7)
   trap   #1
   addq.l   #4,a7

   clr.w   -(sp)
   trap   #1


    section   data


iniSp          dc.l   0

opcod   dc.w   0

logPos   dc.l   logfile

invCnt   dc.w   0


savnam   dc.b    "OPCLOG.BIN",0
   even



    section   bss

vecsav   ds.l     $50



logfile   ds.b   $40004

   ds.b   1000

trash

    ds.b   2000

stackEnd



OPCOVAT1.ZIP


After finished test, what takes few seconds only, it will return to Desktop, but mouse will not work 100% OK. So, reset machine if want to continue work on. I just restored system so much that file save work, for log file.

And to continue my tradition, this post will be not without criticizing Motorola docs too :mrgreen:
I observed this earlier, when disassembled and reassembled game Tanglewood. I got functionally and in size 100% equal TOS executable after reassembling, but binary comparison of 2 files shows some differences:
In original what is $D0BC in reassembled (With Devpac3) is $0680 . First is add.l #data,d0 , second is addi.l #data,d0 . According to Motorola docs, $DOBC is invalid, but it works on real HW, and compiler used in case of Tanglewood (coded in C) generated that.

madd1.png


madd2.png


I really don't get their approach in this: what this means: "The Dn mode is used when the destination is a data register, the destination < ea > mode is invalid for data register"
So, Dn mode is valid too, but they excluded it from table, as table is only for alterable memory addressing modes ??? Then why no specific mentioning that this opcode works with data register as destination too ???
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Thu Aug 14, 2014 9:12 am

AtariZoll wrote:And to continue my tradition, this post will be not without criticizing Motorola docs too :mrgreen:
I observed this earlier, when disassembled and reassembled game Tanglewood. I got functionally and in size 100% equal TOS executable after reassembling, but binary comparison of 2 files shows some differences:
In original what is $D0BC in reassembled (With Devpac3) is $0680 . First is add.l #data,d0 , second is addi.l #data,d0 . According to Motorola docs, $DOBC is invalid, but it works on real HW, and compiler used in case of Tanglewood (coded in C) generated that.

I really don't get their approach in this: what this means: "The Dn mode is used when the destination is a data register, the destination < ea > mode is invalid for data register"
So, Dn mode is valid too, but they excluded it from table, as table is only for alterable memory addressing modes ??? Then why no specific mentioning that this opcode works with data register as destination too ???


I think there are 3 different mnemonics because they don't use the same opcodes bits, especially "opmode"
- ADD allows "ea + dn -> dn" and "dn + ea -> ea"
- but ADDA and ADDI only allow "ea + an -> an" and "ea + dn -> dn", not the opposite
This is what table b) in ADD page 4-6 tells : you can't do "add.l d0,#1456", but you can do "add.l #1456,d0" (table a) )
In the end, I agree "add #imm,ea" and "addi #imm,ea" are similar and take the same, but they differ in their inner execution.
Using yacht.txt, we see for example :

Code: Select all

add.l #data,dn        instr exec time = 8(1/0) ea exec time = 8(2/0)
addi.l data,dn        instr exec time = 16(3/0) ea exec time = 0(0/0)

So, both take 16 cycles, but they are not done in the same way.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Thu Aug 14, 2014 9:33 am

AtariZoll wrote:I made simple test program, which just tries all opcodes in order, starting from $0000 . Generating log file, which is 256 KB long, as for each opcode needs 4 bytes - 2 is opcode self, and ASCI "VA" if caused not illegal exception, or ASCI "IN" if caused illegal. This allows easy comparison of diverse log files, made on diverse HW or emulators. At end count of invalid opcodes is written as word.
I added some filter, to skip branching instructions, reset etc. But it happens that some values cause double bus errors, what halts CPU, or in case of emulators initializes restart, with cleared RAM (Steem) . Problem happens with $2E3E, $2E3F ... , so I limited for now test with $2E3E, just to see the results on real ST and emulators.
Count of invalids on real HW is $0BD4, Steem 3.2 - $0936 , Hatari 1.8 - $0A3B . Problematic cmp.l #data,label(pc) opcode is VA in Hatari, and IN on real HW, as is stated already. I looked so far only some opcodes detected as VA in Steem, which are IN on real HW. Range $1008-$100F :
move.b a0,d0 - of course it is invalid as no byte size allowed with address registers. So, there are Steem bugs in CPU emulation too .
All this needs more time for looking other differences.

Hello
could you post the 3 tables you get (ST, Steem, Hatari) once you finish your tests ?

As for "move.b a0,d0" and more generally "move.b an,ea", this one are looking special.
The doc page 4-118 says "For byte size operation, address register direct is not allowed", which matches your test with opcodes $1008 - $100F.
But in the protection of Blood Money (in Superior 65 compil for example), they used "move.b a1,(a0)" (opcode 1089) and if this generates an illegal instruction, then the game will crash. That's why I allowed move.b with An as source in Hatari, even if it goes against what is written in the doc (and I guess that why Steem allowed it too).
Now, it seems move.b with An as source is possible with some destination ea, but not with some others :(

Nicolas

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Thu Aug 14, 2014 9:38 am

That's not what I complained for. The problem is that add.l #data,Dn is marked as invalid in table with destinations, while it works on real HW . And that's normal that works.
Of course that #data can not be destination - it is never it..
Maybe they consider as destination only memory, and not CPU registers ?

Here are test logs:
OPCLOGS.ZIP


Latest letter in names shows on what is done: R - real HW, H - Hatari, S - Steem.
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Thu Aug 14, 2014 9:52 am

AtariZoll wrote:That's not what I complained for. The problem is that add.l #data,Dn is marked as invalid in table with destinations, while it works on real HW . And that's normal that works.
Of course that #data can not be destination - it is never it..
Maybe they consider as destination only memory, and not CPU registers ?

For me, doc is correct, I read it this way :
- for operations looking like "<ea> + dn -> dn", then table a) applies, and "add #data,dn" is valid in table with destination in that case
- for operations looking like "dn + <ea> -> <ea>" (eg "add d0,(a1)"), then table b) applies, and then it's normal that #data is marked as invalid ; but "add #data,dn" does not enter in that category.

So the doc doesn't say that "add #data,dn" is invalid, it says that "add dn,#data" is invalid and "add #data,dn" is valid

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Thu Aug 14, 2014 1:08 pm

I added some corrections, and now it goes through all 65536 combinations. Disabled writes to SP (LEA and MOVEA to A7, replaced Trap #0-s after test loc with nop-s . But will not publish it for now, as it crashes machine after saving, so need some better recovery code - probably some HW registers were accidentaly written too. Or TOS workspace (low RAM) .
What is interesting is that because changing trap #0 with nop, after tested opcode, in Steem got some different results for same opcodes. Hatari and real HW gave same results . So, in case of Steem, it depends on value after opcode too, will it be illegal or not.

OPCOLG2.ZIP


Considering Blood Money - on real HW $1089 causes illegal. So, those changes you made in Hatari and Steem are just hacks, but not correct CPU emul. It works most likely because avoided not 100 % properly emulated illegal, or some bus error, address error, what follows illegal on real HW. Blood Money is known for that it's STX image works not in Steem, and I looked little in it earlier. The problem is for sure in mentioned exceptions emulation, what is used very tricky, starting from bootsector. It places stack very low, in vector area, so any small error will make it not work well. I'm not sure what Steven Seagal corrected in Steem SSE to make Blood Money STX work.
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Thu Aug 14, 2014 1:21 pm

AtariZoll wrote:Considering Blood Money - on real HW $1089 causes illegal. So, those changes you made in Hatari and Steem are just hacks, but not correct CPU emul. It works most likely because avoided not 100 % properly emulated illegal, or some bus error, address error, what follows illegal on real HW. Blood Money is known for that it's STX image works not in Steem, and I looked little in it earlier. The problem is for sure in mentioned exceptions emulation, what is used very tricky, starting from bootsector. It places stack very low, in vector area, so any small error will make it not work well. I'm not sure what Steven Seagal corrected in Steem SSE to make Blood Money STX work.

OK, I would need to check again this case ; fix in Hatari was made in 2008, that's 6 years old and it could be related to something else that was fixed elsewhere since then.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Thu Aug 14, 2014 1:28 pm

AtariZoll wrote:I added some corrections, and now it goes through all 65536 combinations. Disabled writes to SP (LEA and MOVEA to A7, replaced Trap #0-s after test loc with nop-s . But will not publish it for now, as it crashes machine after saving, so need some better recovery code - probably some HW registers were accidentaly written too. Or TOS workspace (low RAM) .
What is interesting is that because changing trap #0 with nop, after tested opcode, in Steem got some different results for same opcodes. Hatari and real HW gave same results . So, in case of Steem, it depends on value after opcode too, will it be illegal or not.

OPCOLG2.ZIP


Comparing Hatari and real HW, I see there're not that many differences, I need to look opcodes in details (there're certainly the cases for cmpi and also btst I fixed recently, as well as the move.b An)
In case you're interested, you can use this daily build of Hatari http://antarctica.no/~hatari/latest/windows/, it already has the fixes for cmpi/btst and should give better results.

EDIT : here're the main differences I saw with Hatari, per opcode family (I listed only one example per case) :

Code: Select all

083c 0000 0000 0000 0000 BTST.B #$0000,#$00
-> btst on #imm, already fixed

Code: Select all

0c7b 0000 0000 0000 0000 CMP.W #$0000,(PC, D0.W*1, $00)
-> cmpi with d(pc), already fixed

Code: Select all

4a3b 0000 0000 0000 0000 TST.B (PC, D0.W*1, $00) == $00050002
4a3c 0000 0000 0000 0000 TST.B #$00
4abc 0000 0000 0000 0000 TST.L #$00000000
-> similar to cmpi, need to be fixed

Code: Select all

4a49 0000 0000 0000 0000 TST.W A1
-> An not allowed, need to be fixed

Code: Select all

4e74 0000 0000 0000 0000 RTD.L #$0000
-> only valid for 68010 and more, need to be fixed in 68000 mode

Apart from that, I also saw some strange values in your files for Hatari :

Code: Select all

4d91 0000 0000 0000 0000 CHK.W (A1),D6
-> it says V[ instead of VA for opcode 4d91 ; maybe something overwrote memory in your test program ?

Code: Select all

R2 : ab d4 56 41 ab d5 56 41  ab d6 56 41 ab d7 56 41  |«ÔVA«ÕVA«ÖVA«×VA|
H2 : ab d4 56 41 ab d5 56 41  ab 3c 56 41 ab d7 56 41  |«ÔVA«ÕVA«<VA«×VA|
-> in H2, we see opcode "abd6" was replaced by "ab3c"

Thanks a lot for your test results, I should be able to provide a fixed Hatari in a few days.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Thu Aug 14, 2014 2:45 pm

That's the purpose - to find possible errors in CPU emulation.
Surely, tested code writes on random places still. Something like : move.l something,d(an,Ix) can write everywhere.
I will add setting all data registers to 0 before executing opcode test, + likely, it will be best to have bunch of 0-s after tested opcode word.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Invalid addressing modes, assembler problems ..

Postby AtariZoll » Thu Aug 14, 2014 5:19 pm

Here is the final 68000 version, I think. It now trashes not output file as I see, and return to Desktop is with usable system - restored well.

In attachment is executable, it's ASM source, short textual file with usage, some explanations. And 4 LOG files: Real ST, Steem 3.2, Steem SSE 3.6 and Hatari 1.8 .

OPCVAT3.ZIP
You do not have the required permissions to view the files attached to this post.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
npomarede
Atari God
Atari God
Posts: 1305
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Invalid addressing modes, assembler problems ..

Postby npomarede » Thu Aug 14, 2014 10:27 pm

Hello
when I run it under Hatari (tos 1.04, 2 MB RAM), I get a double bus error for opcode 4e58 'unlk a0'

Code: Select all

Bus Error at address $e00000, PC=$f5c6 f5c4 4e58
Detected double bus error at address $e00000, PC=$f5c6 => CPU halted!
> d f5c0
$00f5c0 : 7c00                                 moveq     #0,d6
$00f5c2 : 7e00                                 moveq     #0,d7
$00f5c4 : 4e58                                 unlk      a0

In that case, I see A0=0 (others An=e00000). Did you get a similar problem at some points ?


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 4 guests