[Zlib-devel] [7/8][RFC V3 Patch] Blackfin implementation

Mike Frysinger vapier at gentoo.org
Tue Jul 5 16:51:48 EDT 2011


On Monday, May 09, 2011 13:42:05 Jan Seiffert wrote:
> I am doing them with caches turned on and with a blocksize of 160kb.
> Which is larger then the cache. And still see an speedup factor of
> 1.79. Or are the caches in some way prefetching in the background?
> If i limit the size to 16kb i see a speedup factor of 2.25.

the data caches dont prefetch.  i think you're seeing the 2-way aspect of 
Blackfin data caches ... while there is 32KiB of cache most the time, being a 
2-way means things fall off a little after 16KiB.

is this a tunable you can set somehow at build time ?  Blackfin systems would 
prefer 16KiB on cached setups ...

> > I am not sure of the need to set the circular buffer registers for I0?
> > Unless it is for added security against bugs/buffer overflows...
> 
> To be honest, i was guided by the misconception that addressing over
> In would not work when those register are not properly setup. Or more
> correct i'm still a little fuzzy with it. For example the ABI says
> that on function entry/exit the length register have to be cleared,
> but AFAIK not the base register. But as soon as the base register are
> set, doesn't that trigger circular addressing? Even with len=0?
> At least with that circular addressing the pointer never wandered into
> lala land during development.

the index registers always work for loads/stores.  the only time the 
len/base/modify regs come into play is when the len regs are non-zero and the 
index regs get modified (like "R0 = [I0++];" or "I0 += M0;").  otherwise, the 
base/modify regs are basically scratch regs for whatever you want (sometimes 
useful as an 8 word deep stack).

the reason the ABI says that the len regs must be cleared upon function entry 
is so that the compiler can generate load/stores using the index regs without 
first having to clear the len regs itself.  this occurs much more frequently 
than people using circular buffers, so we put the extra work on the heads of 
the people using the buffers.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://madler.net/pipermail/zlib-devel_madler.net/attachments/20110705/a9fb3ee3/attachment.sig>


More information about the Zlib-devel mailing list