f21d heating, Chuck's talk, Machine Forth

[theFox@xxxxxxxxxxxxxxxxxxx (Jeff Fox)]

Dear Low Fat Computing mail list readers:

>I ran accross the mailing list archive while reading a post in c.l.f on
>"when will iTV or F21 be ready"?  Which reminds me, when will
>it be ready?  (The poster was using an MuP21 and was having
>heating problems and was wondering if the F21 overcomes those
>problems.)

The poster was very confused about the problems he was having.  He
was confusing the transistor heating issue with various video
encoding circuit design and PCB design issues.  That was my take. 
Some of the problem may be communication.  I thought I had answered
his questions quite thoughly in long emails as is my normal fashion.
I was supprised to see him say that I hadn't answered his questions,
but then again about all I could conclude was that either he didn't
understand me or I didn't understand him or both.

Chuck identified and described the transistor heating problem
publicly last summer.  I have transcribed his talks and posted them
on the internet for anyone to read. Since the first three F21 had been dead in
the water and iTV had had a long series of chips functioning
well enough to go into products I made the decision to go for
a known mostly working CPU to be able to test the coprocessor unique
to F21.  

The temperature fix was tested at iTV although that chip had not
come back for testing when he talked about it at his Fireside Chat
last Nov.  Remember it takes about four months to get chips back and
into testing. Since then no chips have been submitted for fab because 
of lack of funding.

Anyway the heating problem was not a serious issue on P21.  In the
chips housed in plastic you must put a nop before A!.  That is not
a serious bug.  On F21d it means that you can execute some code
packed four instuctions per word and some combination of instructions
cannot be packed four per word.  Even for those that execute four
per word there is a limit as to how much of the time you can
execute at that rate.  As Chuck has described in detail the model
he used for heating was way off just like the rest of the
electronics industry.

Now the video questions require more more extensive answers.

>Anyway there's a lot of good info in the archive.  And Jeff I can't
>wait to read the rest of the coverage on Chuck's latest talk.

I have purposely not transcribed Chuck's latest presentation.  I have
felt very bad about the fact that for the last ten years I have been
the only person who posted an agenda or review of presentations to
SVFIG in c.l.f or on the web.  As a reward for doing this I have put
up with a group of unwashed morons (their words) who have called me
a liar, a cultist, said I was intellectually dishonest, that I was
distorting what Chuck Moore had said etc.  I am very tired of it.

I am not even a member of SVFIG.  There were about fourty people in 
attendance on 5/22 when Chuck gave his presentation.  I know that
many of those people read and post in c.l.f.  Some of them read
this list.  

For the first time I saw Chuck post in c.l.f and ask people what
they would like to hear him talk about.  It generated some interesting
discussions, but before the talk took place some of the people had
derailed the discussion into other things.  By the time the presentation
took place there were no longer any discussions.

Personally I thought it was a great presentation.  All about Forth
rather than hardware.  He gave a great presentation about ANS Forth
and how much of the CORE does not belong in the CORE, what should
not be visible at all, and what should be avoided at all cost.  He
also said that he had made outrageous claims about the size and
speed of programs but that he would give another example to demonstrate 
to anyone's reasonable observation that he was right.  He did a
long code walk through on a bmp file program in a few hundred bytes
of source.  In the process he explained more of the internal details
of his Color Forth and the relationship between Color Forth and
Machine Forth.  It is the kind of thing most people would rather 
ignore than face.  

I was currious to see if there would be ANY discussion by the many
people who saw his presentation.  I was not supprised that not a
single person made a single comment about the presentation in c.l.f.
I wanted to know if most of the people there would just ignore it
or if anyone would make any comments about it all.

At my last presentation to FIG I complained that it was strange that
they all heard the same speeches that Chuck has made at SVFIG yet
when I quote Chuck that so many people in c.l.f call me a liar and
not a single one of them ever says, "No, Jeff is not lying. I was 
there too and that is what Chuck said."  After complaining bitterly
to SVFIG about this myself I was shocked to see the discussion of
Chuck's presentation derailed and directed into comments about me and
"demon worship."

