Re: MISC-d Digest V97 #33

[jfox@xxxxxxxx (Jeff Fox)]

Dear MISC readers,

Wayne wrote:

>Hi guys I thought I'd submit this, as an idea instead of the Dev board 
>1Mb Rom.
>
>http://www.m-sys.com/doc2000.htm
>>       DiskOnChip® 2000
>> 
>>          * 2-24 MByte capacity (future capacities: 48, 72, 144
>>            MByte and up)
>>          * Simple, easy to use interface
>>          * 32-pin DIP JEDEC standard EPROM/FLASH compatible

There are nice things about the part.  It looks like an 8K byte
FLASH device with a bank select command.  So the EPROM/FLASH socket
would not have to change at all.  The software would require a
small change to allow paging through the 8K pages in order to
boot or access the FLASH.  The software would not have to change
for any device size since they will just mean more pages are
available.

The 2M device is $50 however and the 12M is $196.  However since
development system do not have to be as cheap as production units
the part might be a nice option for boards.

I might get some for experimentation.

I made a comment today in the comp.lang.forth newsgroup about
Chuck's recent presentation at SV FIG.  In case you missed it there
I am forwarding a copy of my thoughts for those here to read.

>From - Mon Aug 04 15:44:08 1997
Path: uunet!not-for-mail
From: Jeff Fox <jfox@ricochet.net>
Newsgroups: comp.lang.forth
Subject: Re: On Saturday July 26 1997 Chuck Moore gave a presentation to the
Date: Mon, 04 Aug 1997 10:17:22 -0700
Organization: Ultra Technology Inc.
Lines: 117
Message-ID: <33E60EA2.645F@ricochet.net>
References:
<Pine.PMDF.3.95.970730091158.676231606A-100000@cc.newcastle.edu.au>
<19970730202001.QAA22957@ladder01.news.aol.com>
<5rob7r$8r@lyra.csx.cam.ac.uk> <5s3hn7$i28$1@node17.cwnet.frontiernet.net>
Reply-To: jfox@ricochet.net
NNTP-Posting-Host: mg136-018.ricochet.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0Gold (Win95; I)
Xref: uunet comp.lang.forth:35326

John Passaniti wrote:
> 
> What Chuck must be objecting to isn't the concept of
> pull-down menus, but some specific implementations.

Remember the context of his statements.  In his search
for simplicity Chuck had reject both source code and
a Forth command line interpreter.  He had hoped that
object code with a decompiler and a menu system would
meet all his needs in OKAD (OK Assisted Design) CAD
software.  

He still has menus, he just concluded that he needed a
Forth command line also.  He needed the interactivity
of Forth to write test scripts in OKAD to test chip
designs in a repeatable way.  

His point was that menus didn't do everything he wanted
and that they couldn't replace Forth itself.  After
abanding Forth for OK for a few years he has returned
to Forth.  
His lead in point was that menus couldn't replace Forth
for Chuck.

He made other points about Forth and where he want to go
with it.  He wants to simplify it further.  He wants to
replace words like : ; ( ) COMPILE [COMPILE] IMMEDIATE etc
with a color change token that just looks like a space.
He miminized conditional codes. He used FOR NEXT in cmForth
because it was simpler than DO LOOP and he has now gone to
BEGIN constructs and has no FOR NEXT or DO LOOP.  He said
that if you are using an address you should terminate the
loop when the address equals some value rather than counting
with a loop counter.  He unrolls loops and prefers to factor
larger loops now rather than use looping code.  He said

: 5X  X X X X X ;   : 20X 5X 5X 5X 5X ;

is superior to

: 5X 20 0 DO X LOOP ;

"Good Forth miminizes the number of conditional statements.  The
minimum is zero."

He also objects to programmers applying their programming habits
from other languages when they write in Forth.  We all know what
you get when you simply translate a program from C into Forth.
He also objects to programmers relying on the features of ANS
Forth when they have "machine Forth" available.  Chuck felt
that MuP21 had stacks that were big enough but he has more
than tripled the size of the on chip stacks and insists that
they are now big enough.  This is part of the reason why he
prefers a BEGIN structure to a FOR NEXT or DO LOOP.   Not
only may there be less computational overhead in the loop,
but also fewer stack items are used.

Look at the design of the Forth system he is currently using.
It compiles subroutine calls for most words and inlined code
for some primitive words.  It is essentially an implementation
of a MISC assembler on the Pentium.  His current image of
Forth is clearly the MISC assembler instruction set or what
he likes to call Machine Forth.

For the last few years Chuck has been advocating a smaller,
cleaner, simpler, and faster approach to Forth.  He doesn't
think you should need to hire a team of lawyers to explain
the standards document for you.

The thing I liked most in his talk was the statement that anyone
should be able to learn the language in ten minutes.  I couldn't
agree more.  I would qualify his statement to say anyone over
the age of ten with an average intelligence and education
should be able to learn his Forth in ten minutes.  Teachability
was not one of the original targets in the design of Forth but
it is one of Chuck's targets today.  This is in strong contrast
to ANS Forth.  You can't teach someone ANS Forth in ten minutes.

Chuck revisits his code.  He redesigns it, he rewrites it, he
ports it to new machines.  He has designed it to support factoring,
redesign and porting.  He has not designed it to be portable to
all machines.  I suspect that part of this "the map is not the
territory" theme was about the idea that ANS code can be portable
and as such may not be a good map or a good description of a
good implementation on a given processor.

Chuck does as much as he can at design time and at compile time to
generate the most efficient run time code.  Many other Forth users
put their effort into designing code that will be portable to
different machines.  They move most of what Chuck would do at
compile time into runtime code to get something that will be
portable.  He objects when he sees code that is 10, 100, 1000,
or 10,000 times slower than the code he would write because
they insist on writing portable high level ANS Forth and using
habits and attitude that speed isn't important because their
workstation is so fast.

It seems hard to deny that Chuck is headed in a different direction
than most Forth users.  His example is to strip hardware and
software down to the bare essentials.  His efforts for the last
decade have clearly been to simplify and speed up Forth.  And
while the purpose of ANS Forth was not complicate things or
slow down the code it has made things many times more complicated.
It has caused many Forth users to focus on understanding the
meaning of the standard rather than on learning to write 
small, fast, and efficient programs.

I have been amazed many times by examples of ANS code discussed
in this group.  I often think that some of the code snippets that
I have seen here are more difficult to understand than any of
the meta compilers that I have used.  But I have had mixed
feelings about the ANS standard from the beginning.

-- 
Jeff Fox 
jfox@dnai.com    Ultra Technology Inc. 
http://www.dnai.com/~jfox/
Jeff Fox 
jfox@dnai.com    Ultra Technology Inc. 
http://www.dnai.com/~jfox/