68k instruction cycles

All 680x0 related coding posts in this section please.

Moderators: Zorro 2, Moderator Team

User avatar
thothy
Hatari Developer
Hatari Developer
Posts: 451
Joined: Fri Jul 25, 2003 9:36 am

68k instruction cycles

Post by thothy »

Hi everybody!

Is there a list with validated 68000 CPU instruction cycles? I know a lot of cycles lists (e.g. Motorolas 68k User Manual), but it seems that most of them are wrong on the ST. For example "movep.l" is listed with 24 cycles in all texts that I've seen so far, however, it seems to me that a "movep.l" needs 28 cycles on a real ST.
So can somebody help me?

Thothy
User avatar
Zorro 2
Administrator
Administrator
Posts: 2310
Joined: Tue May 21, 2002 12:44 pm
Location: Grenoble (38) - France

Post by Zorro 2 »

Try to join Warrior Munk (http://w3.informatik.gu.se/~a01andy/) for more information...

Code: Select all

               MC68000 Instruction Execution Times

               -----------------------------------



  These are the times for instructons, most of it is self explainitory.
  On the ST at 8 Mhz you need to round all times to multiples of four.
  i.e 10 becomes 12. Please note that  execution instruction times are
  generally irrelevant when you have a instruction cache, ie a greater
  than 68000  processor and i doubt that these numbers will hold true
  for anything except a 68000 even if you turn the cache off. Also note
  that it isn't usually worth spending ages trying to optimise your code
  by using faster instructions. If you're code is too slow, then you will
  probably need to use a different method to achieve you're aims.



MOVE Instructions:

                                               d(an
.b.w/.l    dn   an     (an)  (an)+ -(an) d(an) .Ri)  abs.s abs.l



dn         4/4   4/4    8/12  8/12  8/14 12/16 14/18 12/16 16/20
an         4/4   4/4    8/12  8/12  8/14 12/16 14/18 12/16 16/20
(an)       8/12  8/12  12/20 12/20 12/20 16/24 18/26 16/24 20/28
(an)+      8/12  8/12  12/20 12/20 12/20 16/24 18/26 16/24 20/28
-(an)     10/14  10/14 14/22 14/22 14/22 18/26 20/28 18/26 22/30
d(an)     12/16  12/16 16/24 16/24 16/24 20/28 22/30 20/28 24/32
d(an,Ri)  14/18  14/18 18/26 18/26 18/26 22/30 24/32 22/30 26/34
Abs.s     12/16  12/16 16/24 16/24 16/24 20/28 22/30 20/28 24/32
Abs.l     16/20  16/20 20/28 20/28 20/28 24/32 26/34 24/32 28/36
d(pc)     12/16  12/16 16/24 16/24 16/24 20/28 22/30 20/28 24/32
d(pc,Ri)  14/18  14/18 18/26 18/26 18/26 22/30 24/32 22/30 26/34
Immediate  8/12   8/12 12/20 12/20 12/20 16/24 18/26 16/24 20/28



----------------------------------------------------------------------

 Time to calculate effective addresses.

                                 d(an                    d(pc
          (an) (an)+ -(an) d(an) .Ri)  abs.s abs.l d(pc) .ri)  Imm
 .b.w/.l  4/8  4/8   6/10  8/12  10/14 8/12  12/16 8/12  10/14 4/8


The time taken to calculate the effective address must be added to
       instructions that affect a memory address.

----------------------------------------------------------------------

Standard Instructions:

.b.w/.l   ea,an   ea,dn   dn,mem

add       8/6(8)  4/6(8)  8/12    (8) time if effective address
and        -      4/6(8)  8/12    is direct
cmp       6/6     4/6      -
divs       -      158max   -          Add effective address times
divu       -      140max   -          from above for memory
eor        -      4/8     8/12        addresses.
muls       -      70max    -
mulu       -      70max    -
or         -      4/6(8)  8/12
sub       8/6(8)  4/6(8)  8/12



Immediate Instructions


.b.w/.l  #,dn  #,an  #,mem

addi     8/16   -    12/20
addq     4/8   8/8    8/12   Moveq.l only
andi     8/16   -    12/20   nbcd+tas.b only
cmpi     8/14  8/14   8/12
eori     8/16   -    12/20   scc false/true
moveq     4     -      -
ori      8/16   -    12/20   add effective address
subi     8/16   -    12/20   times from above
subq     4/8   8/8    8/12   for mem addresses
clr      4/6   4/6   8/12    single operand
nbcd      6     6     8      instructions
neg      4/6   4/6   8/12
negx     4/6   4/6   8/12
not      4/6   4/6   8/12
scc      4/6   4/6   8/8
tas       4     4    10
tst      4/4   4/4   4/4



Shift/rotate instructions.


.b.w/.l   dn    an   mem

asr,asl   6/8   6/8   8      memory is byte only
lsr,lsl   6/8   6/8   8      register add 2x
ror,rol   6/8   6/8   8      shift count
roxr,roxl 6/8   6/8   8



                                  d(an                   d(pc
         (an)  (an)+  -(an) d(an) .ri) abs.s abs.l d(pc) .ri)

jmp      8     -      -     10    14   10    12    10    14
jsr      16    -      -     18    22   18    20    18    22
lea      4     -      -     8     12   8     12    8     12
pea      12    -      -     16    20   16    20    16    20

movem t=4
m>r      12    12     -     16    18   16    20    16    18

movem t=5
r>m      8     -      8     12    14   12    16    -     -


movem   add t x number of registers for .w
movem   add 2t x number of registers for .l



Bit Instructions


.b/.l   register .l    memory .b
           only        only

bchg     8/12          8/12
bclr    10/14          8/12
bset     8/12          8/12
btst     6/10          4/8



Exceptions       Periods

Address Error    50
Bus Error        50
Interrupt        44
Illegal Instr.   34
Privilege Viol.  34
Trace            34



Other Instructions

add effective address times from above for memory addresses


.b.w/.l  dn,dn    m,m

addx      4/8    18/30
cmpm       -     12/20
subx      4/8    18/30
abcd       6      18      .b only
sbcd       6      18      .b only
Bcc      .b/.w   10/10      8/12
bra      .b/.w   10/10       -
bsr      .b/.w   18/18       -
DBcc      t/f      10      12/14
chk        -       40 max    8
trap       -       34        -
trapv      -       34        4

                 reg<>mem

movep   .w/.l   16/24

              Reg   Mem                     Reg

andi to ccr   20     -       move from usp    4
andi to sr    20     -       nop              4
eori to ccr   20     -       ori to ccr      20
eori to sr    20     -       ori to sr       20
exg            6     -       reset          132
ext            4     -       rte             20
link          18     -       rtr             20
move to ccr   12    12       rts             16
move to sr    12    12       stop             4
move from sr   6     8       swap             4
move to usp    4     -       unlk            12
.~^ Member of NoExtra Team :: Member of HMD :: Pouet :: DemoZoo :: GitHub ^~.
User avatar
thothy
Hatari Developer
Hatari Developer
Posts: 451
Joined: Fri Jul 25, 2003 9:36 am

Post by thothy »

Thanks for your reply, Zorro2, but the list you attached seems to have the same problems as all the others:
movep .w/.l 16/24
--> "movep.l" is also listed with 24 cycles there, not with 28 :(
User avatar
frost
Captain Atari
Captain Atari
Posts: 396
Joined: Sun Dec 01, 2002 2:50 am
Location: Limoges

Post by frost »

that's strange... on my Ste, movep.l seems to take 6 nops, so 24 cycles..
User avatar
frost
Captain Atari
Captain Atari
Posts: 396
Joined: Sun Dec 01, 2002 2:50 am
Location: Limoges

Post by frost »

oops..

movep.l dx,(ax) is 6 nops...
maybe you use movep.l dx,offset(ax) which may add a nop to read the offset to the address register.
Perihelion

Post by Perihelion »

The only sure way is to try it out yourself :)
I use complete border busting code, since that needs to be timed down to the very last cycle (or 4th since all cycle times are divisable by four).
This can't be tested in STEem though since STEem is lenient with the timings, but has to be done on real atari. I also haven't tested many "platforms" (ST/STe, different computers might differ (?) memory capacity and so forth).
As an alternative approach you could contact the STEem authors, since I think they have every cycle time down except multiplication and division.
Hmmm ... don't have any generic board buster code where I'm at now, but I'll post it if anyones interested.
User avatar
thothy
Hatari Developer
Hatari Developer
Posts: 451
Joined: Fri Jul 25, 2003 9:36 am

Post by thothy »

frost wrote: movep.l dx,(ax) is 6 nops...
maybe you use movep.l dx,offset(ax) which may add a nop to read the offset to the address register.
Ok, thanks for the hint, this might be a possibility. Indeed I was refering to a movep.l dx,offset(ax). However, according to Motorolas M68000 User's Manual (MC68000UM.pdf), the movep instructions aren't marked with a "you have to add effective address timing" label - that's why I thought that a movep.l always needs 24 cycles.
Well, the best solution is probably to really check it on a real ST with a cycle counting programm... But then I wonder if there are more instructions like this movep.l that aren't correctly described in the MC68000UM.pdf and other cycle tables.
User avatar
frost
Captain Atari
Captain Atari
Posts: 396
Joined: Sun Dec 01, 2002 2:50 am
Location: Limoges

Post by frost »

warrior: that's exactly the way i do my "measures" :wink:
User avatar
Grazey / PHF
Atari Super Hero
Atari Super Hero
Posts: 571
Joined: Fri Jun 21, 2002 12:50 pm
Location: Montreal, Quebec

Post by Grazey / PHF »

I have Nick/TCB's cycle timing program if anyone wants it.

Cheers
GRZ
http://phf.atari.org - demo coders since 1983
http://sndh.atari.org - Maintainer of the Atari ST chip music archive
http://www.scenestream.net - Nectarine Administrator
User avatar
thothy
Hatari Developer
Hatari Developer
Posts: 451
Joined: Fri Jul 25, 2003 9:36 am

Post by thothy »

Grazey / PHF wrote:I have Nick/TCB's cycle timing program if anyone wants it.
That sounds interesting. Can you post it here or send it to me by PM?
User avatar
Zorro 2
Administrator
Administrator
Posts: 2310
Joined: Tue May 21, 2002 12:44 pm
Location: Grenoble (38) - France

Post by Zorro 2 »

Grazey / PHF wrote:I have Nick/TCB's cycle timing program if anyone wants it.

Cheers
GRZ
Please mister Grazey, you can post it on this topic ?
.~^ Member of NoExtra Team :: Member of HMD :: Pouet :: DemoZoo :: GitHub ^~.
User avatar
Grazey / PHF
Atari Super Hero
Atari Super Hero
Posts: 571
Joined: Fri Jun 21, 2002 12:50 pm
Location: Montreal, Quebec

Post by Grazey / PHF »

Ok, the code is pretty much self explanatory, just insert your code in the marked area.

Grz
You do not have the required permissions to view the files attached to this post.
http://phf.atari.org - demo coders since 1983
http://sndh.atari.org - Maintainer of the Atari ST chip music archive
http://www.scenestream.net - Nectarine Administrator
User avatar
frost
Captain Atari
Captain Atari
Posts: 396
Joined: Sun Dec 01, 2002 2:50 am
Location: Limoges

Post by frost »

Grazey, you rule !
User avatar
Zorro 2
Administrator
Administrator
Posts: 2310
Joined: Tue May 21, 2002 12:44 pm
Location: Grenoble (38) - France

Post by Zorro 2 »

Thanks a lot !!!
.~^ Member of NoExtra Team :: Member of HMD :: Pouet :: DemoZoo :: GitHub ^~.
damo
Atariator
Atariator
Posts: 25
Joined: Wed Mar 05, 2003 12:46 pm

Post by damo »

nice one Graz, just what I need :)