I don't really know why no one in SVFIG is willing to report anyting
about Chuck's presentation or even discuss it in c.l.f.  I don't know
if it is apathy, ignorance, or fear that they will be characterized
publicly as a liar or a cultist if they even discuss any of the changes
that Chuck has made to his Forth in the last fifteen years.  I think
they should change their name to the Forth Ignorance Group or perhaps
the Forth Apathy Group.

After being told one more time to shut up and leave c.l.f I decided
that I should.  I simply don't want to go there and read the disgusting
insults and terms like cultist and demon worshipers.  For a short time
I thought people in c.l.f were interested in what Chuck was going to
say in his speech, but the thread just turned into the same cultist
crap that I have been reading for years.

I just wanted to see how long it would be before someone brought up
the subject of Chuck's last presentation.  I wanted to prove the point
I have been trying to make for a long time.  I think the way the
SVFIG Talk thread was derailed before Chuck's presentation and never
came back is strong evidence.

>I would like, however, to comment on your statement about
>"...there are so many ill-mannered children in c.l.f who object
>to a single dissenting voice against ANS Forth and in support
>of some of Chuck's ideas."  I agree that some people in c.l.f
>are ill-mannered in their approach.  But others, such as Elizibeth
>Rather, did bring up some valid critizisms of your assessment
>of ANS vs Machine Forth.  

I didn't see her valid criticisms, I guess I missed them.  I
did see that she dismissed the example that I gave and said,
"Oh, that is what you are talking about.  Of course we don't
do things like that at Forth Inc."  I had never claimed that
Forth Inc. was promoting poor Forth.   She tried to make it
seem like it was the exception rather than the rule.  Of course
most of the time her stance is that many self taught Forth
programmers don't know Forth very well and that many PD Forths
are very low quality.

I did point out that I felt that having a poor Forth Standard
was a benefit to Forth Inc. since without serious professional
help the uninitiated will fall into all the traps that are
in ANS Forth many of which are being promoted as the way to go.
I did not claim that ANS Forth was bad for Forth Inc, or that
they used it to write bad code. I just said that most people
use it to write bad code because they have not paid Forth Inc.
to train them and have learned from many poor examples rather
than studying good code carefully.

I also felt that she did a disservice to the Forth
community by characterizing my stance as "trying to get people
to copy what Chuck is doing this week" when I say that they
should at least notice that he has changed Forth completely
four times in the last fifteen years while everyone else was
endlessly debating the ANS Standard.  If I recommend to people
that they really should check in on progress in Forth every
four or five years I think it is a bit unfair to distort this
so much as to claim that I am promoting the fad of the week.

>Basically its too early to draw many
>conclusions about the two other than the obvious, machine forth
>is smaller and machine forth is a better fit for MISC chips.

It many ways it is too late.  Chuck moved on from Machine Forth
years ago.  He wasn't even talking about it anymore until I
brought up the subject in c.l.f a while back.  If you wait
for years after something has come and gone and then say it is
too early to draw conclusions I wonder what conclusions you
will eventually reach.

>But when looking at your experience with the JPEG routine
>there are just too many variables such as the training of the
>two programmers, and the fact that the ANS programmer made
>a bad decision to go with using innefficient C code as a base
>to begin with.

It was certainly not an isolated incedent. It was characteristic of
hundreds of staff meetings where things clearly broke down into the
team of Machine Forth programmers and ANS Forth programmers.  This
was one example where both teams coded the same thing so it was
better than comparing assignments where one team programmed project
A and the other team programmed project B.  It was one example where
both did the same code.  One was just 100x bigger and 1000x slower.

In general what we saw consistenly was that the Machine Forth was
one to two orders of magnitude smaller and one to three orders of
magnitude faster.  There were some even more extreme examples but
those involved things like the FSL.

Decisions to go with ANS code were not bad or good.  The code was
bigger and slower with ANS, but if it was delivered soon enough to
please the investors and ran fast enough to meet the requirements
for the application it is not so much a matter of good vs bad in the
big picture.  I would argue that the larger ANS code might contain
more bugs, but I also acknowledge that it has the value of being more
portable if the company decides to switch platforms.  Managment makes 
decisions like that and not for exactly the same reasons that programmers 
classify code as good or bad.  I did not say it was bad code, nor that
anyone was a bad programmer but when someone shows you strong evidence
that someone else's code is 10x smaller and faster than theirs that
they have a knee jerk reaction.  They say you called them an idiot etc.
and usually want to ignore or dismiss things that are hard to face.

