Another Forth CPU by the Forth creator Chuck Moore and colleagues: http://www.greenarraychips.com/. It's has 144 cores on a square centimeter chip.
Each core is equipped with its own little data and control Forth stacks, making it a fully fledged independent computer (that's why the more precise term is "multi-computer chips" rather than "multi-core").
The cores talk to each other via communication ports. Writing to a port suspends the core until
the peer reads the value. And vice-versa.
(similar to channels in Go language).
Some other interesting properties (quoting the docs):
A computer can read from multiple ports [corresponds to Go's select] and can execute instructions directly from those ports.
FINE GRAINED ENERGY CONTROL: ... The read or write instruction is automatically suspended in mid-operation if the address [one or more of communication ports and I/O pin] is inactive, consuming energy only due to transistor leakage currents, resuming when the address becomes active.
NO CLOCKS: Most computing devices have one or more clocks that synchronize all operations. When a conventional computer is powered up and waiting to respond quickly to stimuli, clock generation and distribution are consuming energy at a huge rate by our standards, yet accomplishing nothing. This is why “starting” and “stopping” the clock is a big deal and takes much time and energy for other architectures. Our architecture explicitly omits a clock, saving energy and time among other benefits.
"A fully fledged independent computer"? You need several such "computers" to compute an MD5 checksum according to an application note at their site.
Anything anyone in the industry dares to call a "core" (apart from NVIDIA's ALUs misnamed as "CUDA cores" or whatever) blows a GA "computer" out of the water, in particular, in terms of memory (you'll get kilobytes or more likely tens of kilobytes of cache and/or RAM per core.) And anything anyone in the industry dares to call a "computer"... well, it's in an entirely different league from a GA "computer", for starters, well, damned peripherals are considered to be a part of a "computer".
Good luck running anything of use on 144 tiny cores only talking to their neighbors, only supporting 18b integer arithmetic and having tiny RAMs for code and data. (Do you even get a DRAM interface? How about Ethernet?)
The chip is a bloody impressive achievement - an async design, no reliance on standard EDA tools, etc. etc. And perhaps it has its uses in really - really - energy-efficient applications with very - very - limited functionality.
But the "multi-computer" business... let's say that it makes GPU marketing look honest.
It's an interesting chip. You can implement a SRAM interface[1] using a few cores. And also generate a VGA signal[2]. Or run 10base 10 ethernet[e].
It's probably better to compare it with a FPGA that allows for rapid programming, than a multicore computer. Only you can sort of configure the whole thing as a SOC. Which has great power management. I'd love to see some updates from Greenarrays -- there hasn't been much news lately.
How about a DRAM interface? That is both necessary for sufficiently complex applications, and damned hard. An FPGA can do it, for some frequency (though many FPGAs come with a hard DRAM interface to save area and improve the frequency.) This thing? I rather doubt.
Also, "implement an SRAM interface" - perhaps, but not one particularly easy to program against, I believe.
I don't think it's a particularly good fit if what one really wants is the equivalent of a "PC" (ie: n cores of ~broadwell cpu with x gigs of ram) -- I tried to highlight that it is an entirely different system, and one which allows for some interesting streaming, straight forward, approaches to solving many problems. You won't be running python on this thing, but that doesn't mean that you can't do some interesting signal processing -- at extremely low power.
Maybe "really, really smart dsp" is a way to look at it...
* An FPGA could do it and the GA chips probably can't,
* You can't do a whole lot of embedded DSP apps without DRAM - it's not a question of "trying to be a PC", you just need memory to store stuff :-) and SRAM is too expensive.
Without DRAM, you're pretty much limited to what you call "streaming"; a whole lot of things don't work without being able to keep a working set in RAM. I don't argue that the chip is useless, just that it's useless in a huge range of use cases including many embedded ones, which is a sharp contrast to the connotations of its self-description as a "multi-computer chip"... And BTW even a really really dumb DSP chip can usually do DRAM :-)
I look at it as "an array of incredibly weak and energy-efficient cores" :-)
I loved Forth as a kid, I thought it was a great language to learn on.
I think that it's much better than BASIC for small projects and I would love to see someone make an arduino or BASIC STAMP type product (maybe kickstarter it?) with a little bit of an ecosystem.
I think a lot of people who are hardware focused but need to do some software would benefit, and software people who want to get into hardware would benefit too.
Forth's great strength over BASIC was in how you broke down a problem. It reward adding simple words that did simple things that could be combined into complex behavior. BASIC really didn't send you down that road. I agree it is a find language to learn.
I am new to FPGAs. I have a Terasic DE0 Nano. Would I be able to get the J1 running on it with the Verilog code, or do I need to translate it? Does the DE0 Nano have what it takes? I appreciate if you could answer my beginner questions. Thanks.
You'll need to change the RAM primitive to the Altera equivalent, but it should fit just fine. Then you have to figure out how you're going to interface to it.
That looks great. Any thoughts on the dictionary in terms of completeness or omissions? I have the TI watch based upon the MSP430 (TI EZ430-Chronos). Would I be able to somehow use this?
I am teaching myself assembler x64, and I find Forth to be a great next-upper level language. Factor and Retro are fun.
I wrote a huge amount of Forth (polyForth) in the '90s and was always fascinated by the simple definition of a Forth machine. When implemented on many uProcessors, you only used a small subset of the available assembly language instructions. Even back then, people were building custom CPUs to optimize Forth's execution speed.
I often wonder what kind of jobs a lot of the posters do. I don't know much about the language but it's quite fun to poke around and see how small the community is.
I found reda4 a forth created by Pablo Reda. He created a whole environment - examples, games, built-in sprite editors, text editors, compiles with FASM to a very small exe for Windows, and although people have criticized the aesthetics, I find them pleasantly retro and quirky. I will be attempting to enter my second Ludum Dare using it.
jonesforth is a nice literary programming tutorial for making a forth using x86 assembly; and then forth - the same approach would work for implementing it in js, C or other languages.
Each core is equipped with its own little data and control Forth stacks, making it a fully fledged independent computer (that's why the more precise term is "multi-computer chips" rather than "multi-core").
The cores talk to each other via communication ports. Writing to a port suspends the core until the peer reads the value. And vice-versa. (similar to channels in Go language).
Some other interesting properties (quoting the docs):
A computer can read from multiple ports [corresponds to Go's select] and can execute instructions directly from those ports.
FINE GRAINED ENERGY CONTROL: ... The read or write instruction is automatically suspended in mid-operation if the address [one or more of communication ports and I/O pin] is inactive, consuming energy only due to transistor leakage currents, resuming when the address becomes active.
NO CLOCKS: Most computing devices have one or more clocks that synchronize all operations. When a conventional computer is powered up and waiting to respond quickly to stimuli, clock generation and distribution are consuming energy at a huge rate by our standards, yet accomplishing nothing. This is why “starting” and “stopping” the clock is a big deal and takes much time and energy for other architectures. Our architecture explicitly omits a clock, saving energy and time among other benefits.
http://www.greenarraychips.com/home/documents/greg/PB002-100...