gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

ASM > Sequential vs. Non-Sequential

#16209 - poslundc - Tue Feb 10, 2004 5:28 pm

Inspired by the other topic recently posted here, I'm just interested in probing more into the nature of the memory controller and how it works with different instructions.

Take the following example case, running from ROM. We know that this code will take advantage of sequential reads to load the instruction:

Code:
   mov      r1, r0
   add      r1, r0, r1


But that this one won't, because of the branch:

Code:
   b      nextstatement
nextstatement:
   mov      r1, r0


What about an instruction that loads from the ROM, though? I would assume that it would also cause a miss:

Code:
   mov      r0, #0x08000000
   ldr      r1, [r0]
   mov      r0, r1   @ should be a non-sequential instruction (?)


How about an instruction that accesses internal/external RAM instead of the ROM? Does that affect the sequential reading of instructions?

Code:
   mov      r0, #0x03000000
   str      r1, [r0]
   mov      r0, r1   @ would this be a sequential instruction or not?


Finally, to look at things from the reverse direction... if I am running code from IWRAM and it is reading data from the ROM, does the memory controller lose its sequentiality between multiple ROM reads if I don't use a ldmia?

For example, the following code running in IWRAM (or anywhere) will take advantage of sequential access:

Code:
   ldmia   r0, {r1, r2}


But if it was done the following way, where the memory controller must load the next instruction from IWRAM, would it be able to maintain sequential reading from ROM:

Code:
   ldr      r1, [r0], #4   @ next ROM read is sequentially ordered...
   ldr      r2, [r0]      @ ... but is it read sequentially if the load instruction must first be read from IWRAM?


I realize that there are also pipelining issues to consider in all of these questions - so it would actually be an instruction further down being fetched while the others are being executed - but please bear in mind these are only examples to illustrate the question, and the nature of the problem (which is how the memory controller decides what's sequential) stays the same with or without pipelining.

These are details that I've puzzled over for the past longish while but never really formulated as a proper question. Any help solving the mystery is appreciated. :)

Dan.

#16215 - animension - Tue Feb 10, 2004 7:38 pm

An excellent set of questions Dan! I've been mulling over the same questions myself for a while now and would love to gain some insight as well :)
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin

#16220 - torne - Tue Feb 10, 2004 8:32 pm

I could be wrong about any of the following, but from my understanding of the GBA memory hardware and my knowledge of the ARM pipeline:

poslundc wrote:
What about an instruction that loads from the ROM, though? I would assume that it would also cause a miss:

Code:
   mov      r0, #0x08000000
   ldr      r1, [r0]
   mov      r0, r1   @ should be a non-sequential instruction (?)


That will cause a future instruction fetch to be non-sequential, yes; but not the immediately following instruction. ARM7 is pipelined with three pipeline stages: Decode, RegRead/ALU, and Memory/RegWrite. At the time the ldr instruction reaches the memory stage, the mov instruction is copying r1 into the ALU, and the *next* instruction is due to be fetched. The fetch of the next instruction will not be able to proceed as the memory bus is in use by the read for the ldr (memory stage always takes precedence over instruction fetches); once the ldr completes, the next instruction will be non-sequentially fetched. This leaves an empty pipeline slot between the mov and the next instruction.

Quote:
How about an instruction that accesses internal/external RAM instead of the ROM? Does that affect the sequential reading of instructions?

Code:
   mov      r0, #0x03000000
   str      r1, [r0]
   mov      r0, r1   @ would this be a sequential instruction or not?


That should still be sequential; the sequential/non-seq stuff is only affected by accesses to ROM. Again, a pipeline slot is left empty as the instruction following 'mov' is scheduled to be fetched at the same time as the str is writing; the chip has only one memory channel and no cache, so can't fetch the instruction at the same time.

Quote:
Finally, to look at things from the reverse direction... if I am running code from IWRAM and it is reading data from the ROM, does the memory controller lose its sequentiality between multiple ROM reads if I don't use a ldmia?

For example, the following code running in IWRAM (or anywhere) will take advantage of sequential access:

Code:
   ldmia   r0, {r1, r2}


But if it was done the following way, where the memory controller must load the next instruction from IWRAM, would it be able to maintain sequential reading from ROM:

Code:
   ldr      r1, [r0], #4   @ next ROM read is sequentially ordered...
   ldr      r2, [r0]      @ ... but is it read sequentially if the load instruction must first be read from IWRAM?


This is the case I'm not sure about; I don't really know how the sequential read is implemented in hardware. If it's done by strobing, then it should be possible to read sequentially even when there is a gap between accesses; however, if it's automatic or some other method is used, it may only be able to read sequentially on consecutive clock cycles.

If you want to find out the answers to all these with no speculation at all involved, write code with examples of all of them and profile it on real hardware, then compare the results to a static timing analysis performed under varying assumptions until one matches.

All the above are affected by prefetch as well, of course, in further complicated ways. =)

EDIT: actually, my comment about the third case applies to the second as well. Does anyone know the exact hardware mechanism used for the cart bus? no$ says only how non-sequential accesses are performedn, afaict, and I can't find mention at all in cowbite.

#16251 - Large Metal Teeth - Wed Feb 11, 2004 5:05 am

The GBA cartridge has hardware counters that increment when the GBA Game Pak Bus's read line is strobed. The ROM does not need to be read on successive clock cycles.

#16268 - torne - Wed Feb 11, 2004 1:17 pm

Thanks, Large Metal Teeth; in which case, the answers to the above are that the second and third cases shouldbe sequential.