On Wed, 9 Aug 2000, Zsolt Prievara wrote: > I read the 64doc and I found something what is very incomprehensible for me. > At the relative addressing I found the following: > > 1 PC R fetch opcode, increment PC > 2 PC R fetch operand, increment PC > 3 PC R Fetch opcode of next instruction, > If branch is taken, add operand to PCL. > Otherwise increment PC. > 4+ PC* R Fetch opcode of next instruction. > Fix PCH. If it did not change, increment PC. > 5! PC R Fetch opcode of next instruction, > increment PC. > > And a note: > > "When determining real execution times, remember to subtract the last > cycle." > > In the doc these instructions have 3/4/5 cycles for execution, but in my old > code I used 2/3/4. I included the last cycle in the description in order to make it easier to comprehend. Consider this example: $c0ff clc $c100 bcs $c0ff (branch not taken) $c102 bcc $c0ff (branch taken) 1 c0ff fetch "clc" 2 c100 fetch the operand for "clc" (thrown away) 3 c100 fetch "bcs" 4 c101 fetch the operand for "bcs" 5 c102 fetch "bcc" (during this fetch the processor notices that the "bcs" was not taken) 6 c103 fetch the operand for "bcc" 7 c104 fetch the next opcode (this is thrown away, as the branch is taken) 8 c1ff fetch the opcode of the branch target (oops, the high byte must be adjusted) 9 c0ff fetch "clc" ... (as in step 1) As you see, this loop takes 2+2+4=8 cycles. I see no contradiction. Marko --this message went through the plus4@c64.rulez.org emailing list---
Archive generated by hypermail 2.1.1.