[MachineForth] 25x Forth engine

[Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx>]

Sorry for the previous empty typo post. (old keyboard)



David K Walker wrote:

> 

> About code size, I think Chuck may mean that 

> "the interesting programs" seen from his point 

> of view are what we would normally view as "very

> small", and what seems interesting for him is 

> precisely those small programs that are relevant 

> to optimizing microcode in a way that will

> (ultimately) reduce the size of larger programs.


I realized later in the message that you are
mixing Chuck's comments about consulting and
writing software for other people's problems
with his making chips that interest other
people and with his own interests.   He

is talking about *programs* and trying to
use the term the way other people use it.



He just reduces programs far more than other 

people and gets about an order of magnitude 

less code than other Forth programmers

and two orders less than people who are not

alrealy claiming to be writing 10% the code

of other people.



Of course Chuck has refered to giving plenty

of proof to any person interested enough to

take the time to read the code regarding his

"ridiculous claims." But he had only provided 

small examples, he doesn't waste time writing
a lot of examples when almost noone seems
interested.  He enjoys designing chips too much. 
Also much of his code is proprietary which means 
that the best examples of his code are not 
available for study at the present time.



He does use the term "program" a little differently

than other people, but not much.  He doesn't picture

the overhead of the OS file system loading programs

and DLL to get access to a "program" or any of
the insanity in popular software but that is about

the only real difference.  You seem to be relating
those comments to his new chip for a client.  Those
are two very different subjects.


As for what he says about writing programs.

He says OKAD is a collection of about 20 "programs" and

that he sometimes calls the whole thing "a program."   

If you don't use OKAD to do just some of the things 

that it does one needs a suite of programs that is 

LARGE by most standards, hundreds of megabytes of code.  

It is hard to count exactly how many "programs" are 

contained in all those pull down menus and dll etc. but

Chuck is really trying to use the term the way

other people use it.  His OKAD and other VLSI CAD
software is a collection of a couple of dozen programs.


So when his programs replaces other people's programs 

that are 1000 times larger to do what the client

wants done, and does it faster, more accurately,

and in a far more flexible way most people

just count the lines of code and say that 

Chuck's programs are really just 1000 times

simpler problems...  No, I am sorry but that
misses everything.  Chuck has explained this
very well in his presentations I think.


Part of Forth as practiced my Mr. Moore that

I don't see other people doing is fully exploiting

things like scaling at runtime.  Most people paste in some

equation that requires 1000 floating point calculations

to produce a rought approximation of X, Chuck will use scaling 

so his code will generate a far more accurate X with a 2/
at the same point in the program.  It is another reason
that his code is so much smaller than other people's code.

Is a 2/ done by a few thousand transistors simpler than
1000 floating point operations done by millions of
transistors?  Of course.  But both are solving exactly
the same problem at the same point in equivalent programs
so I think a comparison is valid.


It is the kind of thing that upsets people and sends them

into denial. His know knowledge of algorithms is vast and his

experince in using all the tricks in Forth is vast.  Mostly
he studies problems far far more than most programmers,
sees into them much more deeply and then factors and
optimizes far far more than most people would ever
consider doing.  Chuck is very humble about this and
says that it is nothing special, he says he just tries
harder than others.  There is a little truth to that.


He says that he won't duplicate things that are not needed,

bugs, and baggage that has to be added with other approaches.

In OKAD he doesn't have all the "programs" in the

big package, or all the bugs, but he does duplicate 

the 20 essential things in 20 "programs" as he calls them.
He studied the problem in great depth.  He has focused
his software expertise on one problem for almost
twenty years now.  He has optimized this program more
than most of his software because this is software that
he has used more than another software in his life.
  

Except that all of his "programs" are about 1K

or less.  (and do a lot of things the big programs can't
do, are ridiculously faster, and do lots of things that
most experts insist are impossible.)  So really they
are both programs doing more or less the same thing,
design and simulate CAD files in the same format,
the one used by the fabs.  But Chuck's software does
so many amazing things and the high priced spread
is so buggy and slow that it really isn't fair to
make any comparisons.

