Re: Parallax Propeller processor

[tjoccam@xxxxxxxxxxx]

> Hi all,
>
> I hadn't seen this before, but it looks interesting from an
> occam/transputer point of view.
>
> Parallax have a new line of relatively cheap ($25) multi-core
> microcontrollers. Each chip will run at 80MHz, has 32 IO pins, and
> contains eight processor cores each of which has 512 32-bit words of
> RAM. There's some shared memory in each chip through which the cores can
> communicate. The cores are fairly nondescript register machines; they
> aren't spectacularly powerful, but they're fast enough for interesting
> embedded applications.
>
> Parallax's site about the chip is here:
>   http://www.parallax.com/propeller/index.asp
>
> There's a more general introductory article here:
>   http://www.elecdesign.com/Articles/Print.cfm?ArticleID=13329
>
> The reference manual (worth reading) is here:
>   http://www.parallax.com/dl/docs/prod/prop/WebPM-v1.01.pdf
>
> The programming language they've developed for it, SPIN, bears some
> syntactic resemblence to occam. They describe it as "object-based", but
> it's not really OO in any meaningful sense (there's no dynamic memory
> allocation, for a start); each "object" is a lump of procedural code
> that runs on a single core, and can start up jobs on other cores and
> communicate with them using the shared memory.
>
> The processor and language are clearly aimed at embedded developers, and
> the development system looks unpleasantly proprietary, but it looks like
> it might be a fun system to play with. In particular, it would be a nice
> system to develop an occam subset for (aimed at generating extremely
> small code); their development tools provide no safety guarantees at
> all.

This looks like an example of what Eric Verhulst was talking about, and my
last comment would apply: you would want to model it faithfully using a
simulator and then, after proving the design with the simulator,
faithfully map it onto the 512 bytes of code. After advanced work, it
could be possible to auto-generate this code.

At least the communication ought to be "occam-ized" with a fixed
implementation of channel and ALT. I used to do this by hand on Microchip
PIC nodes.

Larry Dickson

>
> --
> Adam Sampson                                         <http://offog.org/>
>
>