Wed Feb 24 08:19:56 CET 2010
Practical issues for DSP language
Currently I can break down the primitive entities into:
- unit delays
First and foremost: how to translate a program with delays into a
state space formulation.
- variable delays with integer indexing
Then, how to map domain values (i.e. floats) to delay offsets. This
includes bounds checking.
* piecewize functions
* 'while' or 'for' loops
Are general conditional statements allowed, or do we provide only
``local'' conditionals, i.e. to compute piecewize functions, and
``global'' conditionals, in the form of functional combinators
(locally iterated state space systems).
- subsampling & block processing
How to incorporate combinators for subsampling, oversampling and block
processing? Lifting/embedding operators are necessary to couple
different iteration plans.
- lookup tables
Similar to block processing, variables delays: how to accomodate
* Thinking about the nested processing approach, maybe its better to
use an explicit (causal) stream model everywhere, and allow for
translation to incremental form for the top level data stream.
I.e. back to the previous approach (in Staapl): all variables are
infinite streams by default, but can be optimized away.
* Nested streams are only necessary for iterative algorithms that run
multiple updates per real-world sample tick.
* Lifting a sample-based stream to a block-based stream means
creating a nested stream processor, as the sample based stream
needs to perform its iteration for each real-world block tick.
* The other way around: embedding a block processor in a sample-based
stream processor requires buffering.
* The main question seems to be: are delays represented by registers
that are updated in-place (i.e. for state), or indexed offsets
(when multiple input / output sample are available) or a
combination of those that handle different border cases.