Of course some people will insist that it is unfair to
compare them because they are different in a very important
way, they require a different skill set to be used.  If you
are brain damaged Chuck's software will not work for you. But
they are different programs after all and Chuck's was designed
to be used by him.  He adapted the code to his needs and the
problem.  Most other people have to adapt their practices to
the way the programmers of the unchangable high priced software
make them do things.  But they are essentially attacking the 
same problems, designing state of the art silicon.

The programs are most different in that the high priced
spread is a good example of the current direction of such
software, to reduce the skill set of the operator to make
programmers (chip designers in this case) lower class and
lower cost replaceable parts.  Chuck simply says that there
should still be room for a few "professionals" in computing.
We see exactly the same thing in lots of other popular 
software today.  It has been intentionally dumbed down
for various reasons.


So when people insist that Chuck's software is just
toy software, and that his programs are simple because
they are small they miss everything.  They miss the
most important thing, that it is lines of code that
are removed that is more important than lines of
code that are not needed.  But most people equate
lines of code and cost with value.


It is fine until Chuck tries to quantify or report numbers 
to kindly educate other people. Then people just say that he 
_must_ be talking about something else.  They may "interpret" 
what he said in contexts that have nothing to do with Chuck's
world.

Chuck jokingly refered to his statements about 1K programs 
as ridiculous to characterize that other people just can't 
bring themselves to believe them.  I wouldn't have believed 
it myself had I not worked with him for over ten years

and seen too much evidence to argue with that point.  It was
kind of funny when I was programming manager at iTV and
noticed that not only Chuck but a number of our employees
always delived programs smaller than 1K.  

These were of course the MachineForth programmers.  Each
week they would say things like I got my assignment done
quickly so I optimized it from the original 1.5K down to
.5K yesterday and made the context switch faster and
broke the 100ns barrier!

Then the ANS Forth programmers would say, I fell further
behind schedule again this week.  I had to expand my module,
but it was _only_ another 25K.  I can't debug it.  It is
also so slow that I can't really believe it.

The MachineForth programmers often resented that they had
to spend half of their time fixing the ANS Forth programmer's
bugs and that we  kept running into the same kind of bugs
over and over.  Never in MachineForth, always in ANS Forth
and almost always around the illusion of portability.

When Chuck would express his ideas about software it would
set off some of the ANS Forth programmers worse than what
we see in c.l.f.  One liked to scream at Chuck that he 
should shut up because he as just a "hardware guy" and
didn't understand Forth or programming.  Furthermore
this person was hired because he was an ANS Forth expert!

My experience is that Chuck _does_ write about 1/10 the code 
of other Forth experts who are trying to make the code

compact on a given problem.  Although with some of the 

popular styles of Forth today and some "experts" I have
seen the ratio go to 1/100 or 1/1000 or 1/10000.  After
all many people don't care about that and think the more 
lines of code the more impressive the job.


> E.g. my 256 kbytes of Forth code for 

> administrative systems is (apparently)

> extravagant by Chuck's criteria, but probably 

> more accurately described as

> uninteresting for him since it is not 

> relevant to optimizing machine cycles

> or parallelism in general. 


You seem to mixing up Chuck's statements about
his ideas on programming with his customer's
ideas about what chips they want for their
problems.  Very very different subjects.  Do you
really think that all those applications that he
wrote for clients when he was at Forth Inc. were
things that "interested" him?  No. That is called
programming.  You give him your problem or your
old program and stand back.  (meanwhile you should
do something to prepare yourself for the coming
shock of what he does with code.)


Chuck talked for an hour about lines of code and

million line industrial applications and how

his general estimate is that give him a 10

million line app, step back and watch him.

My observations of him at work make me think

that he is just being honest no matter how

much it offends others to hear what he thinks

is reasonable.  See his fireside chat 2000

in video or html for details.



He has said that he can't imagine a problem

that would require more than 64K of his code.

Insulting isn't it? 

Chuck has quite a lot of experience.  Have
you checked out his resume on his website?
Humbling.



