[<<][staapl][>>][..]

Sun Dec 9 22:52:16 CET 2007

krikit -> reflections on Forth and DSP

looking at the code i write, it is full of global variables (temporary
storage for multiple fanout). and inlined early-bound math ops,
operating directly on memory instead of the stack. also macros that
unfold to criss-cross variable access are much more useful here than
compositional forth.

the problem with DSP is that speed matters, and it's easy to get to
order of magnitude savings by early binding. so macros are
important. algorithms are often not terribly complicated. the stress
is more on mapping things to hardware.

now, i realize i'm stretching it trying to do DSP on a PIC18. it
misses essential elements like a barrel shifter, large accumulator,
and rich addressing modes. these things REALLY make a huge
difference. but, keeping data in memory (registers) makes things
relatively fast on a PIC18.

if the specs are clear (if the algorithm doesn't change)
implementation can be straightforward, though a manual endeavor. but,
what i've learned, experimentation REQUIRES more highlevel
constructs. i lost too much time and energy in mapping to hardware
before things actually worked.

which leads me to the following strategy: if experimentation on the
hardware is essential, experiment on hardware that 10x faster, or use
data rates 10x slower such that high level abstractions can be
used. for purrr on the PIC18 and 16/24 bit DSP operations this means:
USE A DTC FORTH! when it's done, core routines can be done in purrr18
or in machine language. what i need is:

  * confidence that 10x speedup is possible
  * confidence that slowing down ACTUALLY WORKS
  * patience and discipline to get it to work FIRST and THEN speed it up

what i missed in this project is the availability of an easier to use
16bit forth, and a policy for doing fixed point math. the former would
have made the latter more easy to use.

and second, it is probably a good idea to start looking for a dataflow
language: one that

  * automates the allocation of temporary buffers (variables).
  * enables abstract boxes (made of networks of abstract boxes)
  * automates iterated boxes (+ possible 'folding')
  * separates registers from functions (all feedback = explicit)
  * frp vs. static sequencing ?

so i'm not so sure anymore if forth is really useful for the
dsPIC. maybe in the sense that it should map to the 16bit arch just
like purrr maps to the 8bit arch, but leave the dsp-ishness alone:
provide only an assembler.

[Reply][About]

[<<][staapl][>>][..]