Speaking of chips, anyone fooling around with this?

<http://www.parallax.com/propeller/index.asp>

Best, Charles

Charles Turner wrote:

It's an interesting device, but I wonder how fast can it get data in and
out of the package since each CPU must wait it's turn until it has
access to the outside world. It's a chip that I have put in my list of
things to try out.

It has enough RAM to hold a decent amount of code inside so that is not
an issue, the eight CPU's can talk to each other through the common RAM,
it looks like it might be useful for quite a few things, and the
packaging available and price is good for home brewing up something. The
concept of the chip is simple, something that could be emulated inside a
FPGA.

Don Seglio wrote:

That is actually a long term problem with any CPU design. Some of the
original computer designs were multiprocessor (SIMD) machines and would
be I/O bound. I worked on an array processor years ago (the early 80's
version of a DSP chip) which has more electronics devoted to moving
data around than it did in the compute head. Even today's DSP chips
are I/O bound which is why they provide varying amounts of internal
memory.

rickman wrote:

Tom Zimmer did the F-PC system and the TCOM package. F-PC
generated more F-PC threaded code on the top of the .EXE system.
TCOM compiled mostly compatible source code ( pre-ANS 16-bit
no 'CELLS' so it has 2* where post-ANS would write CELLS to be
clearer and more portable) and Target COMpile the code. The
target could be pin-hole optimized 8086 native code packaged in
.COM files with or without the name dictionary and Forth interpreter/
compiler included in the target code. TCOM will also target native
code cross compilation for a list of other targets and can be
extended with further targets. It is available at Taygeta.

Yes. There are some other target compilers there and elsewhere.

normally target compilation is compilicated by having the same
names used in host, target, and target-compiler wordlists. And
there may be more wordlists and wordlist order manipulation
needed. What I described was a way to make the compiler
simple by keeping the code it compiled simple.

For a directed threaded ANS standard eForth system with a
couple tiny changes to eForth to ensure that all meta-patched
immediate host words have a literal at the same offset it becomes:

: META ( -- ) ' ' 2 CELLS + ! ; \ as in META 0BRANCH IF

rickman wrote:

Jeff Fox wrote:

Thanks, I made a reply to "richman" and before I sent it I took a little
nap, when I awoke I sent it right away before I noticed your answer so I
apologize for not being more clear on my previous postings. Having said
that, I haven't painted the whole picture so let me give you a brief sketch.

Below are some of my points that I mentioned in the other posting so
it's here for discussion. There are additional features but these are
the main ones.

Link list handling
Typed variables
Object programming
memory allocation and garbage collecting
extensive string support including pattern matching
database tool set for both disk based and memory based databases
rule base programming, this one would be easy to add if the other prior
items are in place.
TCP, UDP support for messaging and file transfers
USB support to connect to target systems or other devices.
Interface to OS system libraries in a consistent way across the various OS's

Don Seglio wrote:
...

Another think you might want to look at is the proposed extension to ANS
Forth for cross compilers, at ftp://ftp.forth.com/pub/ANS%%20Forth. It's
available in MS Word and PDF. XCtext5.* is the "normative" (required)
part, and XCapp5.* is an explanatory appendix. XCpaper.pdf is an
overview. This is based on work done about 10 years ago, jointly by
FORTH, Inc. and MPE. Cross-compilers based on this architecture are
available from both companies (and possibly other implementors), and
have been used in a large number of applications.

Elizabeth D Rather wrote:

Don Seglio wrote:

...