> However the fact that it is written in Forth

> (actually Forth-83, Laxen & Perry style, with a 

> conditional compilation alternative for Novix processors) 

> means that I can return to it as (as many

> times previously) and continue to factor it.  So I 

> interpret Chuck as saying that you can factor any 

> size code into independent networked programs, each 

> with no greater total memory requirement than 256 18-bit

> words.  



I think that would be a poor interpretation because

you are mixing his statements about consulting and

working as a software professional on _any_ software
problem with the architecture of his latest client's 
rather specialized chip. Very very different subjects.



Chuck would certainly _not_ argue that any program 
would break up or fit on 25x, hardly.  You are mixing what

he says about "Forth" and softwware consulting 

with his work in the custom chip business.  That

chip is quite specialized but his background is

quite broad.  The idea that any program will

fit 25x certainly didn't come from Chuck and will

never fly very far.

Chuck has also doen custom VLSI work on things other
than Forth chips.  He is in the custom silicon business.
He is interested in Forth and Forth chips but he has done
hardware and software that interests other people most
of the time because that is what they wanted and what
they paid him to do.  He had NO interest in parallelism
until I paid him to think about the problem, discuss it
with me for several years and then do a design that he
sold.


> The separate programs can then function 

> relatively independently in a packet-switched 

> networking environment (on chip and external to chip,

> both) depending on the memory and pipe drivers.



Yes.



> This I see as a discovery not so much about parallelism 

> and microcoding, as a discovery about packet-switching.



As long as you are not interpretting Chuck as saying

that all programs would fit or run efficiently on the

rather specialized c18 core.  Yes, for a class of

programs it is very true.  It is an interesting 
observation.



The hardware has some things in common with data-flow
architectures which are 100 times more gate efficient at
their programs than conventional computers.  But like
25x they are not for everything.
 

> Thus Andy's comments about contention and (dealing with) the risk of

> deadlock, and scaling, seem key to this direction of development.

Those are some of the multiprocessing and parallelism issues.


Your ideas about packet switching are interesting.


> Why do we get more general computing power than McRae ?  Because we have a

> smaller context to switch, and we have experience in factoring major

> applications and may ultimately reach down to the small program size

> focused by Chuck (which he seems to have reached for 0KAD after focusing on

> 10 bit addressing earlier, a matter of experience).  And because Forth

> programs are generally smaller anyway for any given application (probably

> because they are better factored?).

Yes. Of course Chuck designed his first VLSI CAD chips to mate to DRAM
chips that had 10-bit pages.  They act a little like a 1K cache in that
on-page is 3 times faster than off-page on these chips.  So it is
critical, without real cache, to factor programs into 1K word chunks
on these architectures to get performance.  Since the code _should_
be organized onto 10-bit pages because that is how the memory works,
that was how his first VLSI chips worked.  That had nothing to do
with 1K programs in OKAD except that he used OKAD to design the chips.

I also like to point that on his word addressing designs 1K 20-bit
words provide up to 4K Forth words.  4K Forth words in something
like Win32Forth is 16K bytes.  Chuck's code is about 10x more compact
than other people's code.  If you tell someone that most Forth
programs will fit in 160K bytes they don't flinch.  If you tell someone
that it is equivalent to 1600K of C they flinch.  If you tell them
that is equivalent to 1K of Chuck's code they think you are ...


Even on Intel chips, which Chuck hates, (I won't quote the things
he has said) where Forth opcodes are NOT 5-bits most of his
Forth programs have still been about 1K...  So he felt that 
1K (DRAM) chip pages and 1K branching in his chips would be best.


> Anyway, that is why I would be interested to hear more about

> packet-switching and drivers, with the proviso that it is interesting to

> link in compute-intensive stuff that can be done (possibly in steps) within

> Chuck's criterion for code size.


Chuck's comments on packet switching have been quite entertaining over
the years.  They go back to one of his P32 chips designed for
packet-switching,
very similar to F21 in many ways.

Jeff Fox
------------------------

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.