damo/rg
User avatar
thothy
Hatari Developer
Hatari Developer
Posts: 451
Joined: Fri Jul 25, 2003 9:36 am

68000 instruction cycles

Post by thothy »

For your information: Today I had some spare time to test TCB's cycle count program.
I was wrong, a movep.l really only needs 24 cycles on the ST.
BUT: If you access the PSG with a "movep.l d0,0(a0)" - with A0 = $FF8800 - then the instruction will need 28 instead of 24 cycles! And this also happens with other instructions, e.g. with a normal "move.l" when accessing the PSG registers! So there seem to be some wait-cycles as soon as the CPU accesses the PSG. Could this be? Can anybody confirm this strange behaviour?
User avatar
frost
Captain Atari
Captain Atari
Posts: 396
Joined: Sun Dec 01, 2002 2:50 am
Location: Limoges

Post by frost »

i have heard of it, but i can't remember where :)
Gunstick
Captain Atari
Captain Atari
Posts: 304
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg

Re: 68000 instruction cycles

Post by Gunstick »

thothy wrote: So there seem to be some wait-cycles as soon as the CPU accesses the PSG. Could this be? Can anybody confirm this strange behaviour?
digging in DSOTS source code...
found "playfield screen"
that screen has NO vbl, so even the sound has to be synchron.

