Previous | Next
| From: Marko_Mäkelä
Date: 2000-08-09
Subject: Re: Relative addressing
|
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
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
