Re: [colorforth] Hello - and where to begin?

[Gwenhwyfaer <gwenhwyfaer@xxxxxxxxx>]

On 20/01/2008, M. Edward (Ed) Borasky <znmeb@xxxxxxxxxxx> wrote:
> Well then ... suppose you build a SEAforth PC -- wrap up a few billion
> or trillion Forth MIPS in a box with RAM, some mass storage, a keyboard,
> video, audio and mouse, running colorforth. Where would this machine
> have a *compelling* selling proposition?

This might sound perverse, but I wonder whether a SEAforth chip (with
enough processors, and enough RAM for each of them) could be persuaded
to emulate an x86, or an ARM? After all, each of those little CPUs is
running so fast that external memory is going to be far and away the
constraining factor anyway...

The other idea I had for it is a new synth product, but then I tend to
see *everything* in terms of whether I could build a synth around it.
The short bit length and lack of multiplication are certainly
complications for DSP apps, but perhaps not fatal ones.

More generally, the sense I get from these chips is that they're
basically intended to be FPGAs in software - instead of a logic cell
thingy, as FPGAs have, you get an extremely fast processor and a few
hundred words of RAM. Dataflow applications should be a cinch...

> So is document search and indexing a la Google for the
> same reason.

Since I'm sure you don't mean the absence of floating point hardware
here, which reason is that?

> What else do people do with high-performance computers? Well ... crypto,
> large-scale finite algebraic computation in general, maybe some kinds of
> simulation, some kinds of CAD. But that's really it, I think. Massively
> parallel non-floating-point machines have been built before, and they've
> invariably foundered on the difficulty of programming them and the lack
> of demand for MIPS without MFLOPS/GFLOPS/TFLOPS/PFLOPS.

I'm not altogether convinced that the argument for not trying
something different now is that trying something different didn't work
before. It seems to me that this mindset is what's led us to the
current, insufferably conservative, state of the computer market,
where there is basically one of everything, and anyone who suggests
that perhaps what has come about has not done so by merit is shouted
down almost immediately.

...Well, that and the ravages of unfettered capitalism:

> To be blunt, Intel is trying to kill the XO and probably will succeed. :(

Anyway.

> Well, yeah ... I've seen the hoops Anton Ertl and Bernd Paysan have had
> to jump through to get something as simple as ANS Forth to perform
> acceptably when the inner interpreter is compiled by GCC and run on a
> "modern" x86 with caches, branch prediction, etc. It's ugly.

That's the price of portability, though - the point of gforth is that
it'll compile and run on just about anything. If they'd restricted
themselves to the x86, they'd probably have had a far easier time of
it.

On the other hand, modern processors (of all flavours, not just x86)
are simply not optimised to run threaded code. For a predictor which
works on the principle that an indirect jump will go to the same place
it went last time (which isn't actually too bad for method calls, the
major use of indirect jumps in modern code), the inner interpreter's
indirect jumps will invariably end up being mispredicted, and so far
(I believe) the Core 2 series is the only processor that works any
harder to predict them.

Whereas for threaded code, the relatively simple prediction of
"whatever's in the register in question when the jump enters the
pipeline is the assumed target address" would make it possible to
achieve nigh-on 100% prediction rates. Does anything do that?

> Yes, you can outperform that with a Forth machine. In their day, Lisp
> machines could outperform a VAX with the same hardware costs too. Lisp
> survives, but neither the Lisp machine nor the VAX does today. :)

Although both architectures can be emulated on a PC. I dare say a
SEAforth wouldn't make too bad a job of them either.

Hell, modern CPUs emulate their "native" instruction sets, which is a
trend that always struck me as bizarre...

> Actually, it's the other way around. The C compilers and operating
> systems are designed to keep the processor busy. :)

Actually, they're not - hence the use of the HALT instruction in idle
loops. Leaving modern x86s in a busy-wait loop runs a real risk of
melting them. ;)

Regards
Gwenhwyfaer

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com