compare code...
no sound

Code: Select all

        move.b  #2,$ffff8260.w
        move.b  #0,$ffff8260.w
        move.l  sp,$ffff825c.w

        ds.w 70-4-5,$4e71
        lea     32(a2),a2

        move.w  (a1)+,d2
        movem.l 0(a2,d2.w),d2-d3/d5/a7

;jumping raster
        subq.l  #4,d4
        beq     jump_rast
ras_back21:

        move.b  #0,$ffff820a.w
        move.b  #2,$ffff820a.w


with sound

Code: Select all

        move.b  #0,$ffff8260.w
        move.l  sp,$ffff825c.w

        movem.l stmspl.w,d0-d3/d5-a0/a5-a7
        movem.l d0-d3/d5-a0/a5-a7,$ffff8800.w

        ds.w 70-31-26-4-5,$4e71
        lea     32(a2),a2
        move.w  (a1)+,d2
        movem.l 0(a2,d2.w),d2-d3/d5/a7

;jumping raster
        subq.l  #4,d4
        beq     jump_rast
ras_back19:

        move.b  #0,$ffff820a.w
        move.b  #2,$ffff820a.w
and stmspl.w is in LOW memory so we can adress with .w (saves 1 NOP)
11 registers in long makes 22 nop + movem + abs.s = 26
now writing
11 regs = 22nop + movem + abs.s = 25
hmm... but there are 31 used...
so we get 6 nop waitstates for writing 11 longs to the soundchip

