Re: MISC-d Digest V99 #69

[theFox@xxxxxxxxxxxxxxxxxxx (Jeff Fox)]

>What market?  Any market that allows you ship lots of 10, 000 chips and 
>become well off for your efforts.  The embedded market might be good for 
>1000 lots or with a deal 10,000 lots.  

In Chuck's last talk he said that for 10 to 100 parts FPGAs made
sense, then there was a gap to 10000 parts that was harder to fill,
and then above 10000 custom vlsi makes sense.  It may mean some
variation on PGAs might make sense in that small number size gap
in the curves.  The custom vlsi only really look good in large
numbers.  As in we want a few hundred million to start with then
if we like them we will make a big order.  These are the kind of
embedded market deals that drive the market.  Remember the total
embedded market is billions of units per year.

>the project I've been thinking about (DES codebreaker) wordsize is
>an issue.  My code keeps the 64 bit key and data values in 4
>consecutive 32 bit words on the stack.  I suppose I could use the
>C programming style found in "Numerical recipies" and store each
>bit in a seperate word, but that just seems wasteful to me.

I have a bookmark on http://www.jya.com/craking-des.htm
Cracking DES: Secrets of Encryption Research, Wiretap Politics,
and Chip Design

It looks like an array of FPGA programmed for just that purpose is
pretty hard to beat.  All the info on how to do it is there.  One
could consider and array of custom vlsi parts I suppose.  I think
specialized FPGA or custom parts are the key. ;-)

>And what operations in ANS Forth were "degraded" as in respect to
>other Forth's like Forth-83 or figForth?

I did not mean to imply that ANS Forth was degraded vs older Forths,
in fact my bias is to nearly equate ANS Forth with Forth in 'C' which
means that I would argue it was improved from the Forth in 'C' perspective.
An ANS Forth could be implemented with the internals if F83 or
something quite like it, just add CELLS and POSTPONE as Chuck has said.

The point was that when filling out the instruction set with instructions
to make 'C' or Java compilers more happy the internals of other 
instructions may be complexified.  As a result the fewer instructions that
are required for a Forth implemention on the machine can get slowed down
as in this case.  OK, these may seem like nitpicking details from the
perspective of people working inside of the chip, you know, things like
how many actual internal cycles this instruction takes.  You know some
instructions required more cycles on a Pentium than on a 486 but most
required fewer cycles and the clock rates were higher so it seems like
they were good tradeoffs for that design.  I was just saying that there
were things added to ShBoom II that complexified some simple Forth
stuff in the original chip and added cycles.  Yes, there will be faster
clocks in the future etc so it is not a big deal.

This is the just the perspective of shaving those cycles from the
hardware and the software for what you are trying to do.  They have to
do more things to support those other compilers and it does take both
extra gates and extra cycles.

>Honestly, what I got out of what Chuck recently said about ANS Forth
>wasn't so much things left out as it was things that he didn't like being
>put in.  

I think his biggest point was that it was too much common practice with
no guidelines on how to use it as Forth.  This when combined with it
being too big, having no simple documentation anywhere, that it can
be dissasterous.  The internals are exposed to everyone and there
are many "abominations" in there that just don't belong.

If you know Forth you can write good Forth in ANS Forth systems, but
there are many examples promoted that are not really Forth at all.
They are not written for stacks or factored for Forth, but merely
simply translations of 'C' programs that you can call from a Forth
shell.  

I can't see how someone can say they hate ANS Forth, but like
>Forth-83 since the two are so similair (and I know that you didn't say
>that Jeff.)  

Well I will if you like.  I hate ANS Forth but not Forth-83 because
Forth-83 was just A Forth.  ANS Forth is THE Forth, it is a META Forth
for 'C'.  If we promote this MetaForth in 'C' specifications and
common implementation as the official definition of Forth, see the
Forth FAQ on the internet, the predictable result is that Forth will
become nothing more than one more inefficient scripting language for
'C' platforms.  It is the perfect platform for the obsfuscation of
Forth.  It is the meta specification of a mega Forth, as opposed
to Chuck's idea that a Forth system should be about 1K.  

One of the obvious directions of Chuck's idea of Forth is the idea that
you should try to do it at design time and if you can't do it at compile
time and if you can't do it at runtime.  ANS Forth promotes POSTPONE.
People discuss what POSTPONE POSTPONE POSTPONE MYWORD means.  But worse
than the alternatives include "" COMPILE MY STRING" EVALUATE RECUSE
sort of compiled string juggling in Forth in 'C' as common practice.
ANS Forth seems to love to go just the opposite direction Chuck would
go and you can easily grab libraries to do things 10,000x bigger and
slower than the way Chuck would do it for that reason.

>Chuck also felt that ANS Forth was missing out on some
>good innovation like @+ which could help write faster code without
>needing super-optimizers.  

That is true he did make that point.  As he said if you use it it
will signifigantly change the style of your code.

>I think the ANS standards committe could easily accommodate all
>of Chuck's recommendations by :

I argued with Chuck about ANS for years and years.  I ended up I think
moving past him in feeling as he say that it was a dissaster.  Look
at the Forth FAQ on the internet.  It is mostly about antique Forth
vs ANS Forth, and many statements seem to be from the if it is not
Forth in 'C' it is not Forth perspective.  Chuck has done cmForth,
Machine Forth, and Color Forth in the last fifteen years and the
only document of his I could find sited in the FAQ was from 1968.
I think the ANS standards team has a pretty obvious bias to declare
that Forth was frozen fifteen years ago and that they were made
keepers of the crystal.

But you are certainly welcome to make your suggestion through
channels if you actually think it is a good idea.  There are many
diverse interests promoted in the standard.  It would be very very
difficult I think to get any agreement on the changes you offered.
But I ack that my perspective is extreeme.

Jeff Fox