From: Russell King - ARM Linux Admin <[EMAIL PROTECTED]>
Date: Wed, 5 May 1999 23:43:42 +0100 (BST)
Deborah Wallach writes:
> I think you're misreading the (incredibly cryptic) instruction timing
> table. What mine says is:
>
> Instruction Group Result Delay Issue Cycles
> ------------------------------------- ------------ ------------
> load single - writeback of base 0 1
> load single - load data zero extended 1 1
> load single - load data sign extended 2 1
That's identical to both copies that I have here.
> The first case should only apply to the use of the base register (eg the PC
> in Christophe's example, since his loads are PC-relative). Since the next
> instruction isn't using the PC, but rather the result of the LDR, this
> timing doesn't apply.
Why doesn't it? The wording given is 'The result delay is the number
of cycles the next sequential instruction would stall if it used the
result as an input'. I read this as saying that you can ignore the
result delay, unless the next instruction uses the previous result.
I interpret the phrase "load single - writeback of base" to mean:
"the class of instructions is a load single, and the result delay that we
are talking about is for the base register".
Hence, a ldr r0, [r1], #0 falls into the first category quite definitely,
since there is writeback of base and there isn't and data extending being
performed...
No, it falls into both categories, depending on which register you are
going to use. Consider the difference between:
ldr r0, [r1], #4
eor r2, r2, r1
and
ldr r0, [r1], #4
eor r2, r2, r0
In the first case, you need to know the timing of when _r1_, the base
register, gets written back. This is a result delay of 0.
In the second case, you need to know the timing of when r0, the actual load
data, is available. This is a result delay of 1.
-Debby
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
