Re: Relative addressing

From: Marko Mäkelä (
Date: 2000-08-09 11:42:16

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.


--this message went through the emailing list---

Archive generated by hypermail 2.1.1.