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

["Jeff Fox" <fox@xxxxxxxxxxxxxxxxxxx>]

> Jeff Fox wrote:
> Now it's 15 + years later and massively parallel is back. This time I
> don't think the general-purpose people are going to take as long to
> catch up as they did last time.

I think learn and adapt is more accurate than catch up.

> The parallel algorithms aren't any better now than they
> were then,

More and known and published.

> the languages aren't any better now than they were then, etc.

Having been through five generations of parallel Forth I
would not agree about that.  Each generation replaced
complicated layers of software with clever hardware and
smarter software to simplify things.

> Yeah ... it *can* be done, but it's more work.

I think it is case of more work up front to use FP hardware
to make it easy to be lazier at the back end. But it is not
really my concern and I don't need to argue the point.

> I'm not sure they're even
> teaching it any more except in embedded shops where it's necessary.

That will change.

> I learned all that stuff because I learned programming on one of the
> original Von Neumann machines, ILLIAC I. Guess what? Some people used a
> floating point interpreted order code on ILLIAC I. :)

No doubt.

>> There has always been interest from high-end science
>> for the kind of parallelism SEAforth will offer.  Not
>> all scientific problems need to be expressed as gigantic
>> arrays of floating point numbers.
>
> Yeah ... I remember lattice gas methods. And the Thinking Machines
> Connection Machine. And MASPAR. And the Massively Parallel Processor.
> People with low budgets used tricks and hacks like that, and people with
> big budgets used things that were easier to program.

Yes.  What I think makes this different is that 30 years of
software development came first and as Chuck put it, the
programming problem was solved and the remaining problem
was software that would make programming even easier.

>> Yes, but historically interconnect was inefficient and
>> more expensive than processing.  The machines were
>> fabulously expensive.   Nothing with the performance
>> per watt or performance per $ has been done.  And
>> the E in SEAforth is Embedded where the whole thing
>> is about performance and power and $ costs.
>
> The biggest bottleneck was programming and algorithms.
> I think it still is.

It is a question of if you think Chuck's style of
programming makes things easier or not and whether
using parallelism features in hardware makes the
parallel software easier.

>> Chuck once said that if you set out to design a chip with the
>> intent of making it as difficult to program as possible you
>> might end up with Pentium.  I don't think that's true.  There
>> are things that are probably worse.  But clearly it is the
>> opposite of what Chuck likes.
>
> Actually, the Pentium isn't all that difficult to program.

Compared to what?

If we take someone unfamiliar with Pentium and ask them to
learn it well enough to understand it to program it well
how much of an investment will it be on their part to say
learn the entire instruction set and be able to correctly
characterize all the instructions and all the ways the
instructions can interact given the cache controller and
pipelines?  It is not going to happen in an afternoon.
That's the kind of context that Chuck and I talk about.

I say that I have taught engineers unfamiliar with the
processors or the language or the OS and went over all
the instructions, all the architectural details, all
the compiler and OS except for the GUI and network
code that these guys didn't need, and they were writing
project code the next day.  Now how long will it take
to teach someone unfamiliar with Pentium the complete
instruction set and architecure, all the details of
the compiler and OS that you recommend they use for
programming?  A couple of hours?

It may not be the most difficult to program processor
ever invented.  Ever see the programming manuals for
the Intel 432?  But again the context is that from
Chuck's point of view, where you should be able
to teach someone everthing fast Pentium takes
something more like a college degree than an
afternoon lecture.

> The world
> champion of programming difficulty was probably the
> Multiflow VLIW architecture. It actually *couldn't*
> be programmed by humans -- only a compiler could
> do it. Yet another beautiful theory murdered by
> a gang of brutal facts. :)

It sounds like the brutal facts were that it was a
terrible idea leading to a terrible implementation.
If the idea was to out terrible Pentium then
perhaps it did.

>> Yes.  I wonder if something like Pablo Reda's work with
>> children would be a good fit to a colorforth for OLPC project.
>
> The OLPC project was really very firm on keeping the number of
> programming languages to a bare minimum,

As Chuck likes to say, and the minimum is zero.  For practical
purposes he returned to using one.  It is not the minimum but
it is the practical minimum.  This was after all why Forth
was developed in the first place according to the first paper
ever published on Forth.

> namely Python, Squeak Smalltalk and Open Firmware Forth.

What no C?

> Of course with Mitch Bradley representing Forth
> and Alan Kay representing Smalltalk both senior members of the OLPC
> team, I wouldn't expect anything else. But if you have the "Linux port"
> of the Open Firmware Forth on the machine already, and can install
> gForth out of the Fedora repositories, is there a place for colorforth?

Certainly there is a place.  Whether someone wants to use it or not
is the issue.

> I'd like to try it, but then, I'd like to have an ELF executable
> colorforth I could run on my Athlon64 X2 under Linux 2.6.23. What are
> the chances of that happening?

The same as the chances of anyone who wants to do it doing it.
It doesn't sound like there is any reason it could not be done.

Colorforth and variations have been done stand-alone, DOS, Windows,
and Linux on PCs and stand-alone or hosted on other hardware. I
see nothing preventing an ELF executable.

> Is that something I could actually build myself?

Why not?  If I can get them to release the lastest version that
Chuck and his team are using along with some of the nice
manuals it might make it easier.  I think it is overdue.

As usual changes to the applications tend to take priority over
changes to the compiler.  But the improvements to the compiler
and to the utilities and the documenation to make things easier.

Otherwise you have to pick which other version you will
choose to port.  I don't know which would be easiest or
best to port to an ELF executable.

If anything porting Forth seems to be easier and more
popular with many enthusiasts wanting to understand a
system than using Forth.  People enjoy the educational
value of the exercise and many times other people enjoy
having the resulting system to use themselves without
having to do the porting themselves.

Best Wishes



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