Re: MISC-d Digest V00 #6

["GARY B. LAWRENCE" <garyl@xxxxxxxxxxx>]

I just looked at Jeff Fox's web site and I saw that he has posted mips
speeds
 for the F21d part at different voltages. 
   350 mips @ 5 volts - ok 
   500 mips @ 5.5 volts - some dram chips should work at 5 + 10% = 5.5
volts 
 or 5 - 10 % = 4.5 volts and maybe down to 3 volts in some cases 
   so I can see a F21d chip at 5.5 volts running a good 500 mips but 
   600 mips @ 6 volts 
   700 mips @ 6.5 volts and 
   800 mips @ 7 volts  all seem to be too high for long term reliability 
 When I  checked the specs on nmos chips they seemed to have total chip
breakdown
 voltages around 7 to 7.5 volts regardless of the logic on chip. I would
like to know
 if your dram chips heat up badly at 6.5 to 7 volts and if you feel you
can get long
 term use out of the circuit at this high a voltage. I do remember that
RCA mcmos
 cmos chips could run up to 18 volts so that if you have found high
voltage memory
chips and you feel that the F21d is reliable at 7 volts, I would be very
pleased because
 it could run much faster - 800 mips than expected. 

  I also wanted to mention that Jeff Fox has done a very good job of
trying to explain
 how Charles Moore has gotten the advantages in code development and
chip speed that 
have been claimed. This explaination is labled - "Thoughtful
programming" and is in 
 Jeff's FORTH section. I have reread it a couple of times and it helped
me understand those things that I have done that get me the first 10x
advantage and those things that I have not done to get the other two 10x
advantages.  
 
chapter 1 - the first 10x
    the first 10x that Jeff describes I have seen myself do early on
when I used
forth on a 6502. I knew that I could take a 6502 fig listing and an
assembler and get
a working forth system. I got great joy from getting it working and
adding words to 
run a floppy disk, control dual ported ram, pias, and  add assembler
code to run a piggyback 6511q chip. I would consider this interactive
control the first 10x of forth
advantage. 

chapter 2 - the second 10x 
   It seems to me that when Jeff is talking about the second 10x the
biggest factors
involved are - refactoring and some data structure design. Going from
the 6502 running
a total forth operating system to msdos, I felt that I had lost some
freedom and understanding at the lowest level. I know that FPC has total
scource code for it's system and a very good browse feature - so that
exploring the Forth on top of dos was
not hard, but I just did not like having dos underneath it. I resisted
learning the internals of dos, hoping for a real multitasking 32 bit
operating system. I did however
get to read THINKING FORTH and this book influenced me so much that I
did a total redesign of the database that I had written. I had about 150
pages of code that were
very hard to read and so I tryed to avoid any upgrading or code fixes. I
thought that the readability issue was a "FORTH problem". Many of my
friends in my computer club
had mentioned that Forth was a "write only language". Code shown in
`Thinking Forth' showed this to be wrong. In many places the book showed
how code could be refactored
to be more readable and or faster. I recoded my database using smaller
definitions,
making some decision tables into execution arrays, and defined the
database fields inside the records using create does defining words.
Once I had this working I found
that almost all code except the field definitions could be understood
and changed with
very little trouble - perhaps 80 percent of my code was now fairly
maintainable. 
     The problem I still had with the record fields was that while I had
made them all
consistant in design, I had made the structure too complex. I had
address offsets from
the begining of the record for each field which was very good place to
start, but 
I also had offsets to actions that could be done to each field in the
field definition.
 This made it easier to find all the code that pertained to each field,
but I had to add
words to the code that set the pointer to the correct action. This had
not been a promblem with the old code because I had a separate word for
each field and action. I 
always knew what action was being done by looking at the word. I had
some trouble running down a problem caused by having all fields be in a
print action mode and using
one field to set the number of times to print the other fields. I found
that that field
had to be set to return an integer and not a print field - the print
value had set a
 do loop to a huge number. 
   I redid the field definitions so that I had a word for each field
offset and
 another word for the address of each field. I made two files holding
each set of 
 field definitions in the same order so that I could see where in either
file each
 related field definition was. Chuck was quoted in Thinking Forth as
talking about
using simple words that have just one use. He said that the Forth word
list is a giant
 case statement and by using "dumb words " you avoid many conditionial
statements. 
An example given was the use of  ."  inside a definition to compile a
string to be printed when the word is executed and .( is a word used to
display a string when
 code is being intrepeted. No additional flags have to be set to use
either one. 
    To summarize, I gained perhaps a 5x improvement in readability and
maintainability,
but I had lost some of my previous advantage back by using an outside
operating system.

 chapter 3 - the next 10x 

 If I understand Jeff correctly, he says the third 10x improvement is a
combination
of making a design simpler, refactoring the program and looking for a
way to redesign 
the whole program to remove as much extra fat as possible. I must admit
that I have
done very little in the past that comes close to achieveing any of this.
I knew that
my code was starting to look like other languages that I had lost most
of the low level
control by using msdos and windows 95, but I simply did not try to
rethink the problem
to find a total simpler solution.  I could see the great beauty of the
very simple
stack design of the F21D, but I was not aware that Chuck was trying  to
do a similar 
reduction of complexity not only in the basic forth words he uses, but
also in the software he writes. His okad does consist of a very small
amount of actual code used to
not only layout the chip design, but also to do the chip simulation. I
have a friend  
who uses a circuit board layout program that is very complex and the
early versions
of this program had a tremendous number of bugs and a very inconsistant
interface. Chuck's okad program does a job of similar or greater
complexity and it is maintained
and upgraded by one person at the same time that it is used to design
chips. The circuit
layout program was done by one team of programmers and later redone by a
different set
of programers who had to redesign the user interface for consistancy and
also debug a
tremendous number of program errors - some of which could cause lost of
a large part of
the circuit board layout. 
   I hope that all of you will read Jeff's article " Thoughtful
Programming". I found
much to help inspire me to try to get back to the joy of forth
programming. I dream of 
one day using an F21d chip with a very simple version of Forth as both
language and operating system. I would use a multimedia flash card as
storage - 16mb for $50.00 now
- good enough for use as a small hard drive and has a simple 7 pin hot
swapable  connector. I would try to use a single F21d for a single
application. I am now learning
 about the internals of Linux and it is based on the Unix main frame
structure - 
multi-tasking, multi-user - this was needed when a usable computer cost
ten dollars a minute or more to run, but if you can use F21d design for
a single use application  
instead of a cut down linux, win95, or win ce design all you would have
to do is save 1 to 4 hours on the total design time at 50 to 100 dollars
per hour to pay for the F21
system. 
   I see many problems that I personally would have to overcome to be
very productive
at using an F21 system. I have many friends who just don't understand
any of the advantages of the traditional forth designs, much less
Chuck's current machine and
 code designs. I still could get much enjoyment out of knowing that I
was using both 
hardware and software that was simple enought to totally understand yet
powerful enough
to handle most current jobs and some that can't be done by current
computers, and still
flexable enough to be quickly molded to fit a new application. 
     There is great beauty in the awesome simplicity of Chuck's work. 
		I hope this becomes apparent to may others. 
                                 Gary Lawrence