Re: lean + mean
Thanks for your mail, very informative as always.
Christophe Lavarenne writes:
> > Out of curiousity: is the SHARC architecture (Analog Devices DSP family)
> > suitable for Forth? (Due to it's limited on-die memory one obviously requires
> > a very compact OS, and I'd like to build a DSP array as the next step after
> > my Beowulf (if only Athlon was already available in quantities!)).
>
> The SHARC ADSP21060 has 4 Mbits of dual-ported on-chip SRAM (i.e. 512 Kbytes,
I'm more interested in the ADSP-21160 (because of SIMD), though I
guess that won't be a $10 part. What's realistic for 100..1000
quantities of naked chips, $30? More?
> accessible by 16, 32 or 48 bits words), which is quite a lot, and may access
> a lot of external SRAM/DRAM, including the on-chip SRAM of up to five other
I know, but I wanted to skip around having a circuit board. Hotgluing
a (potentially very large) array of SHARCs to a stack of sheet copper
or plexiglas & wiring the links (with LEDs for debugging) together in
a 3d lattice (and using LOTS of aircooling, or even dipping it in a
Fluoroinert bath), using a SHARC PCI card sticking in a Linux box was
my general idea of it. This is about molecular dynamics, so 3d lattice
is ideal.
> SHARCs sharing the same external memory bus. Multi-megs OS designers may waste
> memory at will with the SHARC as they do with other processors. Compact OS
> designers are rewarded by efficiency. See http://www-rocq.inria.fr/syndex/
> for very compact and efficient multi-DSP SYNchronized Distributed EXecutives.
Thank you, I'll look. In fact I doubt I'll need a true multitasking OS
at all. Just a small (16..32 kByte) Forth core including
compiler/assembler is probably enough.
> The SHARC is of course suitable for Forth, but not for driving a VGA display,
No problem, the Linux box (or a small cluster of them) will do for
visualization and I/O just fine. Should the architecture catch on
(dream on) it can of course do its own visualization/I/O.
> or an FDDI/SCSI/USB/... Because integer/FP computation and memory addressing
> are done by separate units, using separate register files, "machine Forth" is
> (much!) easier to implement efficiently than ans-Forth: most primitives being
> one or two assembly instructions, subroutine-threading and primitive-inlining
> are very efficient and easy to implement (by "machine Forth" I mean @ @+ ! !+
> using an address register and pushing/@ popping/! the stack once, as in F21).
I'd love to see code snippets/general paper on how to implement
this. I'm a pretty lousy programmer (hey, I'm just a scientist, a
Linux zealot with embedded experience limited to a half a year), so
bootstrapping a Forth on a DSP array from essentially nothing along
with the parallel MD code, that's no small matter for a newbie (that's
why I start out with a small Beowulf, as a proof-of-concept). I know
there are portable Forths written in C out there, perhaps I have to
start with them. What's the best place to look?
> SHARC instructions being 48bits wide, you'd better start with a 32bits Forth
> to write a (cross/umbilical) compiler. Have also a look at the cheap 16bits
> ADSP218x, which has a lot of on-chip features, ideal for embedded (multi)DSP
> applications. I've written an umbilical assembler for it, and I enjoy it.
Url? Sources?
> Thanks for gforth :-)
> CL
> --
> http://www-rocq.inria.fr/~lavarenn/
