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
I am intrigued by your ideas, and wish to subscribe to your newsletter :-)
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
