I think prefetch instuction should be supported in C64x+

Vladimir Vassilevsky wrote:
> 
> So, there is a gain only due to the fact that the cache lines are not 
> allocated on writes, but only on reads. But then the initial cache miss 
> will result in even longer stall because the dirty cache line should be 
> flushed before it is fetched.

That's it. L1D can't be configured to write-allocate. The stall won't be 
longer though. The write-back has already been factored in.

> This is not so obvious. It couid be a gain, it could be a loss depending 
> on the particular access pattern.

Yep. There are access patterns where pre-loading does more harm than 
good. With some experience you'll see these loops and don't pre-load.

Algorithms that use huge coefficient-arrays are potential candidates, 
but these benefit from moving the read-only data to internal ram anyway.

For the worst-case cache-access patterns like accessing the cache with a 
stride of 32 bytes and thus causing a cache write-back and cache-line 
fill per access it's a good idea to turn of the cache at the first place.


Anyway, back to the original topic:

If we had a preload instruction that does not stall the pipeline we 
could issue the preload in front of a longer ALU sequence, or a chunk of 
code that we know works on internal memory only. The cache could do it's 
job in the background while the DSP crunches data happily away.

Somewhat like this:

void process (char * data, int n)
{
   int i;
   char internal_ram[32];  // assume in internal ram:

   for (i=0; i<n; i+=32)
   {
     // prefetch next chunk of data one iteration ahead.
     // ought to execute in parallel with ALU unless a
     // cache-miss or cache-line write-back occurs.
     preload (data+32);

     // get prefetched data from previous iteration
     // won't stall if data is prefetched, e.g. on all
     // iterations except the first.
     memcpy (internal_ram, data, 32);

     // do something fancy on internal_ram here.
     for (...

     // writeback result. Won't stall because
     // data is still in L1D.
     memcpy (data, internal_ram, 32);

     // advance to next chunk.
     data +=32;
    }
}

If the process loop takes more time than the prefetch we would have 
perfect parallelism between RAM and the DSP for such streaming jobs. 
It's the same thing we do with DMA, but with a *much* finer granularity 
and *much* less overhead.

Nils

Vladimir Vassilevsky wrote:

> Is the questionable 16% improvement worth black magic with preloads?
> Would this optimization be useful if the program is modified, linked 
> into the different addresses, etc?

I've seen customers jump up and down in joy for such improvements. :-)

Nils

Nils wrote:


> If we had a preload instruction that does not stall the pipeline we 
> could issue the preload in front of a longer ALU sequence, or a chunk of 
> code that we know works on internal memory only. The cache could do it's 
> job in the background while the DSP crunches data happily away.

Then the cache either have to be dual ported or quasi dual ported. There 
also should be the logic for arbitration and resolution of the potential 
conflicts and the intermittent states. That would be the significant 
complication of the hardware.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com