
Chuck Moore's Creations - samsaga2
http://blogs.msdn.com/b/ashleyf/archive/2013/09/21/chuck-moores-creations.aspx
======
tikhonj
If you want to play around with the F18A instruction set, I wrote an emulator
for it[1]. This also comes with a system to synthesize F18A code with MCMC,
using the basic technique from the Stochastic Superoptimization[2] paper.

Additionally, there is an interesting project I worked on with several other
people to make writing code for GreenArrays more accessible[3]. This includes
a system for synthesizing and verifying F18A code using two different solvers
(Z3 and Sketch[4]) as well as a system for automatically partitioning and
laying out code over the different cores. It's a work in progress, but well
worth a look.

[1]: [http://hackage.haskell.org/package/array-
forth](http://hackage.haskell.org/package/array-forth),
[https://github.com/TikhonJelvis/array-
forth](https://github.com/TikhonJelvis/array-forth)

[2]:
[http://cs.stanford.edu/people/eschkufz/research/asplos291-sc...](http://cs.stanford.edu/people/eschkufz/research/asplos291-schkufza.pdf)

[3]:
[http://www.forth.org/svfig/kk/11-2012-Bodik.pdf](http://www.forth.org/svfig/kk/11-2012-Bodik.pdf)

[4]: [https://github.com/TikhonJelvis/array-forth-
sketch](https://github.com/TikhonJelvis/array-forth-sketch),
[https://bitbucket.org/gatoatigrado/sketch-
frontend/wiki/Home](https://bitbucket.org/gatoatigrado/sketch-
frontend/wiki/Home)

------
jnbiche
Amazing architecture; I remember reading about it and colorforth several years
ago when I was researching parallel architectures. I almost want to buy a chip
and mount it on a schmartboard, but I've got so much going on right now that I
know it would probably sit there after that.

The real reason for my comment, however, is a question: is that idiomatic F#?
If so, I like it! It's got a lot of Haskell's succinctness, power, and
functional goodness without becoming a tangled mess of indecipherable symbols.
Yes, you can write Haskell this way, but in my experience, almost no one does.
If this is typical for F#, it deserves a (very close) look.

Add to that the fact that I was impressed with the readability and power of a
bit of C# code the other day. I really got to give these MS languages another
chance. It's too bad I can't stand the OS (and yes, I've tried Windows 8 --
even worse). How's Mono these days?

~~~
xmonkee
Well F# is basically ML.net so why not check out OCaml? Same language, and no
windows required.

~~~
bunderbunder
Basically, yes.

But in detail, "F# is basicall ML.net" is about as useful a language summary
as "Objective-C is basically C++.mac". Despite the common heritage, the two
feel quite different once you sit down and spend some time with them.

And seriously, this "the Common Language Runtime is only available on Windows"
trope needs to die. Mono's been around for. . . what, a decade now? Something
like that.

~~~
technomancy
I agree that the underlying runtime and ecosystem affect the "feel" of
programming in a given language a lot, but the comment above was specifically
referring to the snippet of F# in the blog post, which could be trivially
translated into OCaml.

AFAIK the main differences around the runtime are that the CLR has true
concurrency and access to more libraries without using FFI, while OCaml is
able to produce very tiny executables (~200kb) if you use the native compiler.

~~~
bunderbunder
Sounds like the differences go rather farther than you know:

The object model's really quite very different - F# uses CLR objects instead
of OCaml-style ones.

F# has computation expressions, which are a rather nice riff on monads.

F# doesn't have functors. Since it uses CLR objects it does have .NET
generics, but it's just not the same

Active patterns and type providers are neat, too. Though I believe there are
Caml macros that implement both.

~~~
jnbiche
From my research, it looks like F# does not have structural typing (since it
uses the .net type system). Does this mean you can't use constraints on types,
like make a type with a range (0.0-1.0) or a type from an enum
(man|woman|child)?

These kinds of type constraints are one of my favorite things about Haskell,
and one of the reasons I'm really interested (in another language category) in
Ada -- you can actually model real-life things using the type system.

~~~
bunderbunder
F# uses nominal typing - that's another difference between it and Caml.

That said, F# will let you do the things you listed - one can be handled with
traditional OOP techniques, and the other is handled by discriminated unions.
Structural typing is a bit different from what you're describing - it's more a
kind of compile-time duck typing.

I actually think F#'s switch to nominative typing is a big improvement over
its Caml roots. When I'm trying to build out a type system that's meant to use
type checks to enforce sanity, I want to have explicit control over when and
where types are considered to be equivalent. Just because the types foo and
bar implement members with similar signatures does not mean that they carry
the same semantics.

Therefore, IMO having the language try to be clever and jump to the conclusion
that anything that looks like a duck must be a duck is a hindrance to type
safety. It's also a bit of a maintainability hassle: Having a formal type
definition for each equivalence class makes it easier to find which types need
to be modified accordingly when an equivalence class's definition changes.

------
Semaphor
As someone with little interest or knowledge in low level hardware, what are
the advantages of this? What would you use it for?

edit: Just to clarify, with little interest I mean little interest in
acquiring in-depth knowledge about it. I'm still interested in hearing about
advances like this and their uses.

~~~
tikhonj
The main advantage is that it's _exceptionally_ power-efficient. Take a look
at the chart on these slides[1] for more details. It gets this efficiency
despite being manufactured with relatively outdated methods--if I'm not
mistaken, it has 150nm transitors!

[1]: [http://www.greenarraychips.com/home/news/docs/GreenArrays-
Fo...](http://www.greenarraychips.com/home/news/docs/GreenArrays-Forth-
Day-2012.pdf)

My understanding is that it's power efficient because the stack-based design
allows you to transfer very little data in and out of registers. Additionally,
the chip is very simple, has very few transistors and no clock. All this helps
save power. Also, the cores can power down very quickly when they're not used,
meaning you only pay the energy cost of the ones you _are_ using at the
moment. Of course, you shouldn't take my word for it: I'm desperately not a
hardware person.

I've heard several compelling ideas for using these chips. They're a good fit
for small, simple devices that need a long battery life: things like sensors
in everyday goods and such, think "internet of things". Another possibility is
using them in phones so that the main, power-hungry chip could go to sleep
leaving a chip like this to monitor inputs and awaken the phone if needed.

~~~
hershel
This is not exceptionally power efficient. It does around 90
gigaops/sec(probably 5bit ops) and programmable only in forth. Parallela has a
chip that does 90 gflops/watt and is programmable in c/open-cl/r and maybe
other tools. That's much more usefulland power efficient.

But what about better manufacturing technologies for the F18A chip ? first, it
negates some of the advantages of working asynchronously , because the much
higher leakage current. Second, the processors game was always about software
tools and ecosystems, which is the weak point of the F18A, and without solving
this , we won't see it in more advanced manufacturing processes.

~~~
boomlinde
Actual power efficiency depends on the application of the CPU. If you have a
use case that mostly leaves the CPU in an idle state only to react on
occasional events, the F18A would probably be more efficient than the
Parallela chip.

------
Procrastes
I live in Northern California near Chuck Moore. He came and spoke at our
office last week and showed off the new GreenArrays architecture. Afterwards
we were trying to come up with things to disrupt with a super low power /
massively parallel chip like that. The problem he brought up is that in
products like smart phones the power usage is in the display and the radio. So
there isn't much savings in a lower power processor.

But... After the discussion several of us wondered about electronic ink
signage. With the Green Arrays stuff you could definitely be completely solar
powered.

It would also make an interesting Personal Area Network central control unit
for Quantified Self stuff using harvested energy.

I would support a kickstarter for either of those, but I'm not going to pursue
them myself right now.

Green Arrays:
[http://www.greenarraychips.com/](http://www.greenarraychips.com/)

------
lambda
So, I'm actually looking right now for a microcontroller to run a bunch of
real-time I/O that may involve a certain amount of fairly timing dependent
bit-banging. I'm planning on building a pinball machine, and so need something
that can take input from a couple of buttons, a bunch of switches and some
sensors, and drive a bunch of solenoids, LEDs, and the like.

Since I will need to do a bunch of PWM or possibly bit-banged serial protocols
to drive all of the LEDs, and I want to have good real-time guarantees on
input from the buttons and driving the solenoids, I'm trying to figure out
what microcontroller I should use; something like a Propeller, or an FPGA, or
maybe one of these, or something else entirely.

Anyone have any experience with these kinds of issues? Will the GA144 be able
to do some fairly timing-dependent bit-banging reliably? I notice in the docs
that they say the time it takes for each instruction to execute is not fixed.
How would you go about doing a timing dependent protocol on these? Is there a
high-resolution timer you can poll to ensure that your transitions occur in a
timely manner? Or should I bite the bullet and start learning FPGA
programming?

~~~
sehugg
Your solenoid response time is likely to be much, much slower than the bit-
banging rate of any modern uC. A standard PIC or similar would do fine
(assuming it has the I/Os you need).

~~~
lambda
For solenoids, sure, though some of them (the flipper solenoids) need to be
PWMed to vary their strength; you do a full-strength pulse at the beginning to
drive the flipper with a good amount of force to hit the ball, but when you
hit the end of the stroke, there's a switch that tells you to switch to PWM
with a low duty cycle so you avoid overheating the solenoid but can still hold
the flipper up to trap the ball. So you need at least the ability to PWM that.
Sure, I could probably build a little timer circuit to do that, but it would
be convenient if I could just bit-bang a GPIO pin instead of building more
hardware.

For driving a few dozen RGB LEDs with PWM to control brightness on each of the
three channels, you're very quickly going to reach the limits of what you can
do with a standard PIC. Or even if not driving the LEDs directly but using
something like these:
[http://www.adafruit.com/datasheets/WS2812.pdf](http://www.adafruit.com/datasheets/WS2812.pdf)
you need to be able to produce a fairly high precision 800 khz serial signal
with no clock.

Between the number of inputs and outputs needed (lots of switches and sensors
on the playfield, lots of solenoids to kick out balls and control various
toys, lots of LEDs), and the high-speed output needed to drive the LEDs, I'm
not sure a standard PIC is going to cut it, though I haven't actually sat down
to calculate out the precise number of I/Os and speed that I'll need so I may
be wrong. I'm more looking for a ballpark of what I should get a dev board for
and start playing around with, I may wind up changing my mind and switching to
something else later.

~~~
sehugg
For the LEDs and solenoids I'm guessing the PWM frequency is in the sub 1 kHz
range, so you should be able to bit-bang perfectly well with even a low-
powered uC. Timing precision for those shouldn't be very strict.

As for the WS2812, that's annoying :) It would be nice if it could use SPI or
a UART. I see the NeoPixel library uses bit-banging with interrupts disabled
and relies on instruction timing, yuck. But hey, it might work. I've seen
single-wire stuff work on Windows CE, for crying out loud. AFAIK you don't
need a continuous 800 kHz signal, you can just send it when you want to
update.

~~~
lambda
Yeah, the WS2812 does have a fairly unique interface, but at 45¢ for an RGB
LED with a built in constant current driver, it's pretty much the cheapest
option per LED. Other options I've seen like the A6281 are $2 for just the
driver itself, without the LED.

Since there are probably going to be at least a few dozen LEDs, the per LED
cost can add up quickly, so I'm fine with spending a bit more on a more
powerful microcontroller or FPGA and learning a new system. And of course,
part of the goal is to learn new things and have fun with the project, so some
of these new highly parallel microcontrollers like the GA144, Propeller, XMOS,
or even an FPGA would be more interesting to work with than a standard PIC,
even if they may technically be overkill.

This is the first time I've done hardware hacking in a while; the last time I
did it I used a 68008 as my microcontroller. So I'm hoping to find something
that will be interesting to learn, not too hard to use, and capable of
everything I'm going to throw at it, so I don't have to go through several
iterations of buying expensive development boards only to discover that I
can't drive my dot matrix display or I can only drive half of the playfield
LEDs that I need or that interrupts from the flipper buttons cause my LED
color fades to flicker since they screwed up the timing of my signal to the
driver or something of the sort.

One of the problems is that since there are so many choices, and I haven't
done hardware hacking in a while, I don't have a good sense of what I'll be
able to do yet. Maybe I should start small, with an Arduino or a PIC or
something of the sort, and move up if I discover that that can't do something
that I want.

~~~
mindslight
Coming back into the hardware world after being away for several years, I find
the ARM Cortexen pretty damn compelling for the possibility to do the high
level programming in something besides C. And a STM32F4 Discovery board is
only ~$15.

(And yeah, I feel dirty for blowing up a GreenArrays thread with a suggestion
for a more traditional microcontroller, especially not having really studied
the GA chip.)

------
acegopher
If you are interested in a more "conventional" Forth chip, check out the
J1[1]. It's 200 lines of verilog, so you can put it on an FPGA pretty easily.

But it's even easier than that because the J1 is the basis of the
Gameduino[2]. The Gameduino is a shield for Arduino that gives you a VGA
interface, sprites, and graphics.

[1]:
[http://www.excamera.com/sphinx/fpga-j1.html](http://www.excamera.com/sphinx/fpga-j1.html)

[2]:
[http://excamera.com/sphinx/gameduino/](http://excamera.com/sphinx/gameduino/)

------
Cthulhu_
I was at Chuck Moore's talk at Strangeloop, it was... esoteric. From what I
gather, it's not really something you'd want to write a full application in -
Forth came across to me as a very low-level language, much like assembler.
Which makes sense given how the chip executes it natively.

also the dude did not wear shoes.

~~~
csmuk
Forth is actually pretty high level. You just have to get there first by
building up the abstractions. You can end up with an almost Ruby/Python like
language on top of it if you want. But you probably won't want that after
using Forth for a bit and will end up writing DSL's for your programming
concerns.

The use case I had for Forth was a PLC-like controller. You ended up
describing the configuration in Forth by the time the abstraction was built.
Example for a simple "virtual relay" controlled light switch taht turns two
separate circuits on and off in a ladder:

    
    
       bob relays
       0 switch inports
       1 light1 2 light2 outports
       switch inport 
          bob coil 
          ladder
       bob contact 
          begin
             light1 outport
             light2 outport
          logical-and
          ladder
       plc
    

Was awesome. Unfortunately I don't have rights to the source. It ran on a Z80
board.

~~~
davidw
Forth is quite interesting, and cool in its own way, but: how can anything
where you have to remember what is supposed to be on the stack 'high level'?

~~~
Jtsummers
As I understand it, the ideal in Forth is to build up a base that hides those
complexities in a domain appropriate API. You don't throw 3 numbers onto a
stack and leave them on the stack to represent a vector, you wrap that up with
a call to 'make-vector', and from there on you're dealing with 'vectors' as a
unit rather than '3 points on the stack'. Or if you don't, you develop an API
that deals with them sensibly so that every routine that operates on vectors
doesn't have to get into the nitty-gritty. Write a routine that represents the
common operations (add-vectors, multiply-by-scalar, dot-product, etc) and
build your complex routines on those, so that vector projection could be:

    
    
        : project-a-onto-b (a b -- c) swap rot dot-product swap scalar-mult;
    

Ok, 3 stack manipulations but someone who's done more than just toy programs
in RPL and Forth might be able to come up with some other routines that can
hide those as well. EDIT: And once written, the user of the routine needs to
know, "put the two vectors onto the stack, the first one is what I'm
projecting, and the second is what I'm projecting onto".

Another point to consider, dynamically typed languages suffer a similar
'failing' if they're to be considered 'high level'. How can they be 'high
level' if you can add 1+"b"? (in code, won't work in runtime unless it's
weakly typed, similar to having too few items on the data stack). How can any
language be considered 'high level' if you have to remember how many
parameters, their types and in what order for every function call?

~~~
csmuk
Nice to see a mention of RPL. Still use an RPL machine daily (HP50g)

~~~
Jtsummers
Tragically, my HP48G+ (?? I know this model exists, may have been mine, sounds
right) bit the dust a few years back (water damage, think it happened while
stuff was in storage between residences). It wouldn't be particularly useful
in my day-to-day stuff, but RPL is probably the main reason Forth seemed so
natural to me when I played around with it a few years back.

------
VLM
What to do with 144 cores? I just watched a video last week about a guy doing
SDR to monitor wireless tire pressure transmitters. Every car sold since
2010-ish has at least four of them, each with a unique 32 bit ID, for police
tracking purposes, err, to "save the children" or whatever BS.

Anyway the complaint was there are 127 or 121 or some prime number of
different algorithms from different mfgrs so you need to run 120-something
decoders to completely decode each protocol. This is a pain with a single core
laptop. But with a 144 core forth chip I think giving each precisely one
protocol to decode in parallel would be fine.

------
yiedyie
Sounds like the future if just for the low-power. « 144-core asynchronous chip
that needs little energy (7 pJ/inst). Idle cores use no power (100 nW). Active
ones (4 mW) run fast (666 Mips), then wait for communication (idle).»

~~~
david927
You're right -- it sounds like the future for several reasons. I can't wait to
get my hands on an eval board.

Why is it that if I have to list the three or four people doing the most to
break new ground in our industry, they're all over 60? Chuck Moore is _75_ and
he's doing this.

~~~
kahunamoore
Here is a sample application note detailing an integration with the TI
SensorTag:

[http://www.greenarraychips.com/home/documents/greg/AN012-130...](http://www.greenarraychips.com/home/documents/greg/AN012-130606-SENSORTAG.pdf)

------
be5invis
I saw a RMBP installed Windows while using the native resolution (2880x1800).

Maybe he needs more area instead of neater display. Screen area is extremely
important for an electronic engineer.

------
femto
The fun thing is that you can buy a 10 pack of chips off the GreenArrays
website for $200.

------
STRML
I would love to see this video. The only link I could find [1], unfortunately,
was behind an auth wall restricted only to attendees of the event. Does anyone
know where it might be found?

1\.
[http://www.infoq.com/presentations/power-144-chip?utm_source...](http://www.infoq.com/presentations/power-144-chip?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=StrangeLoop2013)

~~~
astrobe_
There's some on youtube in the manufacturer's channel, Greenarray.

[https://www.youtube.com/watch?v=NK1zlz67MjU](https://www.youtube.com/watch?v=NK1zlz67MjU)

Also maybe try the designer's site, Chuck Moore. Google Colorforth.

------
rthomas6
I'd really like to see a Verilog/VHDL design of this chip to see how it works.
Does anyone know if I can get that?

~~~
Procrastes
It doesn't work that way.

This isn't a Verilog/VHDL implementation, but instead a physical chip.

Also he implemented the chip design tool in FORTH as well.

~~~
rthomas6
Okay, so how did he design the physical chip? Physical design starts with some
kind of RTL, usually. Unless he mapped out the chip on a transistor level by
hand, he used some kind of software to aid him in the design. If he didn't use
Verilog/VHDL, I'd like to see whatever logic-level design he did make.

~~~
beagle3
He did design the physical chip, gates and all. He wrote the design software
himself (supposedly, 500 lines of forth called OKAD). He uses a simpler model
that is accurate enough for the process he is using.

[http://www.colorforth.com/vlsi.html](http://www.colorforth.com/vlsi.html)

Everything he does is fascinating, but don't expect any of it to be useful
unless you are, in fact, Chuck Moore (perhaps Chuck Norris also gets a
pass...)

------
sehugg
The F18A reference doc is amazingly concise; all you need to know about the
architecture in about 10 pages.

[http://www.greenarraychips.com/home/documents/greg/DB001-110...](http://www.greenarraychips.com/home/documents/greg/DB001-110412-F18A.pdf)
(PDF)

------
conjecTech
I've had two separate people tell me about forth and green arrays this past
week. My interest in piqued. Someone please point me in the direction of a
good introduction to the language and its merits.

~~~
Procrastes
This is a nice, concise overview:
[http://cs.earlham.edu/~stoneda/cs71/](http://cs.earlham.edu/~stoneda/cs71/)

Why Forth: [http://bernd-paysan.de/why-forth.html](http://bernd-paysan.de/why-
forth.html)

------
pointfree
Why the change to an uninformative title from 'A CPU with 144 "tiny"
computers, without clock and 5-bit instructions'?

------
teddyknox
How is this different from CUDA?

