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.

 - conditionals: 
   * 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 

 - buffering


 * 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.