very strange.
but the emulators got it right (not at the first time, and I guess it was this bit which made the problem)

oh there are again those ULM-overscan switches :-)
Georges
User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1949
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: 68000 instruction cycles

Post by Greenious »

thothy wrote:For your information: Today I had some spare time to test TCB's cycle count program.
I was wrong, a movep.l really only needs 24 cycles on the ST.
BUT: If you access the PSG with a "movep.l d0,0(a0)" - with A0 = $FF8800 - then the instruction will need 28 instead of 24 cycles! And this also happens with other instructions, e.g. with a normal "move.l" when accessing the PSG registers! So there seem to be some wait-cycles as soon as the CPU accesses the PSG. Could this be? Can anybody confirm this strange behaviour?
I'm not 100% sure, but I think I can explain this.

I remember reading the datasheet for the PSG, and one thing that struck me was that some of the data I/O pins doubled as adresspins aswell.

The time needed to switch the mode of the datapins between adress/data mode could be the factor that adds the extra cycles to your move instruction.

I recommend you track down a datasheet of the PSG though.
User avatar
Cyrano Jones
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Wed May 28, 2003 8:28 pm

Post by Cyrano Jones »

Yeah its definatly different with the sound chip, it really messed up the ZoomRoom intro and I had to try various combinations to get it to work.

BTW, Gunstick - Your "Paralax Distorter" screen is just about the only screen that to this day I still can't work out how its done :-)

Maybe you could drop me a PM with some hints?
Perihelion

Post by Perihelion »

Maybe you could drop me a PM with some hints?
aaa, come now, that's cheating :)

Seriously though, it's cool that nowadays we (or rather you, since my kung fu is weak) share all those secret special techniques. It's like in a good ninja movie, first you have to keep your secrets, but then the world opens up and all the ninja clans have to join up in order to fight the big nasties (M$ if somebody missed that). ALl ninja clan happily share techniques and the world ends with the big nasties crushed.

weeeeeeee

if anyone missed it before; i'm a fan of martial arts movies! (and I do know that ninjas don't use kung fu)
Gunstick
Captain Atari
Captain Atari
Posts: 304
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg

Post by Gunstick »

Perihelion wrote:
Maybe you could drop me a PM with some hints?
aaa, come now, that's cheating :)
it's not explainable in a quick note. That's why I plan to make a more detailed website for some screens in the DSOTS. I spent 4 month coding on the parallax screen, cramming instruction after instruction into the overscan :-)

Georges
User avatar
thothy
Hatari Developer
Hatari Developer
Posts: 451
Joined: Fri Jul 25, 2003 9:36 am

Post by thothy »

Gunstick wrote: it's not explainable in a quick note. That's why I plan to make a more detailed website for some screens in the DSOTS.
Georges
Cool! That would be very interesting!

And thanks for the information about the PSG timing... I hope I'll get it correctly emulated one day in Hatari...
User avatar
Cyrano Jones
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Wed May 28, 2003 8:28 pm

Post by Cyrano Jones »

Thanks Gunstick, that would be great.

Return to “680x0”