The SHARC has a pretty bad GCC port (no long longs, not even indirect
jumps, thus no switch() for more than two or three entries... and all
these hacks with program memory vs. data memory - and all that with even
violating the GPL; no source on the CD, nor a written offer, but at
least they still have the sources on
ftp://ftp.analog.com/pub/dsp/dev_tool/21k_tool/gnu_src/). I fixed the
indirect jump issue for myself (patch available on request), but AD
discontinued the GCC derived compiler anyway.
When you actually use a DSP as documented (including multiple DMA
channels at once, interrupts, etc.), be prepared to find some nasty and
subtle bugs. I've heard some pretty awful horror storries about Ti
c3x's.
What's awful for a general purpose OS is that DSPs are often
word-addressed, and have at most a very cumbersome sub-word addressing
scheme (mapped somewhere else, like the SHARC does). It's not so much a
problem for the C compiler, but your app grows enormously, since each
character takes up 4 bytes.
Eventually DSPs will grow enough features to run an OS, but I expect
that from graphic DSPs (3D render engines) first, not from audio DSPs.
After all, they have almost anything yet - GART-MMU for AGP,
byte-access, large memory... it's just the program space is a problem
(typically not user programmed).
-- Bernd Paysan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/