Subject: Re: Sequential and non-sequential memory access

From: Rainer Dorsch <[email-masked]>
Date: Tue, 02 Feb 1999 09:55:42 +0100

My armulator was configured for the 7TDMI (BTW, can it simulate processors 
with cache?). I did not stress enough: I am not surprised from the sequence of 
addresses (which is clearly affected by the pipeline) but the sequential 
memory access signal from the ARM after the data was loaded.

Rainer.

> Hi,
> 
>   You are probably seeing a cache line fill and/or simple read ahead since
>   the Program Counter is ahead of the execute pipeline.
> 
> Bob Kondner
> 
> Rainer Dorsch wrote:
> 
> > The ARMulator (as the ARM chips) as signal, if a seqeuntial or non-sequential
> > memory access is requested. I found a strange behavior in armulator
> >
> > The program basically writes a string (hello world) to the console:
> >
> > HelloW
> > +0000 0x00008080: 0xe28f1010  .... :    add      r1,pc,#0x10
> > LOOP
> > +0000 0x00008084: 0xe4d10001  .... :    ldrb     r0,[r1],#1
> > +0004 0x00008088: 0xe3500000  ..P. :    cmp      r0,#0
> > +0008 0x0000808c: 0x1f000000  .... :    swine    0x0
> > +000c 0x00008090: 0x1afffffb  .... :    bne      LOOP
> > +0010 0x00008094: 0xef000011  .... : >  swi      0x11
> > Text
> > +0000 0x00008098: 0x6c6c6548  Hell :    stcvsl   p5,c6,[r12],#-0x120
> > +0004 0x0000809c: 0x6f57206f  o Wo :    swivs    0x57206f
> > +0008 0x000080a0: 0x0a646c72  rld. :    beq      0x1923270
> >
> > The address trace of this part is given below. The Load Byte is called delayed
> > due to the pipeline (as the reading of 8094 and 8098. But the strange thing is
> > that the instruction after the ldrb is a sequential cycle (8090). Does anybody
> > know why is this? Thanks.
> >
> > 00008084 (Load Instruction - non-sequential cycle)
> > 00008088 (Load Instruction - sequential cycle)
> > 0000808C (Load Instruction - sequential cycle)
> > 000080A3 (Load Byte - non - sequential cycle)
> > 00008090 (Load Instruction - sequential cycle)
> > 00008094 (Load Instruction - sequential cycle)
> > 00008098 (Load Instruction - sequential cycle)
> > 00008084 (Load Instruction - non-sequential cycle)
> > 00008088 (Load Instruction - sequential cycle)
> > 0000808C (Load Instruction - sequential cycle)
> > 000080A4 (Load Byte - non - sequential cycle)
> > 00008090 (Load Instruction - sequential cycle)
> > 00008094 (Load Instruction - sequential cycle)
> > 00008098 (Load Instruction - sequential cycle)
> > 00008084 (Load Instruction - non-sequential cycle)
> > 00008088 (Load Instruction - sequential cycle)
> > 0000808C (Load Instruction - sequential cycle)
> > 000080A5 (Load Byte - non - sequential cycle)
> > 00008090 (Load Instruction - sequential cycle)
> > 00008094 (Load Instruction - sequential cycle)
> > 00008098 (Load Instruction - sequential cycle)
> > 0000809C (Load Instruction - sequential cycle)
> >
> > --
> > Rainer Dorsch
> > Abt. Rechnerarchitektur  e-mail:[email-masked]
> > Uni Stuttgart            Tel.: 0711-7816-215
> >
> > unsubscribe: body of `unsubscribe linux-arm' to [email-masked]
> 

-- 
Rainer Dorsch
Abt. Rechnerarchitektur  e-mail:[email-masked]
Uni Stuttgart            Tel.: 0711-7816-215

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: [email-masked]
Date: Tue, 02 Feb 1999 10:48:42 +0000

>with cache?). I did not stress enough: I am not surprised from the sequence
>of addresses (which is clearly affected by the pipeline) but the sequential 

It could simply be a bug in the ARMulator.  I can't find my ARM7 data sheet 
right now so I'm not sure what the exact semantics for SEQ are supposed to 
be (the SA110 has a slightly different, and essentially pretty useless, 
meaning for this pin).

>>> 00008084 (Load Instruction - non-sequential cycle)

A cache fill would start at 0x8080 and run all the way up to 0x808c without 
interruption.  Also if the Icache was enabled the cpu wouldn't re-fetch the 
loop instructions.  So that doesn't look like it's what's happening.

p.