Received: by 10.66.84.5 with SMTP id u5mr4039423pay.11.1349017545275;
        Sun, 30 Sep 2012 08:05:45 -0700 (PDT)
Path: t10ni23597989pbh.0!nntp.google.com!news.glorb.com!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: rickman <gnu...@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: GA144 polyForth
Date: Sun, 30 Sep 2012 11:05:42 -0400
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <k49n48$gmj$1@dont-email.me>
References: <32e7fd8d-7494-4010-a9d5-d9673a3df831@googlegroups.com> <7xtxuhtf3b.fsf@ruckus.brouhaha.com>
Mime-Version: 1.0
Injection-Date: Sun, 30 Sep 2012 15:05:44 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="0628ddd77d8fa919af0c3e6d4e8555c4";
	logging-data="17107"; mail-complaints-to="ab...@eternal-september.org";	posting-account="U2FsdGVkX1/Jn7ALvOd1iAbJr3fogBLI"
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
In-Reply-To: <7xtxuhtf3b.fsf@ruckus.brouhaha.com>
Cancel-Lock: sha1:MIfx9hBEGzplBExk4TBVw99WnHY=
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 9/29/2012 4:20 AM, Paul Rubin wrote:
> Howerd<howe...@yahoo.co.uk>  writes:
>> I have just downloaded the latest arrayForth and polyForth systems for
>> the GreenArrays GA144 EV001 evaluation board, dusted down the eval
>> board and installed it...
>
>> 3. There is no "inner interpreter" AKA "address interpreter" because
>> the F18 cores are programmed to be the polyForth virtual machine. OK,
>> you can argue semantics here...
>
> I wish they would document how the VM works.  Greg Bailey had a plea for
> someone to target a C compiler to the GA144, but I couldn't make enough
> sense of the VM source listing to tell whether those VM nodes (they have
> ROM code for the vm) could be a sensible C target already.

I am a bit biased being more of a hardware designer, but I can't see a C 
compiler being all that useful.  Maybe I don't appreciate the utility or 
efficiency of such a tool, but it seems to me the VM will run a lot 
slower than many other CPUs and will end up being very energy 
inefficient.  I can see running one VM to facilitate high level control 
or UI functions but running many of them can be difficult due to memory 
access conflicts and not along the lines of the chip's strong suit... 
fast, efficient hardware.


>> the other 100+ F18's via Ganglia and Snorkels ( whatever they are -
>> more docs please GA guys :-)
>
> That's the stuff for routing code and data around the GA144.  It's
> mentioned on some of the videos (type "greenarrays" into youtube).

I don't recall seeing this anywhere.  Chuck has done his stuff on 
inter-node comms but I don't recall these names being used anywhere. 
But then he noted that this was very complex code, so I never dug into 
it.  I expect to be useful it will need clear, simple documentation of 
how to use it.


>> : asd  1000 for 1000 for 0 drop next next ;
>> takes about 3 seconds.
>
> OK, I remember hearing something like 250ns access time to the external
> ram, so each pass through the loop is doing 10-12 ram accesses (the F18
> cycles probably don't use much of that 3 sec).  I guess not too bad,
> figuring it's a traditional threaded interpreter.
>
>> IIRC a 16 MHx Novix takes less than 1 second for this, and most 8 bit
>> processors are some tens of seconds.
>
> Hrm, do you mean recent 8 bitters?  And I wonder how something like an
> MSP430 (16 bit) would do.

Comparing a VM on a processor node on a $15 GA144 (which also needs 
external memory, etc) to an MCU that costs next to nothing is pretty 
pointless.  The question is not, can the GA144 do a job, the question 
is, is it the best chip for the application?


>> Speed wise, the combination of GA144, SPI EEPROM and SRAM, running
>> polyForth looks plenty fast enough for the sort of embedded apps I
>> usually work with.
>
>> Power wise, it looks good too.
>
> Did you measure the power, running that 3 second loop?  I wonder how it
> really compares with something like an MSP430, since those VM nodes are
> running at 700 mhz or so.  OTOH they may be idle most of the time,
> waiting for the external ram.

If it is running one node at full speed, it will use around 5 mW.  Many 
8 bitters will use around that same power level, but this would need to 
be normalized to their computing time.  That is essentially what Greg 
Bailey does in white paper 3, "Comparison..." with an MSP430.  But they 
use an old version of the MSP and I think the results are a bit skewed 
because of that.


>> All in all it could compete with an MSP430, 8051 or a PIC except that
>> only with the GA144 do you get so many fast cores with fast I/O to
>> play with.
>
> Right now it sounds sort of like a somewhat unusual FPGA, as Rickman has
> pointed out a few times.  It's nice that there's now a working "soft
> core" using a few of its cells that can run a relatively conventional
> software environment (calling Polyforth conventional just shows how far,
> er, ahead of the curve GA is).

Yes, and I think the device could be much better served by a Verilog or 
VHDL compiler than a C compiler.  But in reality I think they just need 
to figure out how customers can best use their devices and work on 
producing more app notes and guides to help us learn these techniques. 
The last conversation I had with Greg was along the lines of I need to 
measure timing data for myself.  I think this is a bit much to expect of 
customers.


>> The GA144 with polyForth seems to be to good not to use...
>> Just sharing my excitement - well done to all the GreenArray folks!
>
> Yes, it's a good development, and makes the product more "real".
> Congrats GA.

Hmmm, I think that was intended to be "*too* good not to use".  A small 
change makes a big difference in interpretation.

Rick