I will leave Dzz's thread alone for a while and live in mine.
I am going to harp on this again, a quote from the MP2520f data sheet:
"MP2520F can handle four parallel data access operations through allowing four out of nine bus master to access one of the four internal data buses independently and concurrently."
I think they mean four of the
"one DRAM memory bus, one Non-DRAM memory & Fast I/O bus, one I/O Peripheral bus and one local data bus".
This means two processors can be faster than one if you arrange them right. Have to figure out how to do that.
Moving data from the 920 to the 940 is a delicate procedure. You should not (IMO) have the shared memory cached from the 920 side. It doesnt buy you any performance, in fact it slows you down as you have to flush the cache. the write buffer will help if you are doing a memcpy from cache to non-cached wb enabled ram. or if you are inventing the data. preferrably writing in words or quad words instead of bytes to take full advantage of the write buffer.
On the 940 you want to move the data out of the way, unless you are double buffering, so that the 920 can work on the next block of data while the 940 is working on the current block. This means memcpy again (for a single buffer).
So I had this fear that memcpy wasnt optimized, gotta test, gotta know.
The first one I happened to find was this one
.global _gmemcopy
_gmemcopy:
mov ip,#0
b gmemtest
gmemtop:
ldrb r3,[ip,r1]
strb r3,[ip,r0]
add ip,ip,#1
subs r2,r2,#1
gmemtest:
bcs gmemtop
bx lr
(Renamed it so I could test it independent of whatever memcpy the compiler used).
Which is exactly the kind of thing I was afraid of. Then I wrote these to compare speeds
.global wcopy
wcopy:
cmp r2,#0
b wtest
wtop:
ldr r3,[r1],#4
str r3,[r0],#4
subs r2,r2,#4
wtest:
bhi wtop
bx lr
.global xcopy2
xcopy2:
stmdb r13!,{r4}
cmp r2,#0
b xtest2
xtop2:
ldmia r1!,{r3-r4}
stmia r0!,{r3-r4}
subs r2,r2,#8
xtest2:
bhi xtop2
ldmia r13!,{r4}
bx lr
.global xcopy4
xcopy4:
stmdb r13!,{r4-r6}
cmp r2,#0
b xtest4
xtop4:
ldmia r1!,{r3-r6}
stmia r0!,{r3-r6}
subs r2,r2,#16
xtest4:
bhi xtop4
ldmia r13!,{r4-r6}
bx lr
Basically copy 4 bytes at a time, 8 or 16.
And as expected my xcopys were around 4 times faster. Assuming we really do have a 32 bit data bus (which this confirms) one read or write cycle can move 4 bytes (32 bits). an strb or ldrb only gives 8 bits per cycle with 24 bits unused, a big waste. Had it been 2 times faster that would have indicated a 16 bit data bus.
Before posting this I looked for some C source for memcpy as the above looks very much like compiled C instead of asm. I had just started using a new to me compiler, winarm. gcc 4.1.1, built for embedded and runs on windows, supposedly with newlib. but none of the memcpys in gcc or newlib looked like this (there were more than one in each place). In fact the new lib ones were huge, trying to decide direction to copy and what size chunks to use. So I changed back to my compiler with newlib, sure enough newlib's memcy was only slightly slower than the word, double word and quad word above. Granted memcpy has the overhead of actually copying every byte which the test functions above dont.
Then I downloaded glibc and uClibc to see their memcpy's. Turns out between gcc, newlib, glibc and uClibc there were several memcpy's. uClibc was the only one with any assembler.
bottom line there is no rule on what memcpy you are going to get. at a minimum fill up the bus on every cycle. ldm/stm pairs will take advantage of the write buffer if you are in a situation to take advantage of it. Any read from memory drains the write buffer first, so if you are executing out of non-cached memory the write buffer drains and you gained nothing. If your source is not cached, then the write buffer drains and you gain nothing. I did not try an exhaustive test on various copy lengths, I did, interestingly see 2048 do much better than 8192 bytes for one of the off the shelf memcpys (maybe the one in devkitGP2X).
Hmm, did I mention above the devkitGP2X's memcpy, was between 1.5 and 2.0 times slower than the 1, 2, and 4 word copies above?