Fri Oct 18 07:50:27 EDT 2019


Thinking in dataflow is still quite difficult for me, while thinking
in sequential programs operating on buffers is second nature.

Maybe that is the problem that needs to be solved first: write systems
in that "CPU form", then gradually work towards factoring out steps
that can go into hardware.  I need to model the _reduction_ that
happens there.

So let's spell it out.

- all problems (for now) are modeled as single input to single output
  data streams.

- streams get "parsed" into some internal state, then "printed" out

- splitting the problem up into buffers + sequential packet processing
  code is a natural thing to do (at least for a programmer).

- so start out that way, and gradually eliminate the need for general
  purpose CPUs, by:

  - simplifying the high speed parts so buffers can be eliminated, and
    the processing cores can be simple state machines.

  - leaving the low speed parts to be handled by a single CPU
    executing an event loop

Most if this is known stuff, apart from the "simplify to non-buffered
stream processor".

The transition there is very large, as it consists of:

- eliminiating data memory accesses

- eliminating instruction sequencing

Is there a method that can be employed?  E.g. write out the entire
program as a sequence of data processing loops to expose the ones that
need to be turned into hardware, then merge the remaining code into
CPU code that operates on a minimal set of buffers.

I wonder if there is some more elegant way to say that both are the
same.  The CPU is an artifact.  It is NOT the most natural way to do
things.  The buffer is an artifact that is a side effect of the TDM
nature of a task switching CPU.  Basically, this representation is too
biased.  A CPU is essentially too powerful powerful such that al
algorithm can be mapped back to a simpler architecture.  A more
restricted abstraction is necessary.  Essentially, work backwards.

What I want is to split the problem into:

1) An executable specification (no buffers, all parallel processing)

2) An explicit mapping from parallel to TDM, either to simple
   sequencers or full-fledged CPUs and buffer memories.

How do you go from knowing that in principle this is possible, to
finding a practical approach that can be implemented in a reasonable
amount of time.  I.e. to solve the core subproblem first.

I need a toy problem to tackle this.

The typical one is a logic / protocol analyzer.

Let's write that DHT11 driver with this idea in mind.

And let's write it in Haskell right away.