[MachineForth] Code Size, consulting vs chips

[Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx>]

David K Walker wrote: 
> It was interesting in this context to hear that the MachineForth
> programmers were able to follow Chuck's lead and had fewer 
> problems with bugs.

I thought that it was interesting that I also trained
some engineers from another company that was an investor
and was working with iTV on another project.  What amazed 
me was that they came in knowing zero about Forth and it 
took a two hour tutorial of the chip, the language, and 
the tools to turn them into effective MachineForth 
programmers. They were writing code and testing 
their own prototype hardware the next day.  They 
had not even been programmers the day before.  

Chuck and I swore that this stuff is so easy that 
we could teach it all to young children.  Chuck 
insists that he could teach them VLSI CAD.  That
*really* upsets some people.

It was SO much easier than trying to get the ideas
through to Forth programmers after they have ruined
by ANS Forth philosophy.  It is easy, and ANS Forth
programmers want to make everything complicated
and they have a very hard time with it if they have
deeply entrenched habits and think they know more
than anyone else about Forth.

I have not heard of anyone who is not already a 
programmer and learned ANS Forth, C, C++, Java, 
or whatever in two hours.  If anyone has heard
of that then please tell me where I can sign up 
for some two hour language tutorials. ;-)

They really didn't just learn a language.  They
learned everything about a processor, its architecture
and its complete instruction set, how the boot code worked,
what OS code they might want to use, how the high-level
language worked (from a user's view, not an implementor)
virtually everything we had except for the iTV internet
drivers and GUI code that they did not need for their
project.

So it made we wonder.  How long does it take to take
someone who is not already a programmer to learn 
all about the architecture of both a Pentium and 
the chipset on a PC motherboard, all of the Pentium 
instructions in complete detail, how BIOS and boot 
code works, what BIOS routines they might want to use, 
and all about Windows except the GUI and network
code?  Do you think that would take more than two
hours? ;-)

As they say in c.l.f, "If writing a Forth in assembler
doesn't scare you then you aren't doing it right." ie.
real programmers want it as complex as it can be.

As for our real programmers at iTV, to be
completely honest I also knew that the 
programmers who were writing our MachineForth 
could also easily write bug free code
in ANS Forth.  They were all sharp folks and
understood the idea of writing ANS in a
quasi-MachineForth style.  Chuck can write
in ANS too but he doesn't.

I also felt that the programmers who just did not
want to touch MachineForth and insisted that they
only work with ANS had the problems that they had
because they were so set in their ways and so
insistant that their way was right that they just
insisted that they do it the way they always did
it.  In fact one refused to compile his code
into our system ever and a second programmer was
assigned to port, compile, and debug his code
for him.  He always guaranteed us that his code
was fully debugged and would run on our system.
It never was. It was the source of most of the
bugs, and most of the killer bugs. It was a full 
time job to convert it and make it portable because 
despite his insistance that ANS Forth would make his 
code portable it didn't.  That was his job and like
many ANS Forth experts what we were doing was
quite foreign to him and he didn't want to learn.

Chuck said that his idea in designing MachineForth
included the idea that it would "enforce" good
programming habits.  In a sense it does.  I mean
really anyone can still write garbage code, but
the environment is so restricted in terms of
resources that usually the easiest way to 
get things working is to keep things simple
and be very conservative with resources.  

In that sense most of the terrible things that
ANS programmers do are simply out of the
question.  They are simply too bloated and
too complex to ever consider writing MachineForth
that way.

When iTV started they had one consultant who
was really a C programmer who was also writing
some of our first routines.  He was not anywhere
near the class of programmer that we hired later.
I remember looking at his code the first time.
His code began by initializing a lot of variables.
He started by placing 256 literals on the stack
and then stuffing them into his code to get it
fired up.  Not exactly MachineForth. 

His code was eventually fixed and optimized by
one of our ANS Forth programmers.  Later it
was fixed again by another one of our programmers
who rewrote it in MachineForth.  In going from the
second optimized ANS version to MachineForth it got 
100 times smaller and 10,000 times faster.  We saw a 
lot of that sort of thing over three years.

Also part of these huge differences can be quite
rightfully blamed on a far less than ideal
ANS Forth implementation.  Management would not
let me write it the way that Chuck and I said
it should work and some of our ANS programmers
insisted that they "fix" it.  All in all it
did let us meet all the requests and performance
levels that managment and investors wanted and
apparently all the speed that test users in
various places felt the appliance needed.

In one of our weekly programming staff meetings
I used code that one of the ANS programmers had
written to highlight how some of them were just
not listening to us and not following the 
guidelines.  I took someone's module and worked
on it before the meeting.  My first point was
that in 10 minutes I sped it by 5x.  What I
did was what I would expect from a complete beginner
to Forth, who had been given good instruction.
It was a no brainer.  It was a perfect
example of code that has simply been pasted
in without any thinking about or apparently
even looking at the code.  Then I rewrote 10%
of it in MachineForth and sped it up by another
factor of 100x.  500x before the meeting and it
was easy...

Then I asked several of the MachineForth
programmers how they would have done this 
code if they had done the whole thing.  We
all said more or less the same thing and then
I pointed out that if it had been done that
way it would have been 10,000x faster,
and probably been done with the same
effort as the ANS version.  Boy do some
people hate these stories.  But hey,
it really is not about personal issues.
This is just about understanding how a
computer architecture and computer
language work.

Our best MachineForth programmers cut their teeth
on P21 so F21 or i21 were much much easier with
more instructions and 18/17 cell depth stacks
instead of 6/4 deep stacks.   Chuck says that
6/4 is perfectly sufficient for good Forth.
He says that the 18/17 deep stacks that I 
requested on my chip and that went into i21 
and c18 and 25x is "effectively infinite."  
Michael even said that thought P21 was a 
little more fun because i21 and F21 were 
just too easy to program.

Sometimes I think that programmers should
have to spend their first few years with
systems that have 1K of memory the way
that I did, or to spend time with P21
before going to later MISC chips.  It
does help understand Chuck's ideas.

Chuck's idea of an infinitely large stack is
quite different than what ANS folks think of
as a small stack, it is smaller.  The worst case 
I have seen for ANS was one system that "needed" 
six megabytes of stack space. (but what do
you expect from a Unix in Forth. :-)

I gave everyone tutorials on how to write ANS
Forth in MachineForth style.  I did this for two
reasons: keep it simple and make it easy to port
critical code from ANS to MachineForth.  A number
of the ANS programmers simply ignored all that
and did ANS the way they always did it.  They
were experts in ANS Forth, inflexible, and had
deeply set patterns of behavior that they
did not seem to be able to break.  Most showed
no interest in breaking any habits at all
because they said they knew more about Forth
than Chuck so why listen to anyone else?

P.S.  It is nice to know that there are at least
a couple of people interested in MachineForth and
in this list.  I hope I don't drive anyone away
with my long posts about all sorts of stuff
related to the subject.
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe MachineForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main Machine Forth site   -   http://www.