Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief

[Josh Blum]

>>
>> I wonder if that assertion is generally true, or only in some cases?
>> Increment and test shouldn't be *that* expensive.
>>
> 
> I'm sure the benefit varies depending on the situation, including some where
> there is no benefit.  But modulo increments add a conditional operation for
> every pointer increment, which can cause a processor pipeline stall, and
> takes up register file space to hold the array boundaries for every input
> and output stream.  It also forces the author of the work() function to know
> about how GNU Radio handles circular buffers.  The double-mapped circular
> buffer lets the work() function treat all its inputs and outputs as linear
> arrays in memory, no matter the actual case.
> 

Suppose that we didn't have a specially mapped memory. I believe the
scheduler could easily ensure that contiguous chunks of memory are
always passed into the work function with little overhead for both read
and for write.

Now, I bet there will be a slight problem when you have a block with
"history" like FIR filter that needs ntaps worth of samples repeated
into the next work function. So, when the scheduler has to actually wrap
back around to the beginning of the buffer, it will have to memcpy
nsamps to the begging of the buffer. Which shouldnt be bad when buffer
size >>> history size.

Its sounds possible (so stop me if I missed something big here).
Basically, it would be nice to support a linear memory/buffer mode for
the block executor for two reasons. 1) switch to a linear memory when
allocation of mapping fails, and 2) swap out the buffer with something
like a memory hole for a dsp for direct-copy.

-Josh