>I think it's important to look at all these issues lest someone think
>they're automatically going to get faster smaller code simply by
>switching to Machine Forth.  

I really don't think that is too much of a misconception.  If you have
good Forth style you may only see a small speedup, but it should be
there.  If you are a typical Forth programmer you should see a big
speedup.  If you are a typical ANS Forth programmer you should see
a huge speedup.  It will force you to drop many of your poor style
habits that ANS promotes.

We only have one "large" program in Machine Forth and many small
programs.  Almost all the programs were smaller than 1K.  The "large"
one is OKAD and Chuck describes it as a collection of about twenty
programs of 1k or less each.  Once again I like to contrast this to
the commercial programs that provide some of the functionality of OKAD
(and other stuff that is not appropriate for what Chuck is doing).

When company A consistently makes programs 20% larger than company
B one might not generalize that they are doing something that would
allow one to assume that all their programs will be larger.  On
the other hand when the number is 10,000% people either dismiss it
or see the obvious conclusion.

>Some in c.l.f. have mis-read what Machine Forth really is.  

I will certainly agree with that.   

>I know I've been confused, though I
>think I finally have the hand of it.  Machine Forth is not simply
>"forth designed for whatever machine you're using".  If so Pentium
>Machine Forth would look much different from MISC Machine
>Forth.  Machine Forth, like other Forths, implements a virtual
>machine, but that VM is different from "traditional" Forths and
>it's a VM that fits hand in glove with current MISC design.  But

I would agree with you.  But I would also agree with Chuck that
more important perhaps is the style of programming that falls out.

>is Machine Forth optimum for every other chip out there?  For

Optimum?  Perhaps not, but most likely a closer match than
traditional Forth.  It eliminates a number of bottlenecks by
improving the efficiency.  Many processors have instructions that
go to waste in traditional Forth implementations and which 
match Machine Forth, though certainly not as well as the match to 
MISC.

>example, SWAP was left out because it was harder to implement
>into Chuck's design.  But on other chips SWAP is as least as
>efficient to do as OVER (if not more).  I only point this out
>because in the past in c.l.f. when I've asked questions about how
>certain Machine Forth features might be done on a Pentium I've
>gotten answers from well meaning, but IMHO misguided MF
>fans that seem to be off-base.  Then again I might still be out
>in left field on this one.  :-)

SWAP is an interesting case.  Chuck defined SWAP in his Color Forth
and I believe had different types of SWAPs in his Machine Forth.  Three
of the other Machine Forth programmers never defined SWAP, the function
was just built with the primitives at hand as it seemed clearer to the
programmer.  On the MISC machines it just isn't needed.  We got used to
it not being there and it never bothered anyone except Chuck.  

Part of the problem in the things that I read about Chuck's work is that 
rather than understanding cmForth and then understanding OK then 
understanding Machine Forth then understanding Color Forth so many 
people have ignored what Chuck has done in the last
fifteen years that today people are faced with trying to catch up on
fifteen years of development (half the life of Forth) or to just ignore
it.  Chuck has moved on from Machine Forth to Color Forth which in many
ways is more like traditional Forth than Machine Forth almost four 
years ago.  Those of use who used Machine Forth for years loved it.

If one understood traditional Forth one could move on to ANS by
adding CELLS CELL+ and POSTPONE.  It could have been simple, but 
instead it has been complexified to the point that it is still
being argued after fifteen years.  If you were not well grounded
in traditional Forth I cannot imagine where you would begin in
ANS Forth.  I learned Forth in half an hour originally.  Chuck's
goal is to make it learnable in ten minutes.  I feel that ANS
really needs a college course for a full semester to get any
handle on it at all.  After all the goal was to make it look like
all the other languages that get complexified so that it takes
a signifigant investment just to get started.

Jeff Fox
Ultra Technology
----------------