Timings when writing an immediate to SR

All 680x0 related coding posts in this section please.

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

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1993
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Timings when writing an immediate to SR

Postby Steven Seagal » Sun Aug 28, 2016 2:03 pm

Hi,

In the YACHT timing tables, we find this for instructions that write an immediate to CCR/SR:

Code: Select all

-------------------------------------------------------------------------------
 ORI, ANDI, EORI  |    Exec Time    |               Data Bus Usage
  to CCR, to SR   |      INSTR      | 1st Operand |          INSTR
------------------+-----------------+-------------+----------------------------
#<data>,CCR       |                 |             |               
  .B :            | 20(3/0)         |          np |              nn nn np np   


The first np is when the immediate is being fetched (4 cycles, bus used), but I don't see the use of the nn nn (nn = 4 cycles, bus not used, the CPU is thinking) and one np.

The last np should correspond to "prefetch IRC" (next opcode) there is at the end of most instructions.

For info, here's the table for the same instructions used on anything else than SR:

Code: Select all

-------------------------------------------------------------------------------
 EORI, ORI, ANDI, |    Exec Time    |               Data Bus Usage
    SUBI, ADDI    |  INSTR     EA   | 1st Operand |  2nd OP (ea)  |   INSTR
------------------+-----------------+-------------+---------------+------------
#<data>,<ea> :    |                 |             |               |
  .B or .W :      |                 |             |               |
    Dn            |  8(2/0)  0(0/0) |          np |               | np         
    (An)          | 12(2/1)  4(1/0) |          np |            nr | np nw        
    (An)+         | 12(2/1)  4(1/0) |          np |            nr | np nw        
    -(An)         | 12(2/1)  6(1/0) |          np | n          nr | np nw        
    (d16,An)      | 12(2/1)  8(2/0) |          np |      np    nr | np nw        
    (d8,An,Xn)    | 12(2/1) 10(2/0) |          np | n    np    nr | np nw        
    (xxx).W       | 12(2/1)  8(2/0) |          np |      np    nr | np nw        
    (xxx).L       | 12(2/1) 12(3/0) |          np |   np np    nr | np nw        
  .L :                              |             |               |
    Dn            | 16(3/0)  0(0/0) |       np np |               | np       nn   
    (An)          | 20(3/2)  8(2/0) |       np np |         nR nr | np nw nW   
    (An)+         | 20(3/2)  8(2/0) |       np np |         nR nr | np nw nW   
    -(An)         | 20(3/2) 10(2/0) |       np np | n       nR nr | np nw nW   
    (d16,An)      | 20(3/2) 12(3/0) |       np np |      np nR nr | np nw nW   
    (d8,An,Xn)    | 20(3/2) 14(3/0) |       np np | n    np nR nr | np nw nW   
    (xxx).W       | 20(3/2) 12(3/0) |       np np |      np nR nr | np nw nW   
    (xxx).L       | 20(3/2) 16(4/0) |       np np |   np np nR nr | np nw nW   


For example, when writing a word on a data register, there's just a np for the immediate fetch, another for "prefetch IRC". This is straightforward.
Can somebody explain the different timings for SR?

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Timings when writing an immediate to SR

Postby ijor » Sun Aug 28, 2016 5:18 pm

Well. Writing to SR is, internally, quite different than writing to a regular register. The most important difference is that the prefetch must be flushed and filled again. This is because the instruction might have changed mode from SUPER to USER (other way around is not possible, it would trigger a privilege violation). And some systems use a different memory map for each mode. Then the prefetch must be filled again, now with the new mode. Yes, just in case.

Not only that, it can't refill the prefetch until the write to SR and the possible mode change has been completed internally. So they can't overlap.

Steven Seagal wrote:The first np is when the immediate is being fetched (4 cycles, bus used)


Nope. The immediate operand was already prefetched by the previous instruction. Every single instruction starts with two words in the prefetch. The opcode and one extra word. The first np fetched the opcode for the next instruction or whatever was at that location, which in this case is completely wasted because it will be flushed. And the wastefull bus cycle is because the instruction just reuses the same microcode as every other immediate instruction for that part.

Yes, not the most optimized 68K instruction.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1993
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Timings when writing an immediate to SR

Postby Steven Seagal » Sun Aug 28, 2016 6:54 pm

ijor wrote:Well. Writing to SR is, internally, quite different than writing to a regular register. The most important difference is that the prefetch must be flushed and filled again. This is because the instruction might have changed mode from SUPER to USER (other way around is not possible, it would trigger a privilege violation). And some systems use a different memory map for each mode. Then the prefetch must be filled again, now with the new mode. Yes, just in case.

Not only that, it can't refill the prefetch until the write to SR and the possible mode change has been completed internally. So they can't overlap.


Thx ijor, I was thinking you could answer that question.



Nope. The immediate operand was already prefetched by the previous instruction. Every single instruction starts with two words in the prefetch. The opcode and one extra word. The first np fetched the opcode for the next instruction or whatever was at that location, which in this case is completely wasted because it will be flushed.


Yes, it was prefetched, but using the word provokes another prefetch at that moment, I didn't express it correctly.


And the wastefull bus cycle is because the instruction just reuses the same microcode as every other immediate instruction for that part. Yes, not the most optimized 68K instruction.


I see, that's why it doesn't make sense at once.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 1 guest