Jeff Fox's "Anti Ansi Forth"
he...@albany.net
and Chuck call Machine Forth, "27 easy to learn
and understand Forth opcodes that take 2ns. We
took people who never learned ANSI Forth and taught
them Machine Forth in an hour and had them programming
an embedded wireless ethernet controller in it the
next day."
Most of us could spare an hour. Is there a teacher
in the house?
Anti Ansi Forth:
<http://www.UltraTechnology.com/antiansi.htm>
Leo Wong
he...@albany.net
http://www.albany.net/~hello/
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
jf...@ricochet.net
he...@albany.net wrote:
> Jeff's article contrasts ANS Forth with what Jeff
> and Chuck call Machine Forth, "27 easy to learn
> and understand Forth opcodes that take 2ns. We
> took people who never learned ANSI Forth and taught
> them Machine Forth in an hour and had them programming
> an embedded wireless ethernet controller in it the
> next day."
>
> Most of us could spare an hour. Is there a teacher
> in the house?
I trained those engineers. They got the standard two
hour lecture. virtual machine architecture, memory spaces,
instruction set, high level programming extensions, and
how to write good optimized code and know exactly how
fast it will be. That part takes about an hour.
Then they got exposure to all the tools. How to open and
run compilers and assemblers and all the tricks. How to
open and run the simulator and emulators to be sure the
ROM you make for the board is suppose to work. They
were writing working code the next day but only running
it on the emulator. But we did that for years. Then
there were some utility programs to master like the
emulator and file format converters etc. That took
a second hour.
But they have never been exposed to Forth or ANSI Forth. Some
of the ANSI Forth programmers simply would not deal with
any of the above in three years. They just wanted ANSI Forth and were
hired because they knew it.
Chuck thinks the first hour should be reduced to ten minutes.
I almost agree but I have not given it that many times to
get it down that well yet. I think one hour is reasonable.
Yet many ANSI Forth programmers at ITV could not find that
hour in several years of work. Well I guess they were
pretty overworked considering how far behind they would get
with all the complicated problems in ANS Forth that they
were dealing with. The people who got it done ahead of time
in Machine Forth would encourage them to try it at least.
It seemed to me after a few years that for most users what they
like about ANS is the license to do everything exactly the
way they have always done it. The standard was designed for that.
I think it is mostly mindset. You must empty the cup before
you can fill it. But it is worse than that. People ask for
a cup of tea and then say just poor it into this gallon bowl
of fish stew. Then they complain that they don't know why
people drink tea, it tastes just like fish stew. I don't
know if you can learn machine Forth if you were runined by ANSI.
Chuck says that he always tries the solution that everyone else
will reject first. He says that he figures it might work and
no one else ever tries it. I think he is happy with a stance
about Forth that is exactly opposite the almost complete
consensus in the Forth community about what Forth is. But I
think he also worries that ANS will certainly be the last
nail in the coffin. He has said so much.
He feels that the only hope would be to put 100M copies of
machine Forth into peoples hands and make it a standard by
numbers. I like the idea of Forth being the MISC virtual
machine. I like the idea of hundreds of millions of cheap
internet terminals with capabilities of scripting in the
MISC virtual machine in native code. Would a machine running
a few hundred million java instructions per second that costs
so little it can be given away all over the world be well
received? Well people with money know the word Java and not Forth
but the people buying a $20 terminal don't and don't care
really.
People might say that there are no people buying $20 terminals
instead of PCs but the largest internet service providers in
the largest countries in the world would like to change that.
It still could happen but I would not suggest holding your
breath or not eating until it happens.
I also think that Chuck is still right on the original idea
of Forth and that he has taken it to an incredible level
where it is so simple and so fast and so easy and so portable
that if we want a portable Forth why not use the MISC virtual
machine as a harder defintion of Forth close to metal? Being
close to the metal and making things simple is the idea of
Forth. The opposite idea is to abstract as far away from the
metal as possible and change mindset to portable code.
That strategy almost works (if you can live with the fat) if
the 'C' compilers can optimize your abstracted source into
something better than you can. But when you have no idea
how fast each word is or what the compiler might do with
your souce and need to trust in the compiler that
you don't understand I think you are getting away from the
spirit of Forth. Get close to the metal. Write good code
for everyone's sake. The MISC virtual machine and Machine
Forth as so simple.
You can implement it on anything an order of magnitude easier
than an ANSI system. The machine Forth native code compiler
is a few bytes long. It inlines a few words (some MISC opcodes)
and makes everything else calls. It is a trivial thing to do
whether you do it on something trivialy simple like a MISC
chip or even on a terribly complex chip like Pentium. That
is what Chuck did in OKAD and Color Forth. Most of the
high frequency words are optimized to the max and a call
overhead on high level words is pretty minimal.
His approach has yeilded the smallest, fastest, cleanest,
simplest, most power, most portable approach to Forth yet.
It is a order of magnitude better on these things than
many Forths and more than that on most ANSI Forths.
ANSI Forth is exactly the opposite idea of that. Abstract
everything so you really don't know where the metal is.
How do I write this and make it clean and fast if I don't
know if DUP and OVER are the same speed or if one is ten
times slower than the other? With ANS Forth I constantly
saw people selecting a high level word that did the same
thing that was closer to the metal that was 1000 times
faster. They didn't know, they didn't care, they just
wanted portibility and that is just an illusion anyway.
That was some of the meat from my article
http://www.ultratechnology.com/antiansi.htm
without the quotes from Chuck and other programmers at
ITV and the details of some of the programs.
Jeff Fox Ultra Technology
www.UltraTechnology.com
Marcel Hendrix
> Jeff's article contrasts ANS Forth with what Jeff
> and Chuck call Machine Forth,
"Jeff's article contrasts ANS Forth with what Jeff
says Chuck calls Machine Forth, ..."
Isn't it time somebody interviews Chuck again, like
Jack Woehr did for Dr. Dobb's in years gone by?
-marcel
Ian H Thain
> them Machine Forth in an hour and had them programming
> an embedded wireless ethernet controller in it the
> next day."
>
> Most of us could spare an hour. Is there a teacher
> in the house?
Does anyone know where Leo Brodie is now?
Ian H Thain
Alex Bilyk
I have got a book on Forth dated by 1988: 153 pages. Everything is in
there: language, internals future ideas and examples. Simple and easy to
understand. And now I have been looking at the ANS documents -- what a
disappointment.
Although, I find ANS as an excellent scripting language specification. It is
rather resembling a language I got to know back in 1988 -- it was called
FORTH.
AB
he...@albany.net wrote in message <7bje9c$k7$1...@nnrp1.dejanews.com>...
>Jeff's article contrasts ANS Forth with what Jeff
>and Chuck call Machine Forth, "27 easy to learn
>and understand Forth opcodes that take 2ns. We
>took people who never learned ANSI Forth and taught
>them Machine Forth in an hour and had them programming
>an embedded wireless ethernet controller in it the
>next day."
>
>Most of us could spare an hour. Is there a teacher
>in the house?
>
>Anti Ansi Forth:
>
><http://www.UltraTechnology.com/antiansi.htm>
>
>Leo Wong
>he...@albany.net
>http://www.albany.net/~hello/
>
Mary Murphy and Leo Wong
>
> > We took people who never learned ANSI Forth and taught
> > them Machine Forth in an hour and had them programming
> > an embedded wireless ethernet controller in it the
> > next day."
> >
> > Most of us could spare an hour. Is there a teacher
> > in the house?
>
>
he...@albany.net
Sounds like the length of a video. If you based the lecture
on the F21 emulator, I don't see how iTV could object.
I'd gladly pay $30 for such a tape. Any other takers?
-----------== Posted via Deja News, The Discussion Network ==----------
Mycroft
Alex Bilyk wrote:
> Great article. Good points.
>
> I have got a book on Forth dated by 1988: 153 pages. Everything is in
> there: language, internals future ideas and examples. Simple and easy to
> understand. And now I have been looking at the ANS documents -- what a
> disappointment.
>
> Although, I find ANS as an excellent scripting language specification. It is
> rather resembling a language I got to know back in 1988 -- it was called
> FORTH.
>
> AB
I've seen a lot of critizism of ANSI Forth and it's usually based on someone
trying to read the ANSI Forth document like a book. But the ANSI Forth
document is a specification, not a tutorial. It was never MEANT to be read
as a book. Admittedly I got put off a couple of times trying to read the ANSI
Forth document, thinking it would be a tutorial on ANSI Forth. Then I stumbled
upon the idea of skipping to the sections that I found pertinent and it made ALL
the difference in the world. Here's my humble guide to reading ANSI Forth:
Sections 1 - 5 : Implementation details.
Stuff like "what is a cell" and "counted strings" ect. Skip it unless you're
planning
to implement your own Forth. (Well in that case I guess everyone will be
reading
this section anyway. *S* )
Section 6 : Core and Core extension word sets
The "guts" of ANSI Forth. Although this section is probably larger than
Jeff Fox's "27 easy to learn instructions" it's still pretty small. In fact I
don't see anything in this section that is not in "Starting Forth" by Leo
Brodie. (Yes, believe or not a 1987 edition Forth book is a good place
to learn ANSI Forth!!!)
Sections 7-15 : Optional word sets
The key word here is OPTIONAL people. From what I understand a Forth
compiler only has to implement the Core word sets to be considered ANSI.
Some of the wordsets listed here are still in "Starting Forth". (Blocks and
double-words for example). Other word sets are rather new (locals and
floating point come immediately to mind.)
When you concentrate on the Core word sets ANSI Forth doesn't look so
big and overwhelming afterall. Still I would recommend "Starting Forth" or
"The Forth Programmers Handbook" for someone seeking to learn ANSI
Forth over trying to read even just the core section of the ANSI Forth
specifications.
Mike Eggleston
Mike Eggleston
Mike Eggleston
Jonah Thomas
>I'd buy it!
>he...@albany.net wrote:
>> I'd gladly pay $30 for such a tape. Any other takers?
So would I, and I don't even own a VCR.
jf...@ricochet.net
he...@albany.net wrote:
> Sounds like the length of a video. If you based the lecture
> on the F21 emulator, I don't see how iTV could object.
>
> I'd gladly pay $30 for such a tape. Any other takers?
I never thought of that. Great idea.
I will change the second hour to cover the free tools from UT
rather than the tools that I wrote at iTV and are owned by
them. Then they nothing to object to.
I could also makes tapes covering the coprocessors. They
require a lot more explantion even if you already have a
strong background in video, GUI, video accelerators, graphics,
DSP, D/A engineering, networking hardware, networking software,
parallelization techniques etc etc.
I guess it could be a whole series of tapes. Great idea. Thanks.
I have put up with a lot people saying a lot of shit about my
chip for a lot of years. Chuck told me ten years ago not to
promote my chip until it was working or no one would still
take me seriously by the time it was finished in 3 months.
It has been very frustrating for people to publish stuff that
is off by orders of magnitude and say that it is all just vaporware
anyway there are no chips. All I could say was we have been
doing demos at ITV for years but no one will invest because of
lots of uncertainty in the markets.
ITV would always complain and make it clear that my job was not
releasing iTV information. I could therefore give no facts about
real chips even though I know a lot about them.
It took me a couple of years to expand Chuck's four pages of specs
to fifty pages of tech docs. It is redundant. They contain everything.
It is there twice. But just as it took me a long time unravel
Chuck's specs and translate them to English they still don't make
much sense to people who don't have a very wide background in
all the field of information that went into the design.
To this day I have never posted a promotional document about my
chip in this newsgroup. the most I have done is to post corrections
when people say totally absurd stuff about my chip.
I often also jump in when I feel people are saying absurd stuff
about me or Chuck. I often feel that way and don't jump in to
the flame bait.
But I do get tired of the liar, snake oil salesman, and cultist
insults. I wish people realized that going around calling other
people cultists in public is similar to screaming kill the nigger
at a clan meeting. It does incite people to hate crimes. I
would have been able to do more without the hate mail.
On another subject the ANSI stance that I have recently published.
So far about ten people have said, right on, I didn't know that
I wasn't the only one who felt that way. Thanks.
Not a single person has sent me mail saying "I don't agree at all."
That is not hate mail and I would not respond to it that way.
I am willing to be convinced that I am wrong, but I am also
very stuborn.
Perhaps I could post one description of F21 to this group after
waiting ten years to get my chips. Chuck advice was not to
tell you too much that you couldn't believe too long ago.
There have been two times I have said to him, "Don't EVER mention
THAT in public." Once I added the word, "again"
Jeff Fox
> Leo Wong
> he...@albany.net
> http://www.albany.net/~hello/
>
Jonah Thomas
>On another subject the ANSI stance that I have recently published.
>So far about ten people have said, right on, I didn't know that
>I wasn't the only one who felt that way. Thanks.
>Not a single person has sent me mail saying "I don't agree at all."
>That is not hate mail and I would not respond to it that way.
>I am willing to be convinced that I am wrong, but I am also
>very stuborn.
I don't completely agree. First off, though, you're describing
your own experience, and I have no intention of telling you that
what you've seen didn't happen. Clearly it's possible to misuse
ANS Forth. It has some possible values. For example, if the iTV
Forth OS was written so that the higher-level functions were mostly
ANS then iTV might be able to port it to other processors fairly
easily. I've heard nothing to indicate whether they'd care about
that. Similarly, inefficient ANS routines could get ported to
other systems easily and optimised at will. Often it's easier to
optimise when you have a working model than when you don't have
anything that works on the system in question.
And ANS programmers could potentially be sort-of productive very
quickly. It sounds like that didn't happen for you, that they
weren't productive quickly and their learning curve leveled off
too soon. That sounds like a management problem of some sort.
If their manager wanted them to learn to write efficient code and
they insisted they were only supposed to write ANS, maybe there
was a communication problem. Still, you had a bad experience and
that shows that bad experiences are possible. I want to think
that ANS Forth could have value in some circumstances, used well.
I'd expect ANS Forth to be least useful when you're making a
one-off device. A single design that will be reprogrammed from
scratch for efficiency if anything (like the hardware) changes
significantly. It sounds like that's what iTV is doing. If you
write your code very carefully using your knowledge of which of
DUP and OVER is faster, the next version of the chip might possibly
reverse those. At some point it makes sense to optimise for
simplicity instead of for speed. If the code is simple and clear
then you can do as much optimisation for speed as you have time
for, when each new version comes out. I don't know how many
versions you have to support before that approach is best. That
isn't really a defense of ANS Forth (which can't be optimally fast
unless you use an optimising compiler which might bite you). But
it suggests that the farther you get from your drivers the more it
might pay to focus on simplicity more than on speed -- if you'll
have to support multiple models.
>Perhaps I could post one description of F21 to this group after
>waiting ten years to get my chips. Chuck advice was not to
>tell you too much that you couldn't believe too long ago.
That's excellent advice. Something that might work is to hint
at things people don't generally know, and see whether somebody
figures out the idea that's a little beyond them. They'll probably
think it's possible and get excited about it when they think of it
themselves.
Tom Zegub
Alex Bilyk <nebula-...@home.com> wrote:
>Great article. Good points.
>
>I have got a book on Forth dated by 1988: 153 pages. Everything is in
>there: language, internals future ideas and examples. Simple and easy to
>understand. And now I have been looking at the ANS documents -- what a
>disappointment.
>
My first reaction but ...
The ANS standard is something different than what many expected and
dismay, disappointment is a natural reaction. However, until the
expectations are placed aside and the standard is viewed in its own
light then its true nature and merit will be unknown.
Three points:
1) The ANS standard is not "yet another Forth." It is something of a
different category from past standards and requires a different
orientation of viewpoint. To use the terms of another poster, "the
standard is not for a Forth implementation but for a Forth interface."
Until this aspect is _well_ understood proper assessment will not be
achieved. You have one thing in your hand but another thing in your
mind.
2) The ANS standard addresses problems of portability.
Portability is an ugly affair. To a casual viewer the ugliness of
portability can easily overshadow the inherent good of the standard.
3) The ANS standard is not a document for teaching Forth. For teaching
Forth, the past books, tutorials, and systems are as good today as
then. Learn Forth first and don't get prematurely concerned with ANS
Forth and portability issues.
>Although, I find ANS as an excellent scripting language specification. It is
>rather resembling a language I got to know back in 1988 -- it was called
>FORTH.
>
I still use late 70s FIG. With a few changes and added extensions I
can align with ANS. I haven't given up any functionality but only
moved in a given direction. If forced to write a standard program, I
will loose functionality and efficiency but not because of ANS
but because of portability constraints! ANS did not cause the problem
but gives a solution.
The sweet and simple system that you have is still your best system.
However, you are enjoying its local optimization. When the need comes
to be portable, ANS provides a standard for interfacing your
system into the portable world. And most likely there are some few
changes with little cost that you can make to your current system to
be more congruent with ANS so that you can shift with ease between
your local optimized environment and the portable environment. For
instance, in FIG I changed true from 1 to -1, altered the sequence
timing of tic(k), and a couple of more things which had as little
consequence but which eases the transition when required to operate
in the ANS world.
--
Tom Zegub
WasteLand http://www.dhc.net/~tzegub
tze...@dhc.net
Philip Preston
>In article <7bm20n$a1s$1...@nnrp1.dejanews.com>,
> he...@albany.net wrote:
>
>> Sounds like the length of a video. If you based the lecture
>> on the F21 emulator, I don't see how iTV could object.
>>
>> I'd gladly pay $30 for such a tape. Any other takers?
>
>I never thought of that. Great idea.
I don't like videos but I would be very interested to know the 27 Machine
Forth instructions. Is there a published glossary of them available
anywhere?
Philip Preston.
Wil Baden
them are Hardware Forth, Firmware Forth, and Software Forth.
Chuck does Hardware Forth, or Machine Forth as he calls it. Any
Firmware Forth or Software Forth is negligible. Jeff Fox does Hardware
Forth, Firmware Forth, and Software Forth.
Firmware Forth people also do Software Forth. Newbies are mostly
interested in Software Forth. I do Software Forth but once upon a
time I did Firmware Forth.
The objective of the Standard is Firmware Forth.
So the Standard does not satisfy the Hardware Forth folks because they
don't need and don't want the superfluous.
The Firmware Forth people are not satisfied with the Standard because it
is missing things they need.
The Software Forth users are not satisfied with the Standard because it
is missing things they want, and they can't "fix" it in the Standard. So
they build non-standard Forths.
The Firmware Forth people also build non-standard Forths.
The Hardware Forth folks will never have a Standard Forth.
(
--
Wil Baden Costa Mesa, California WilB...@Netcom.com
)
Bruce R. McFarling
> The Software Forth users are not satisfied with the Standard because it
> is missing things they want, and they can't "fix" it in the Standard. So
> they build non-standard Forths.
This would seem to be a really silly reason to be dissatisfied.
Adding things which appear to be missing from the standard, using only
standard words, is an intellectual exercise, and one which is well worth
doing in the right contexts
... but for run of the mill ``software Forth'', when you need to go beyond
the limits of the ANS Forth API, *JUST DO IT*. !!! The ANS Forth is not
an *outer* limit on applications, its an *inner* limit on compliant
implementations. Since I have, in the past, identified `holes' in the ANS
Forth API which, in my opinion, ought to be filled, I might as well stress
what should be obvious: there's no pressing need to add something to ANS
Forth *just* because its missing. There's nothing wrong *or* non-standard
about an application which relies on a large number of `non-standard'
words, as long as:
(1) It doesn't provide incompatible semantics to standard words and
(2) It says what the non-standard words do.
Virtually,
Bruce R. McFarling, Newcastle, NSW
ec...@cc.newcastle.edu.au
jf...@ricochet.net
<7BA12FA98A0928E8.6094A5C3...@library-proxy.airnews.net
>, <tze...@dhc.net> wrote:
> Three points:
> 1) The ANS standard is not "yet another Forth." It is something of a
> different category from past standards and requires a different
> orientation of viewpoint. To use the terms of another poster, "the
> standard is not for a Forth implementation but for a Forth interface."
> Until this aspect is _well_ understood proper assessment will not be
> achieved. You have one thing in your hand but another thing in your
> mind.
I agree completely. I even said in my aritcle that it was an
excellent document and clearly written to express the ideas there.
I do not complain that the standard document should be a tutorial,
is a tutorial or is not as simple as any single physical implementation
of Forth can be.
What is more important than having a good standard is standardizing
on a good thing.
The ANSI Forth standard is a good standard. It is just standardizing
on something bad when compared to Forth.
I will use the terms Classic Forth, ANSI Forth, and Machine Forth here
so let me say what they mean to me first.
Classic Forth is what us old timers learned. It was the most productive
and portable thing any of us had ever seen. We all loved that we
became ten times as productive quickly. It was based on the concept
of porting the Forth Virtual Machine.
This approach made it small simple manuverable portable easily learned
and easy to use. With some good examples of code you would write good
code by thinking about a problem and mapping it to the virtual machine
implemented as a real machine on your hardware.
Code accumulated and people could read what other people had written
and published, study how it worked, and port it or rewrite it for
their own use. We made a lot of progress and lots over very clever
classic Forth examples were published.
ANSI Forth was created to standardize things in a new way. A defintion
of what was acceptable implementation practice on any type of machine
and in every style anyone had ever thought of and taken to trouble
to argue must be covered by that standard as fast as I know. I hope
someone will correct me if I am wrong and say, "Oh yeah we rejected
warp threading because of ..."
This seemed to offer more credibility in acedemia and the marketplace
and give the impression that Forth is professional.
This also seemed to offer the perfect way to make Forth truely portable, and
it is so simple and Forth-like to approach it that way. It is so clear to
start saying CELLS instead of 4 * on one machine and 2* on another machine
and nothing on our machines. (: CELLS ; on cell addressing)
Clever progammers can exploit this to write code that is portable and
which can be read better than Classic Forth because CELLS should be
distinguished from 2* or (nothing) to make the code clear in what it
means.
I also don't want to give the impression that ANSI Forth cannot generate
just as good of code as anything else, or that it cannot be used in
a manner at least as productive as Classic Forth. I'll bet it is
better when taught properly to a programmer.
I was a big enthusiast for ANSI Forth for a long time and argued with
Chuck for years until I became programming manager at iTV managing
both Machine Forth and ANSI Forth programmers who I didn't hire.
Like most environments managment always had the last say about
who was hired and what was acceptable practice. More later.
I have no doubt that using ANSI Forth compiant compilers did not result
in signifigant problems for Forth Inc. or its clients. They are famous
for understanding Forth and teaching people how to use it. If they
have had any disasters I would be very supprised.
But they do not represent a very large percentage of ANSI Forth in my
opinion. Most ANSI Forth programmers are either Classic Forth
programmers with well established habits. Some of them good, some
of them bad. They tend to have many many bad habits as a result of
reflexively saying I always do it that way rather than thinking
though all possible solutions. They often become so habitual that
they standardize on many programming style practices to the nth
degree, everything from layout to spelling and such to the more
important use of their own set of words to write their code.
Whatever habits they have from whatever language may get implemented
as a set of their own private words and dominate their code. This
in itself is not bad. But habits are hard to break.
When you start transfering your style of programming habits from
another language on top of Forth things can get pretty messed up.
What does this have to do with the standard one might ask.
Since there are massively more 'C' programmers than Forth programmers
as the years went by more and more Forth programmers were also
'C' programmers and did both. They often would want to use 'C' style
in Forth. That is just how I always do it. As long as it is ANSI,
just like 'C'. Standard ways of doing things are commonly agreed on
as good.
However Forth and 'C' are very different in many ways. The most important
was the notion in Classic Forth that thinking through the problem to
write clever code was important so they read other people's code
till they understood it, looked at examples and wrote code on their
system based on the knowledge of the actual details of the system.
They wrote good Forth code. 1. Use stacks. 2. good factoring etc
I have always said that the worst form of Forth abuse was to translate
a 'C' program into Forth. you lose 1. Use stacks and 2. good factoring.
But perhaps even more important the concept in Forth was look at it
and think it through and then write some good code, close to the metal
based on your knowledge of the system.
The style in 'C' is to use variables knowing the compiler will optimize
them for you into registers in smart way so you don't have to think
about that. The other biggest difference is that in 'C' they couldn't
live without large libraries of code to load and call. The habit that
everyone has is to use library routines for everything the same way
that everybody else does it. Just follow the examples you are given
or better yet don't think about what they are doing just trust in
your compiler and the quality of someone else's code.
This is kind of the oppostite of Classic Forth where you usually might
look at someone else's code but you HAD to think about it. You had
a chance as programmer to improve on it and tailor it to do just
what you want, and modify it to be best version of FOO for you
machine.
So if you just translate a 'C' program into Forth you have 'C'
code that will produce terrible Forth. Huge poorly factored words
thrashing countless variables instead of a little well thought out
code. But that is only responsible for things getting really bad.
The real problem is when they never even think about the problem
because someone else already translated FOO from 'C' to Forth for
them and put it in the library. You can use 'C' style and not
think about FOO, it is so easy.
Those Classic Forth people had to think about what they wrote
and we don't, we have lots of libraries available and we know
they work because they are just translations of working 'C'.
Now since there are millions of 'C' programmer to whom a tiny
library file for them to hold their portable interactive scripting
extension to them might sound like a great idea. I think it is
a great idea. It just isn't the Forth idea. It is great to
extend 'C' that way I support it.
I began to notice however that as the years went by more and more
people promoted this approach to Forth was important enought to
make sure that the ANSI Forth would support 'C'. Soon lots
of people saying that they love Forth didn't mean they loved
Classic Forth and thinking about the problem the way you do in
Forth but liked having a scriting language extention to 'C'.
The majorty of ANSI Forth enthuiasts fell into one of two camps,
Classic Forth programmers with good or bad habits that were
firmly entrenched and 'C' programmers who habits were firmly entrenched.
Both could continue doing everythign the way they always did
and everyone was happy that ANSI Forth was good for everyone.
Meanwhile Chuck was going in exactly the opposite direction. He
didn't want to have anything to do with it. He liked the Classic
approach of rethink the problem that you are really facing, don't
use too many general solutions and don't be afraid to write code.
He wanted to get closer to the metal to write better code. He
wanted to do it to be more productive. He also wanted to do it
in a portable way as he was forced to use Intel chips until he
bootstrapped to his and then his would be changing.
He felt that Forth had been the most powerful thing for him by
being simple easy to port and close to the metal so that is
the direction he went. He though and thought and though. He
came up with MISC instruction set, slightly different than
the basic words in the Classic Forth virtual machine that
he felt were clever than the words the though of decades before.
He has told you about them before.
-IF and -UNTIL and -WHILE are great! overflow, what assembler people
love and what we or 'C' never had easily and it so simple and so
powerful and so easy to learn.
@+ and !+ instead of sequences like A @ DUP 1 CELL + SWAP A ! @
etc etc
basically just a small variation on Classic Forth with some small
but very powerful things added.
cmForth matched the Novix too much. Chuck didn't really like it
after he moved on from Novix. It was too complicated he would say.
But it was a very clever optimizing native code compiler, or
a simple assembler on his Forth machine you could think of it
either way. But it was too Novix specific, the optimizations were
no good on any other machine.
But porting Machine Forth to Pentuim was an order of manitude
simpler than porting Classic Forth because the optimizing native
code compiler is just the trival assembler for the MISC virtual machine.
Implement 27 simple MISC instructions, easy on Pentium or anything
else and compile a few lines of the assembler and you have a
tiny tight optimizing native code compiler that is much closer to
the metal, much smaller, and much faster, more productive, AND
more portable than Classic Forth.
The underlying Forth in Chuck's Color Forth in his OKAD is just
that. A more Forth-like (following Forth philosophy) version of
Forth than Classic Forth.
You also just thing of it as a result of Chuck's philosophy
of thinking it through ahead of time and being will go back
and change it if you see how to improve it. After thinking
about it for a long time he saw a way to do it agian. He
figured out how to make Forth more Forth like.
Everyone who has tried it has loved it. They get so excited
they say, this is great. I feel like I did when I first learned
Forth. This is like learning Forth again.
After using it they reported to the ANSI Forth programmers how
happy they were and how the much smaller simpler underlying
native code optimizing compiler simply let them do Classic
Forth on top of the this improved virtual machine.
They still did it the old way, Forth style, they couldn't
use everything right out of Classic Forth but it was so simple
as you port it to take advantage of the improvements in the
virtual machine specification and to take advantage of their
chance to rethink the problems.
The result, Classic Forth but greatly improved by the new
virtual macine, subroutine threading and inling of many
virtual macine opcodes, and by keeping the clasic approach
and access to all the classic code examples. Some of
them even good examples.
They reported an order of magnitude better everything and
most importantly less bugs. An order of magnitude improvement
over Classic Forth. The ANSI Forth programmers were skeptical,
unconvinced and apparently experiencing just the opposite.
They wanted to keep their old style right dow every detail.
I can only write in this ANSI Forth because ... what is
the difference? It will be portable ANSI Forth and well
tested.
The problem was that it never was portable. They would insist
till they were blue in the face that it was portable and
fully debugged. Then another programmer would have to port
it and then the whole team would start searching for
the hiding portability bug. The programmer who knew and
tested the code saw no bugs. The programmer who had to port
the code saw no bugs. But when we tried to run it we all saw
bugs and couldn't find them.
This went on for years. Every week the Machine Forth programmers
would say I am a month ahead of schedule. I thought through my
code the first time and didn't have to track down bugs. I
went back and revisted it and reduced it from 3K to 2K and
made it 20% faster. But I am spending 98% of my time just
trying to find those cursid ANSI portability bugs.
The ANSI Forth programmers would deny that the bugs were theirs.
They had tested their code. But eventually we would find
those portability bugs and fix them. The ANSI Forth programmers
were usually reporting delays due to their own problems
debugging their code. And each week would report adding large
amounts of code to fix the problems. We would say how much?
Only 50K.
Chuck was not programming except in OKAD. From time to time
he couldn't take it any more. He would say this is nuts. We
have one target machine here. We have to focus on it if we
want to stay in business. Why are we even bothing to worry
about portability at this stage? Lets write code for our box.
I would say lets discuss some code I found this week. This
another example of what we don't want to do. This code
obvious came out of library and was dropped in without any
thougth. It is terrible.
It is portable.
That is the problem. But it is worse, it is also bad.
Then I would show that someone with an a few hours of
programming experiece could speed up this code 10x in ten
seconds like this. Anyone who even looked at the code
should surely do this.
But look in ten minutes I converted these 4 words only
to machine Forth and they speed up 50x and the whole thing
10x. That was 100x speedup in 10 minutes work and this
is am important system routine. And it is nothing.
Look at what the code is doing! Why isn't this being done
at compile time? If you thought through this you would not
do it this way. Every one of the Machine Forth programmers
in would have done this in less than 100ns. This code
takes 10,000 times that long. This is an embedded product
with minmal resources. Shouldn't we think about our code that way?
But it came right out a library and is a copy of 'C' code.
The portability issues and the way I always do it and the whole
idea of ANSI Forth ... This is a standard library routine. ...
Chuck was less diplomatic than I. ANSI Forth programmers would
run out of logical arguments in my opinion and yell at Chuck
that they were ANSI Forth experts and he was just a hardware
guy and didn't know as much about Forth as they did.
After seeing this over and over I came to agree with Chuck
about ANSI Forth pretty quickly. In his first talk on his
Color Forth he had said,
"I had reservations about ANSI. I worried that it would be a
dissaster and not merely a dubious advantage. All of my
fears and none of he advantages have come to pass. Any
spirit of innovation has been thouroly quenched. Underground
Forths are still needed. I said I thought the standard
should be a publication standard but they wanted an
execution standard.
There is a problem that I first say at iTV. It was the first
time I had been in the presence of a Forth project that I
wasn't contributing to. I saw how other programmers use Forth.
They don't always get it right.
Besides stacks plus colon defintions there needs to be something
else. There needs to be another book written about writing good code."
Chuck Moore 7/26/97
> 2) The ANS standard addresses problems of portability.
> Portability is an ugly affair. To a casual viewer the ugliness of
> portability can easily overshadow the inherent good of the standard.
> 3) The ANS standard is not a document for teaching Forth. For teaching
> Forth, the past books, tutorials, and systems are as good today as
> then. Learn Forth first and don't get prematurely concerned with ANS
> Forth and portability issues.
To a casual user? These were all Forth experts. Portability is
an illusion.
Anton Ertl
jf...@ricochet.net writes:
> Then I would show that someone with an a few hours of
> programming experiece could speed up this code 10x in ten
> seconds like this. Anyone who even looked at the code
> should surely do this.
>
> But look in ten minutes I converted these 4 words only
> to machine Forth and they speed up 50x and the whole thing
> 10x. That was 100x speedup in 10 minutes work and this
> is am important system routine. And it is nothing.
Could you present an example? That might be much more convincing.
BTW, I agree with you about direct transliterations from C. I just
needed one look at Wil Baden's transliteration of IIRC a compression
routine to be convinced about that.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Jonah Thomas
>What is more important than having a good standard is standardizing
>on a good thing.
>The ANSI Forth standard is a good standard. It is just standardizing
>on something bad when compared to Forth.
I can imagine that. ANS Forth had to be designed by a committee.
>Classic Forth is what us old timers learned. It was the most productive
>and portable thing any of us had ever seen. We all loved that we
>became ten times as productive quickly. It was based on the concept
>of porting the Forth Virtual Machine.
You could port *your* code easily by porting your version of the virtual
machine. If you wanted to port somebody else's code to your virtual
machine you pretty much had to understand what they were doing and
rewrite it. Classic Forth was a cluster of highly portable incompatible
languages.
>ANSI Forth was created to standardize things in a new way. A defintion
>of what was acceptable implementation practice on any type of machine
>and in every style anyone had ever thought of and taken to trouble
>to argue must be covered by that standard as fast as I know. I hope
>someone will correct me if I am wrong and say, "Oh yeah we rejected
>warp threading because of ..."
We rejected having the compiler be called by the interpreter. So
: ; POSTPONE EXIT R> DROP ; IMMEDIATE
doesn't work.
The concession for separate compiler wordlists is so slight that it
is mostly worthless.
There are some other things that were rejected, mostly things that
people don't implement very often.
>This also seemed to offer the perfect way to make Forth truely portable, and
>it is so simple and Forth-like to approach it that way. It is so clear to
>start saying CELLS instead of 4 * on one machine and 2* on another machine
>and nothing on our machines. (: CELLS ; on cell addressing)
>Clever progammers can exploit this to write code that is portable and
>which can be read better than Classic Forth because CELLS should be
>distinguished from 2* or (nothing) to make the code clear in what it
>means.
This example is clearly a good thing. Here's the problem -- ANS Forth
doesn't guarantee portability, it only *allows* it. Classic Forth code
was mostly guaranteed to be nonportable from one classic Forth to another.
ANS Forth code can be portable from one ANS Forth to another provided
it's written very carefully. I have not heard of any commercial tools
that help programmers find out whether their code is portable. You could
find a lot of problems with as few as two wildly-different ANS systems.
A lot of bad code would blow up on one or the other. A brute force
approach along those lines would involve listing the N ways that ANS Forth
systems can differ and testing the code on 2^N systems. For each pair of
differences that you could guarantee couldn't interact to produce subtle
bugs, you could cut down the number of test systems to 2^(N) - 1. And to
really find the subtle portability bugs you'd have to test boundary
conditions on each system. It's impractical to do thorough portability
testing.
So portability turns into a craft issue. "I believe my code is portable,
I'm a competent ANS Forth programmer and I've used all the tricks I know
to make it portable." You can do interactive testing to find out whether
it works on your system. You can't do interactive portability testing
until you're actually ready to port it.
The obvious ANS Forth tricks are clearly worth doing. They make code
easier to port and often easier to read. But writing code now that
will be portable later is a different problem. Suddenly you go from
the classic Forth way -- factor it, write it and test it now, go on to
the next problem, be productive -- to the classic academic way, where
you try to think out every possible problem ahead of time without
testing what you're doing. That doesn't work.
>I was a big enthusiast for ANSI Forth for a long time and argued with
>Chuck for years until I became programming manager at iTV managing
>both Machine Forth and ANSI Forth programmers who I didn't hire.
Already you're hinting at a management problem. Forth programmers are
traditionally kind of independent. And Forth doesn't in itself give
us any management advantages. How do you get a bunch of independent
Forth programmers to cooperate if they aren't inclined to?
It's probably hard to test ideas about that because when something
works it might work because the people involved actually were
inclined to cooperate this time for some other reason.
I can imagine various approaches to help with that, all of which would
be management issues. For example, you could have an explicit pecking
order, where any programmer could fire anybody lower on the chain than
he was. You'd hesitate to do it, since after all firing the wrong
people or too many people could get you fired yourself, but it would
make it clearer about who had to listen to you.
One problem with advocating innovations along these lines is that one
of them might actually get used and someday get me fired.
>I have always said that the worst form of Forth abuse was to translate
>a 'C' program into Forth. you lose 1. Use stacks and 2. good factoring.
>But perhaps even more important the concept in Forth was look at it
>and think it through and then write some good code, close to the metal
>based on your knowledge of the system.
>The style in 'C' is to use variables knowing the compiler will optimize
>them for you into registers in smart way so you don't have to think
>about that. The other biggest difference is that in 'C' they couldn't
>live without large libraries of code to load and call. The habit that
>everyone has is to use library routines for everything the same way
>that everybody else does it. Just follow the examples you are given
>or better yet don't think about what they are doing just trust in
>your compiler and the quality of someone else's code.
This approach is probably more workable after thousands of other people
have used the libraries and reported their problems, and the libraries
have gone through a couple of dozen cycles of revision.
>So if you just translate a 'C' program into Forth you have 'C'
>code that will produce terrible Forth. Huge poorly factored words
>thrashing countless variables instead of a little well thought out
>code. But that is only responsible for things getting really bad.
That's really bad.
>The real problem is when they never even think about the problem
>because someone else already translated FOO from 'C' to Forth for
>them and put it in the library. You can use 'C' style and not
>think about FOO, it is so easy.
That sounds like a real problem. I can see them thinking that they're
being productive. "I ported this C code much faster than I could have
rewritten it in Forth and tested it."
>Meanwhile Chuck was going in exactly the opposite direction. He
>didn't want to have anything to do with it. He liked the Classic
>approach of rethink the problem that you are really facing, don't
>use too many general solutions and don't be afraid to write code.
>He wanted to get closer to the metal to write better code. He
>wanted to do it to be more productive. He also wanted to do it
>in a portable way as he was forced to use Intel chips until he
>bootstrapped to his and then his would be changing.
He could be portable the old way, by porting his virtual machine.
He didn't have to think about other people's Forth systems. Maybe
that's OK for everybody. Say we have a village full of Forth
programmers. Each of us builds his own hut. There are a dozen
different brick presses in the village and they make incompatible
bricks, so when you build your own hut you use one of them or you
make your own. So long as we don't all have to get together to
build a tower we can live in a Village of Babel without too much
trouble.
.....
>They reported an order of magnitude better everything and
>most importantly less bugs. An order of magnitude improvement
>over Classic Forth. The ANSI Forth programmers were skeptical,
>unconvinced and apparently experiencing just the opposite.
>They wanted to keep their old style right dow every detail.
>I can only write in this ANSI Forth because ... what is
>the difference? It will be portable ANSI Forth and well
>tested.
This sounds like a management problem. ANS Forth is not portable
by default, you have to test for portability the same way you'd
test anything else. They should have known that. If you didn't
have the authority to tell them what you wanted and they wanted
to play politics, ANS turned into a political tool. "You have to
let me do it my way because I know what I'm doing and you don't.
Here are the reasons why I'm right and you're wrong, blah blah
.... ANS ... blah blah ... portability ... blah blah. So there."
I'm not saying that happened in your case but it sounds like a
plausible way for it to go when there are management problems.
>The problem was that it never was portable. They would insist
>till they were blue in the face that it was portable and
>fully debugged. Then another programmer would have to port
>it and then the whole team would start searching for
>the hiding portability bug. The programmer who knew and
>tested the code saw no bugs. The programmer who had to port
>the code saw no bugs. But when we tried to run it we all saw
>bugs and couldn't find them.
This is important! Somewhere along the line somebody found out
the details about each problem, right? I haven't seen much about
what sort of subtle portability bugs are likely to show up in
ANS Forth code. You guys have valuable experience, there ought
to be some way to spread the word about the details.
>This went on for years. Every week the Machine Forth programmers
>would say I am a month ahead of schedule. I thought through my
>code the first time and didn't have to track down bugs. I
>went back and revisted it and reduced it from 3K to 2K and
>made it 20% faster. But I am spending 98% of my time just
>trying to find those cursid ANSI portability bugs.
>The ANSI Forth programmers would deny that the bugs were theirs.
>They had tested their code. But eventually we would find
>those portability bugs and fix them. The ANSI Forth programmers
>were usually reporting delays due to their own problems
>debugging their code. And each week would report adding large
>amounts of code to fix the problems. We would say how much?
>Only 50K.
It sounds like two different groups.
>Chuck was not programming except in OKAD. From time to time
>he couldn't take it any more. He would say this is nuts. We
>have one target machine here. We have to focus on it if we
>want to stay in business. Why are we even bothing to worry
>about portability at this stage? Lets write code for our box.
That makes sense too. Maybe you should consider the first one
a prototype, and figure on spending just as much time writing
the second one, and only think about portability the second time
around. Keep the obvious ANS things like CELLS and forget the
rest until you need it.
>But look in ten minutes I converted these 4 words only
>to machine Forth and they speed up 50x and the whole thing
>10x. That was 100x speedup in 10 minutes work and this
>is am important system routine. And it is nothing.
So you showed them up.
>Look at what the code is doing! Why isn't this being done
>at compile time? If you thought through this you would not
>do it this way. Every one of the Machine Forth programmers
>in would have done this in less than 100ns. This code
>takes 10,000 times that long. This is an embedded product
>with minmal resources. Shouldn't we think about our code that way?
>But it came right out a library and is a copy of 'C' code.
>The portability issues and the way I always do it and the whole
>idea of ANSI Forth ... This is a standard library routine. ...
Circle the wagons boys, the Injuns are on the warpath.
>Chuck was less diplomatic than I. ANSI Forth programmers would
>run out of logical arguments in my opinion and yell at Chuck
>that they were ANSI Forth experts and he was just a hardware
>guy and didn't know as much about Forth as they did.
Going just from your description, it sounds like they weren't
as good as you and Chuck. And they couldn't learn from you.
Probably the management thing was set up so it was hard for
them to admit making any mistakes. Any time they admitted
that they were wrong and you were right they were likely to
suffer for it. So they played their ANS portability card
because it was what they had.
And this is a smokescreen that ANS Forth allows. People can
claim that their code must be portable because it's ANS. If
there are problems the problems must be in the system. There
are no tools that can confirm that a system is a standard system
(but there are some that make some tests and show up some
problems.) There are no tools that can confirm that a program
is a standard program. (There could be some tools that would
make some tests and show up some problems.) Who's right? If
you find an error in the system you can fix it and maybe
multiple problems will dissolve. If you find an error in the
program you can fix it and you're done til next time. *Before*
the problem is solved, while people are pointing their fingers
at each other and saying it isn't their fault, the claim that
somebody's code is ANS Standard Forth and therefore is correct
is just another symptom.
So here are some general suggestions concerning ANS:
1. If you're thinking about buying a Forth system, remember
that it will be easier to port other people's code to it if
it's an ANS system. That's one criterion to consider.
2. If you're building a Forth system, if you pay attention
to ANS concerns they're likely to help you build in things
that will make it easier to port other people's code to your
system.
3. If you're writing code that should be portable to other
people's systems -- particularly library code -- then you
should pay careful attention to all the little ANS matters,
and especially pay attention to the tricky parts of your
code. Notice how much you're willing to do work-arounds to
make your code more portable, versus declaring dependencies
on particular things. If you really want to do things that
aren't even ANS (like >NAME which is Forth-83 but not ANS
at all) go ahead, some systems will have problems but you
can save yourself problems now. It's good to document those
things as you notice them so the people who have problems
won't be so mystified.
4. If you're writing code that should be portable to other
hardware but that doesn't need to run on other Forth systems,
pay attention to your particular hardware requirements, and
use the obvious ANS things like CELLS and ALIGN but don't
worry about the subtleties. When it's time to port you can
port your particular virtual machine and reasonably expect
that all the problems will be hardware incompatibilities.
5. If you're part of a team and there's a bug that nobody
knows how to solve yet, and somebody says it can't be their
bug because their code is ANS, one reasonable response is
"Prove it.".
Jonah Thomas
> jf...@ricochet.net writes:
>> Then I would show that someone with an a few hours of
>> programming experiece could speed up this code 10x in ten
>> seconds like this. Anyone who even looked at the code
>> should surely do this.
>> But look in ten minutes I converted these 4 words only
>> to machine Forth and they speed up 50x and the whole thing
>> 10x. That was 100x speedup in 10 minutes work and this
>> is am important system routine. And it is nothing.
>Could you present an example? That might be much more convincing.
There's no doubt it's possible to write extensively-factored bad code.
\ data structure: tag1 1 cell
\ tag2 1 cell
\ link1 1 cell
\ link2 1 cell
\
: TAG1 ;
: TAG2 TAG1 CELL+ ;
: LINK1 TAG2 CELL+ ;
: LINK2 LINK1 CELL+ ;
If you converted those to
: TAG1 ; IMMEDIATE
: TAG2 CELL+ ;
: LINK1 [ 2 CELLS ] LITERAL + ;
: LINK2 [ 3 CELLS ] LITERAL + ;
and it turns out that LINK2 gets used heavily inside your innermost
loop, it wouldn't be surprising to get a 500x speedup even without
optimising for the particular processor.
The worse the code is to start with, the easier it is to get big
improvements.
>BTW, I agree with you about direct transliterations from C. I just
>needed one look at Wil Baden's transliteration of IIRC a compression
>routine to be convinced about that.
I remember that. One giant routine, left unfactored for "efficiency".
I wondered at the time whether he was trolling. What happened to the
idea of factoring the code and writing key fragments or innermost loops
in assembler? But I didn't try to improve it to find out what the
problems were.
Alex Bilyk
jf...@ricochet.net wrote in message <7bnrj4$tpg$1...@nnrp1.dejanews.com>...
>In article
><7BA12FA98A0928E8.6094A5C3...@library-proxy.airnews.n
et
>>, <tze...@dhc.net> wrote:
>
>> Three points:
>> 1) The ANS standard is not "yet another Forth." It is something of a
>> different category from past standards and requires a different
>> orientation of viewpoint. To use the terms of another poster, "the
>> standard is not for a Forth implementation but for a Forth interface."
>> Until this aspect is _well_ understood proper assessment will not be
>> achieved. You have one thing in your hand but another thing in your
>> mind.
>
>I agree completely. I even said in my aritcle that it was an
>excellent document and clearly written to express the ideas there.
>
>I do not complain that the standard document should be a tutorial,
>is a tutorial or is not as simple as any single physical implementation
>of Forth can be.
>
I am working on Forth interpreter implementaion and, believe you or not,
using the standard as a specification and tutorial on how the thing should
work.
>What is more important than having a good standard is standardizing
>on a good thing.
It sure is.
>The ANSI Forth standard is a good standard. It is just standardizing
>on something bad when compared to Forth.
The ANSI <whatever> standard is a good standard. It is just standardizing on
something bad when compared to <whatever>.
Hmm!? This is the type of style I often see in the ANS documents. It feels
like the thought is so deep, that English is not adequate to express it. My
favorite one so far is "3.4.1 Parsing". Absolute pearl !:)
AB
jf...@ricochet.net
an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> In article <7bnrj4$tpg$1...@nnrp1.dejanews.com>,
> jf...@ricochet.net writes:
> > programming experiece could speed up this code 10x in ten
> > seconds like this. Anyone who even looked at the code
> > should surely do this.
> >
> > But look in ten minutes I converted these 4 words only
> > to machine Forth and they speed up 50x and the whole thing
> > 10x. That was 100x speedup in 10 minutes work and this
> > is am important system routine. And it is nothing.
>
I would love to. My only reservation is that standard library
code can be found in standard libraries. It has people's names
on it.
I hate to take useful code from libraries (useful to someone for something)
and show how exactly I say someone with a couple of hours
of Forth would go cancel cancel cancel there 10x improvement by
removing unneeded stuff. This is real code written by a real
person and dropped into a real app by a real person.
Also I don't "own" the four words rewritten in Machine Forth in
ten minutes that sped it up another 10x. I could do it all again
from scratch with random code from a library or fake code if
you want. I hate to really tear into stuff with real names on it.
I am a little uncomfortable with publishing the details in public
but I am so convinced that this is what will kill Forth that I
really want to.
Wil Baden
questioned here, I'll break a rule and explain.
I have not looked at it in over 4 years; in fact I no longer
have the Forth source.
As you have guessed, it was an _automatic_ method of
translation. I was looking a way to automate translation
from C to Forth. The conversion took a very boring 3/4 hour.
As I was not inventing and eager to get through the task, I
did not add comments to the ones in the C source. Indeed I
didn't try to understand the details of the C code -- just
duplicate the logic in strict Standard Forth.
I added I/O -- efficient for my own use, ANS for the article.
It worked.
It was 8-10 times faster than my original attempt AND was a
rip-off of someone else's work AND I was foolishly worried
about a lawsuit AND I was tired of it. So I never did
anything more with it.
I don't know why I wrote: "I believe that politically correct
factoring would not help understanding and would degrade
performance." I don't think that now. It might have been
because it worked, and why bother?
I wasn't trolling, but I was trawling. I hoped someone would
do something with it. (I just now had the thought that the
quote above might have been a troll.)
--
Wil WilB...@Netcom.com
P.S. It did show that C could be converted almost mindlessly by
using PICK.
W
jf...@ricochet.net
wilb...@netcom.com (Wil Baden) wrote:
> Chuck Moore has said that there are three kinds of Forth. Good names for
> them are Hardware Forth, Firmware Forth, and Software Forth.
It helped me when I first heard you explain that.
> Chuck does Hardware Forth, or Machine Forth as he calls it. Any
> Firmware Forth or Software Forth is negligible. Jeff Fox does Hardware
> Forth, Firmware Forth, and Software Forth.
NO not at all. The point I was trying to make is that Machine Forth
evolved after Hardware Forth. Hardware Forth was cmForth 15 years
ago, ask Chuck.
Machine Forth is just Classic Forth but using the updated virtual
machine, the improved virtual machine and improved compiler over
the 30 year old stuff.
It is the most portable and Forth like because it is more easily
ported. When Chuck does his presentations and I see two or
three lines of code in Color Forth on his Pentium I recognize
it as the same as the one on P21 or i21 or F21 or Pentium or
whatever. It is very different than his concept of Hardware
Forth which was not portable at all.
Machine Forth and Hardware Forth are VERY different concepts.
To equate them misses entirely what Chuck has learned in Software
in the last 15 years. He is not just a hardware guy folks.
I have posted info about his Color Forth which evolved from
Machine Forth. But they too are different. At Ultra Technology
and iTV we had Machine Forth not Hardware Forth as it was on
Novix. Chuck learned from his mistake of not generalizing
how the optimizer would work.
The stc compiler with inlining of the 27 opcodes came from
taking advantage of abstracting the features of the improved
virtual machine to get a trivial efficient compiler. His target
was a portable way to get closer to the virtual machine.
Of course it gets incredibly close when all the most frequently
uses words are inlined as five bits instead of Pentium or
whatever instructions. But it gets you really close to the
metal that way on Pentium too.
> Firmware Forth people also do Software Forth. Newbies are mostly
> interested in Software Forth. I do Software Forth but once upon a
> time I did Firmware Forth.
>
> The objective of the Standard is Firmware Forth.
ANSI Forth was targeted for Firmware Forth really? I wasn't there
so I don't know.
> So the Standard does not satisfy the Hardware Forth folks because they
> don't need and don't want the superfluous.
sorry don't call me a hardware Forther. That is a fifteen year old
concept associated with different generation of chip. It was not
portable because it was hardware specific.
Machine Forth is classic Forth with a greatly improved virtual machine
For years we had no working chips. All I could do was play with
simulators. We tried all kinds of permutations of the virtual
machine for years. Chuck had been thinking about this problem
for twenty years. He put fifteen more years into it.
I have seen the statistical evidence of this improved virtual machine
approach. I was very skeptical at first believe me. I thought
that it was wierd. It was starting over in Forth but with a
a wierd virtual machine. I thought it was wierd.
But I found that I learned it really fast and it was so much easier
and better than the old one that my productivity went way up. I
wrote the code at about the same speed as before but it was way
smaller and way faster and simpler and had way fewer bugs and
was way easier to maintain. IT REALLY WAS JUST LIKE LEARNING
FORTH ALL OVER AGAIN. Except this time it was 10x better than
classic Forth.
The same thing happened when Chuck did this the first time. People
didn't want to hear it. They didn't want to believe it. It was
just too good etc etc.
After ten years, people are still in denial about it. They
want to equate Hardware Forth with Machine Forth. That is
nothing more than saying that you refuse to admit that
Chuck did this.
He has been up in front of you and told you this himself
many times and you will not listen to him. I see it as no
different that the resistance to the original Forth.
> The Firmware Forth people are not satisfied with the Standard because it
> is missing things they need.
>
> The Software Forth users are not satisfied with the Standard because it
> is missing things they want, and they can't "fix" it in the Standard. So
> they build non-standard Forths.
>
> The Firmware Forth people also build non-standard Forths.
>
> The Hardware Forth folks will never have a Standard Forth.
But the MACHINE FORTH people sure do. We are here. We seem to
be invisible to you but we are here. I didn't tell you this first.
Chuck Moore did, they guy who invented Forth. He didn't like
Hardware Forth after he thought about it and did something better
no one cares.
For years all they talked about was his keyboard. Nothing about
his code. I am tired of doing presentations. The insults roll
off Chuck's back and he just keeps on telling people what
they should hear even when after he explains this at Forth
Day the first two questions were "what kind of keyboard do you use?"
and "how can you tell the differnce between one and the letter i
in your CAD font."
I get so sick of that. Why should that man have to put up with
insults like that when he tells you about Forth to FIG that
is just sickening.
He does it for fifteen years, and just smiles. People insult him
and refuse to listen to what he is saying and deny that he
has ever done anything in Forth in fifteen years by saying that
Machine Forth and Hardware Forth are same thing.
I have seen ANSI Forth programmers nose to nose with Chuck. He
smiles while they shout in his face. He knows he is right. He is
not out of logical arguments or patience.
I have really tried to learn more from him than how he designs
chips or programs or even thinks. I have tried to learn how he
can be such a kind and giving and generous man. It bugs me to
read all the insults I do in c.l.f directed toward him. He is
more mature than I.
It bugs me to see him snubbed by listening him explain to everyone
how to learn Forth again and get that 10x again and have them
ask him about his keyboard and font or say, same as hardware forth.
why do you people do that?
he...@albany.net
"Philip Preston" <phi...@preston20.freeserve.co.uk> wrote:
>
> ...I would be very interested to know the 27 Machine
> Forth instructions. Is there a published glossary of them available
> anywhere?
>
One source is:
<http://pisa.rockefeller.edu:8080/MISC/F21.specs>
-----------== Posted via Deja News, The Discussion Network ==----------
Bart Lateur
>Machine Forth is just Classic Forth but using the updated virtual
>machine, the improved virtual machine and improved compiler over
>the 30 year old stuff.
>Machine Forth and Hardware Forth are VERY different concepts.
>To equate them misses entirely what Chuck has learned in Software
>in the last 15 years. He is not just a hardware guy folks.
I for one am VERY curious what improvements Chuck Moore has discovered
(or should I say "invented") for FORTH and the virtual machine, in the
last 15 years. Can you/anybody give an overview? Or are there too many
trade secrets? I'll tell you one thing: make it a booklet. I would buy
it.
I'm not sure what that one example you quoted, @+ , means. Is it a
fetch-and-increment?
Bart.
Bruce McFarling
...
>This also seemed to offer the perfect way to make Forth truely portable, and
>it is so simple and Forth-like to approach it that way. It is so clear to
>start saying CELLS instead of 4 * on one machine and 2* on another machine
>and nothing on our machines. (: CELLS ; on cell addressing)
...
There is a real big gap between ``the only viable way to'' and
``the perfect way to''. Perfection is never portable, because
portability required compromises.
>Since there are massively more 'C' programmers than Forth programmers
>as the years went by more and more Forth programmers were also
>'C' programmers and did both. They often would want to use 'C' style
>in Forth. That is just how I always do it. As long as it is ANSI,
>just like 'C'. Standard ways of doing things are commonly agreed on
>as good.
If you had said this right off the bat, everything else could
have been extrapolated. That is, ``C programmers who try to translate
C thinking into Forth tend to gravitate to ANS Forth, since it gives
them the impression of a stable target for the translation. And the
results produced by these "ANS Programmers" are horrible.''
Since its common to refer to ANS C as ANSI C, one shorthand for this
approach would be "ANSI Forth programmers".
...
>The real problem is when they never even think about the problem
>because someone else already translated FOO from 'C' to Forth for
>them and put it in the library. You can use 'C' style and not
>think about FOO, it is so easy.
>Those Classic Forth people had to think about what they wrote
>and we don't, we have lots of libraries available and we know
>they work because they are just translations of working 'C'.
!! Yeah, right. ``We know this word processor is bug free, because it
is just a translation of Word 97''.
>The majorty of ANSI Forth enthuiasts fell into one of two camps,
>Classic Forth programmers with good or bad habits that were
>firmly entrenched and 'C' programmers who habits were firmly entrenched.
>Both could continue doing everythign the way they always did
>and everyone was happy that ANSI Forth was good for everyone.
I'm still thinking that if you can be an enthusiast about ANS
Forth, you haven't gotten the interface bit. Are there RS-232C
enthusiasts? IP/UDP enthusiasts? I can see being a competent user of,
even for some to be a guru, and some who have tried other interfaces
and run into problems that don't crop up with a particular interface,
a fan, but an enthusiast for an interface is a pretty odd duck indeed.
>The problem was that it never was portable. They would insist
>till they were blue in the face that it was portable and
>fully debugged. Then another programmer would have to port
>it and then the whole team would start searching for
>the hiding portability bug. The programmer who knew and
>tested the code saw no bugs. The programmer who had to port
>the code saw no bugs. But when we tried to run it we all saw
>bugs and couldn't find them.
You can't claim that you've tested for portability until
you've tested the words on a variety of implementations. It really
ought to be at least three, with one a common way to implement a small
forth, one a common way to implement a big forth, and one specifically
designed to include things omitted in the two, and omit things
included in the two.
But you haven't tested it on anything but a single
implementation until you've tested it on more than one implementation.
Reading that, it sounds obvious. But I can not only imagine, but even
remember the mindset where I would try to work out what to do to make
the C source that I was writing on one platform be as portable as
possible.
What you really need is to have all three test bed
implementations running concurrently, and as soon as you are done
testing a word on one, you go and test is again on the other two.
Would you expect anyone to believe you that you `tested' a
piece of equipment as compatible with a hardware interface after you
have tested it to exactly one example of that interface? Of course
not.
>The ANSI Forth programmers would deny that the bugs were theirs.
>They had tested their code.
Yeah, as long as ``ANSI Forth programmers'' is read as I suggested
above, this sentence and the following ones all make a lot of sense.
(
----------
Virtually,
Bruce McFarling, Newcastle,
ec...@cc.newcastle.edu.au
)
he...@albany.net
jf...@ricochet.net wrote:
> In article <7bo1np$4v4$1...@news.tuwien.ac.at>,
> an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> > In article <7bnrj4$tpg$1...@nnrp1.dejanews.com>,
> > jf...@ricochet.net writes:
> > > programming experiece could speed up this code 10x in ten
> > > seconds like this. Anyone who even looked at the code
> > > should surely do this.
> > >
> > > But look in ten minutes I converted these 4 words only
> > > to machine Forth and they speed up 50x and the whole thing
> > > 10x. That was 100x speedup in 10 minutes work and this
> > > is am important system routine. And it is nothing.
> >
>
> I would love to. My only reservation is that standard library
> code can be found in standard libraries. It has people's names
> on it.
>
> I hate to take useful code from libraries (useful to someone for something)
> and show how exactly I say someone with a couple of hours
> of Forth would go cancel cancel cancel there 10x improvement by
> removing unneeded stuff. This is real code written by a real
> person and dropped into a real app by a real person.
>
> Also I don't "own" the four words rewritten in Machine Forth in
> ten minutes that sped it up another 10x. I could do it all again
> from scratch with random code from a library or fake code if
> you want. I hate to really tear into stuff with real names on it.
>
> I am a little uncomfortable with publishing the details in public
> but I am so convinced that this is what will kill Forth that I
> really want to.
>
I think you should take real code from real libraries. Anything
published is there is to be criticized and improved. It's
a revelation to me that programmers are even more thin-skinned
than academics and artists - I thought they loved tearing into
each others' code.
By the way, you keep on talking about ANS Forth programmers. I'm
a little surprised they even existed when iTV started up. Where
did they come from and who trained them?
In any case, give us examples of real ANS Forth code and your
Machine Forth improvements.
-----------== Posted via Deja News, The Discussion Network ==----------
he...@albany.net
jf...@ricochet.net wrote:
>
> Machine Forth is classic Forth with a greatly improved virtual machine
>
I hope that Frank Sergeant (and a few others) will take this and
run with it.
-----------== Posted via Deja News, The Discussion Network ==----------
dta...@rt66.com
You mentioned in a previous post some Forth ethernet development.
I am currently working in that arena - are there any pointers to the work you
did?
- DT
Mike Eggleston
8080.
he...@albany.net wrote:
> In article <7bndff$1r8$1...@news5.svr.pol.co.uk>,
> "Philip Preston" <phi...@preston20.freeserve.co.uk> wrote:
> >
> > ...I would be very interested to know the 27 Machine
> > Forth instructions. Is there a published glossary of them available
> > anywhere?
> >
>
> One source is:
>
> <http://pisa.rockefeller.edu:8080/MISC/F21.specs>
>
> Leo Wong
> he...@albany.net
> http://www.albany.net/~hello/
>
Mike Eggleston
I'd really like to see an implementation of Machine Forth (MForth?)!
he...@albany.net wrote:
> In article <7bolbt$ig9$1...@nnrp1.dejanews.com>,
> jf...@ricochet.net wrote:
>
> >
> > Machine Forth is classic Forth with a greatly improved virtual machine
> >
>
> I hope that Frank Sergeant (and a few others) will take this and
> run with it.
>
> Leo Wong
> he...@albany.net
> http://www.albany.net/~hello/
>
Bruce McFarling
>In article <wilbadenF...@netcom.com>,
> wilb...@netcom.com (Wil Baden) wrote:
>> Chuck Moore has said that there are three kinds of Forth. Good names for
>> them are Hardware Forth, Firmware Forth, and Software Forth.
>
>It helped me when I first heard you explain that.
>
>> Chuck does Hardware Forth, or Machine Forth as he calls it. Any
>> Firmware Forth or Software Forth is negligible. Jeff Fox does Hardware
>> Forth, Firmware Forth, and Software Forth.
>
>NO not at all. The point I was trying to make is that Machine Forth
>evolved after Hardware Forth. Hardware Forth was cmForth 15 years
>ago, ask Chuck.
>Machine Forth is just Classic Forth but using the updated virtual
>machine, the improved virtual machine and improved compiler over
>the 30 year old stuff.
Why not call it Virtual Machine Forth to capture the
difference?
Bruce McFarling
>After ten years, people are still in denial about it. They
>want to equate Hardware Forth with Machine Forth. That is
>nothing more than saying that you refuse to admit that
>Chuck did this.
This is pretty silly. I didn't know what Machine Forth denoted
until I read the explanation, which made sense, but which you now says
was not what you were talking about in the first place.
It's a bit silly to impute the equation of Hardware Forth to
Machine Forth to denial when it is perfectly easy to impute it to the
fact that the term was originally used without a clear explanation,
and for someone who has been exposed to this Hardware / Firmware /
Software distinction, Hardware Forth and Machine Forth sound almost
the same.
William Tanksley
>Machine Forth and Hardware Forth are VERY different concepts.
>To equate them misses entirely what Chuck has learned in Software
>in the last 15 years. He is not just a hardware guy folks.
There's a good excuse for missing this, I think -- we've never been told. I
find it very interesting.
>ANSI Forth was targeted for Firmware Forth really? I wasn't there
>so I don't know.
I think Wil might be thinking of OpenBoot.
>> So the Standard does not satisfy the Hardware Forth folks because they
>> don't need and don't want the superfluous.
>sorry don't call me a hardware Forther. That is a fifteen year old
>concept associated with different generation of chip. It was not
>portable because it was hardware specific.
That makes sense, but keep in mind that you've never shared this info with
us. Don't be too offended at our wrong ideas; just correct them.
>Machine Forth is classic Forth with a greatly improved virtual machine
Could you describe these improvements? Are other people allowed to
implement systems using them, or will we thus open ourselves to lawsuits?
>The same thing happened when Chuck did this the first time. People
>didn't want to hear it. They didn't want to believe it. It was
>just too good etc etc.
>After ten years, people are still in denial about it. They
>want to equate Hardware Forth with Machine Forth. That is
>nothing more than saying that you refuse to admit that
>Chuck did this.
It's more likely nothing more than never having been told. I've always
assumed that since Chuck was working on a new chip, that's what your
announcements were about.
I mean, I've heard stuff about colorForth, but that's still highly
experimental.
>He has been up in front of you and told you this himself
>many times and you will not listen to him. I see it as no
>different that the resistance to the original Forth.
You're assuming too much. You know what Chuck's talks imply because of your
shared background. Most of us have nothing to go on but roughly transcribed
talks and chip specs.
>But the MACHINE FORTH people sure do. We are here. We seem to
>be invisible to you but we are here.
You were invisible until you started speaking. Now I can see you. Aside
from your bitterness, I like what I see. Tell us more.
>no one cares.
Shrug. Learn to communicate.
>his code. I am tired of doing presentations. The insults roll
>off Chuck's back and he just keeps on telling people what
>they should hear even when after he explains this at Forth
>Day the first two questions were "what kind of keyboard do you use?"
>and "how can you tell the differnce between one and the letter i
>in your CAD font."
>I get so sick of that. Why should that man have to put up with
>insults like that when he tells you about Forth to FIG that
>is just sickening.
Those are questions, not insults.
>He does it for fifteen years, and just smiles. People insult him
>and refuse to listen to what he is saying and deny that he
>has ever done anything in Forth in fifteen years by saying that
>Machine Forth and Hardware Forth are same thing.
I'm glad that you're clarifying the terms. I wish you'd done that BEFORE
you started getting mad at us.
>why do you people do that?
"And how will they hear without a preacher?"
>Jeff Fox Ultra Technology
--
-William "Billy" Tanksley
"But you shall not escape my iambics."
-- Gaius Valerius Catullus
jf...@ricochet.net
wtan...@dolphin.openprojects.net wrote:
> Shrug. Learn to communicate.
>
> >his code. I am tired of doing presentations. The insults roll
> >off Chuck's back and he just keeps on telling people what
> >they should hear even when after he explains this at Forth
> >Day the first two questions were "what kind of keyboard do you use?"
> >and "how can you tell the differnce between one and the letter i
> >in your CAD font."
I used to get so upset when the only press Chuck was getting was
about his keyboard. This guy was doing this stuff more than ten
years ago but with three keys. That was all people could see or
talk about, even in FIG.
Chuck is wierd and not doing anything resembling ANSI Forth any more.
When Chuck is giving his speech before FIG and I am looking at
the crowd I am thinking, are these people hearing him? He has
said this so many times and shown them the code in so many
incarnations. Don't they see it?
Are they just sitting there trying to ignore him because they all
came to hear about ANSI? Are they trying to think up funny insults
or will the questions they ask have ANYTHING to do with what
he is telling them, and what I have been telling them for so
many years? Are they all going to focus on the quirkiest stuff
they can find to ignore all this brilliant stuff he is saying?
The first question, "what kind of keyboard do you use." long laughter
The second question, "how do you distinguish the 1 from the i in your CAD
font? long laughter
These people know the answers to these questions. Everyone thinks it is
funny except me. He has answered those questions a thousand times for
FIG. I don't think that he sould have to put with it myself. He is
TOO generous.
> >I get so sick of that. Why should that man have to put up with
> >insults like that when he tells you about Forth to FIG that
> >is just sickening.
really
> Those are questions, not insults.
yeah right.
So I am thinking, what are they going to ask me? the same questions
that everyone always does so they can laugh at them again? Are they
going to listen to anything this time or just all going to focus on
the quirkiest stuff they can find that is a result of funding or
compromise in some corner?
I hope they are not going to make the same jokes again.
How do you feel about your chips being so many years late? Laughter
Is it just for toys? Laughter
How fast will it run SpecFP? Laughter
They rarely dissapoint. They are just questions. They need to know.
> >why do you people do that?
>
> "And how will they hear without a preacher?"
I assume that that is a compilement rather than an insult.
Everyone knows that I have the shortest fuse when I see the discussion
start to use religious terms leading toward cultist to whip up
those who send email or worse.
Anyway I am on vacation.
Mary Murphy and Leo Wong
wrote:
>Is there source not on an odd port? I'm behind a firewall and can't reach
>8080.
>
Most relevant is:
<http://www.UltraTechnology.com/f21cpu.html#cpu>
But also look throughout Jeff's site. He might not have it for long.
William Tanksley
> wtan...@dolphin.openprojects.net wrote:
>Chuck is wierd and not doing anything resembling ANSI Forth any more.
All my friends say that too. I agree. But I admire that kind of wierdness.
>When Chuck is giving his speech before FIG and I am looking at
>the crowd I am thinking, are these people hearing him? He has
>said this so many times and shown them the code in so many
>incarnations. Don't they see it?
I wish I could attend meetings like that.
>Are they just sitting there trying to ignore him because they all
>came to hear about ANSI? Are they trying to think up funny insults
>or will the questions they ask have ANYTHING to do with what
>he is telling them, and what I have been telling them for so
>many years? Are they all going to focus on the quirkiest stuff
>they can find to ignore all this brilliant stuff he is saying?
Hard to say.
>These people know the answers to these questions. Everyone thinks it is
>funny except me. He has answered those questions a thousand times for
>FIG. I don't think that he sould have to put with it myself. He is
>TOO generous.
He seems to realize that new concepts are always tough sells.
Personally, I had *no* idea that he was working on any Forth concepts -- all
I've heard about was the microprocessor, OK, and colorForth. He doesn't
like OK (the non-Forth system) anymore. The microprocessor is really
interesting, but I don't want to learn to program a processor I can't use,
so I didn't bother learning its Forth (I thought it was merely a Hardware
Forth; nobody told me that it was the first representative of a New Forth,
the Machine Forth).
And colorForth? I can't find anything about it.
>> >I get so sick of that. Why should that man have to put up with
>> >insults like that when he tells you about Forth to FIG that
>> >is just sickening.
>really
>> Those are questions, not insults.
>yeah right.
No, really! Or at least they seemed that way to me when you mentioned them.
I see now how one could easily run out of patience -- I doubt I would have
kept trying. I do admire Chuck's persistance.
>> >why do you people do that?
>> "And how will they hear without a preacher?"
>I assume that that is a compilement rather than an insult.
You're 100% correct. Look at my past posts -- I've always been puzzled at
people who attack you for posting what Chuck's doing.
I want to know more of what he's doing. All I have is these little samplers
-- numbers, some claims, rarely any hint at an application for me. The
release of the MuP21 was an application which I could have taken, except
that I have little use for it right now.
The emulator is cool, but I didn't know that the Forth it used was anything
more than a software imitation of a hardware implementation of a crippled
Forth. Now I hear that it might be much more, and I'm interested. I guess
I'll get it and play with it for a while.
>Everyone knows that I have the shortest fuse when I see the discussion
>start to use religious terms leading toward cultist to whip up
>those who send email or worse.
Sorry. I didn't know.
>Anyway I am on vacation.
Nice of you to drop by and talk. Hope you have the time to teach more.
Anton Ertl
Jonah Thomas <jeth...@ix.netcom.com> writes:
> There's no doubt it's possible to write extensively-factored bad code.
>
> \ data structure: tag1 1 cell
> \ tag2 1 cell
> \ link1 1 cell
> \ link2 1 cell
> \
>
> : TAG1 ;
> : TAG2 TAG1 CELL+ ;
> : LINK1 TAG2 CELL+ ;
> : LINK2 LINK1 CELL+ ;
>
> If you converted those to
>
> : TAG1 ; IMMEDIATE
> : TAG2 CELL+ ;
> : LINK1 [ 2 CELLS ] LITERAL + ;
> : LINK2 [ 3 CELLS ] LITERAL + ;
>
> and it turns out that LINK2 gets used heavily inside your innermost
> loop, it wouldn't be surprising to get a 500x speedup even without
> optimising for the particular processor.
I wonder whether this hits or misses the point that Jeff Fox was
making, because both of these codes are ANS Forth.
Anyway, the 500x speedup looks extremely unlikely to me, so I did
some timings on a 486/66:
LINK2 FLINK2 SLINK2 ASLINK2
Gforth 0.4.0 138.51 50.17 11.02 53.37
bigForth 1.22 65.26 22.12 - 34.15
LINK2 is the first version above, FLIK2 the second version, and SLINK2
and ASLINK2 are versions coded like this:
struct
cell% field stag1
cell% field stag2
cell% field slink1
cell% field slink2
end-struct foo%
SLINK uses the version of field built into Gforth, ASLINK uses the ANS
Forth version (you can get it from
http://www.complang.tuwien.ac.at/forth/objects/). All these words were
embedded in a loop like this:
: benchloop
0 66666666 0 ?do loop drop ;
The times are times in seconds, with the time needed for running the
empty loop subtracted. Due to the loop count, the times also represent
the number of cycles needed on the 486/66.
We can see that we get a factor of about 3 between LINK2 and FLINK2.
The general version ASLINK2 has a slowdown factor of 1-1.5, and the
version SLINK2 (based on what would be a ";code" routine in classic
implementations) has a nice advantage even over native code
compilation.
Bernd Paysan
> LINK2 FLINK2 SLINK2 ASLINK2
> Gforth 0.4.0 138.51 50.17 11.02 53.37
> bigForth 1.22 65.26 22.12 - 34.15
> We can see that we get a factor of about 3 between LINK2 and FLINK2.
> The general version ASLINK2 has a slowdown factor of 1-1.5, and the
> version SLINK2 (based on what would be a ";code" routine in classic
> implementations) has a nice advantage even over native code
> compilation.
Well, just add "macro" behind the offset words (or use bigFORTH's
structure package). On my P200, FLINK2 gives 6,08 sec, whereas with
"macro" behind LINK2 it gives 0,698 sec (which is somewhat faster than
the empty loop, so don't trust you overcomplex CPU ;-). That's almost
ten times faster, by simply removing the call/return offset. I'm quite
aware of the reason, it's the two xchg sp,rp instructions (the
call/return overhead itself should be less).
A compiler with auto-inlining and constant folding (of inlined macros,
certainly) such as RAFTS could give identical code for slow, fast and
inlined version. But that's just an indication that the compiler has a
higher IQ than the user ;-).
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/
Bruce McFarling
wrote:
>I'd love to hear about this in a direct way, and not necessarily a
>confrontational way.
I think this pretty much hits the nail on the head. For
example, I'd like to read the conference paper distributed before the
talk which got the responses described, both to get an idea what was
in the talk and to try to puzzle out what was left out of the
conference paper, since it sounds like the kind of response you get
from an audience when they get an unexpected message `cold'.
Mary Murphy and Leo Wong
McFarling) wrote:
>On Fri, 5 Mar 1999 08:26:16 -0600, James Hague <jha...@dadgum.com>
>wrote:
>
>>I'd love to hear about this in a direct way, and not necessarily a
>>confrontational way.
>
Jeff is on vacation. I don't know if he'll be contributing to
c.l.f. during that time. I hope he won't mind if I quote from
his most recent article to the MISC List:
<BLOCKQUOTE>
I feel like we made a breakthrough this week. I think we
started a lot of people thinking about Forth and what
it is rather than focusing on the quirky details in
the ANSI standard. I feel like some people started
to get the idea that Chuck's Forths have been getting
more Forth like. From what Wil Baden called Hardware
Forth to the Machine Forth stage Chuck gave us a whole
new Forth and told us about it. There were many
distractions. He was also talking about OK, OKAD, VLSI,
transistors, design styles and other things and when
he first started it the quirkyness was very distracting.
To complicate things Chuck wasn't very good at not
jumping around himself in his perspetive as he talked
about his chip from inside of it in OKAD and from outside
of it in Machine Forth looking down at the machine.
One day he tried to explain the concept of numbers vs
patterns and how that is useful to him as he moves his
focus from inside to the outside of the chip and it
sounded like you were going to need a Phd to add 2+2
on my chip. My head was spinning and I understood
everything he said. I looked around at the room full
of people and their heads were spinning so much that
they couldn't hear a word for the rest of the hour
and were convinced that you couldn't program anything
like that. I told Chuck never to do that. Mixing
those two concepts and explaining them at the same
time did a lot damage. Stick to OKAD or Forth,
but these people are not ready for how your job is
thinking about both at once when designing either one.
MACHINE
MACHINE Chuck MACHINE<-- Forth Chuck
MACHINE
I had the feeling that many people just began to
understand about how Machine Forth was just his latest best
Forth; it is not a quirky machine.
You could implement Machine Forth or your own
variation of it on the old classic virtual machine model
or on the new MISC virtual machine. In this group [MISC List]
I think people are more willing to consider using some new
primitive Forth words and some new commands like the -IF -UNTIL
words. You could do that. Chuck has been encouraging people
to do this but not many have.
I would like to see someone port Machine Forth (the trivial
inlining stc compiler) and a small set of Forth words. Use
the classic ones, a good experiment. Do it like eForth.
That is the eForth model also to a great extent, except
no one has ported the inlining stc compiler to eForth.
The eForth philosophy is to implement a standard set of
primitive words in CODE, consider it a virtual machine,
and then write Forth for it. It is easy to port and
experiment with.
I can post the assembler from OK; it is at my site. I can
post the assembler for f21; I have several, the sources
are there. Chuck didn't like calling it assembler at iTV
because the design is a portable stc compiler with inlining
for the MISC virtual machine. In fact the machine is not
virtual for Chuck. He doesn't even call it Virtual Machine
Forth on the Pentium. He calls it Machine Forth.
Other people can and should experiment with it. It is so
simple so powerful so productive to face the machine and
think about the code you are writing. I don't think that
the improvements that Chuck added are as important as
that mentality of facing down at the machine rather
than looking away.
cmForth had neat tricks and I marvel over it for years. But
it was an assembler because its optimizations were totally
Novix specific. It was ported to RTX and by Frank to Intel.
People liked it but it never caught on widely as an approach.
I hope that this new more portable approach of using a
trivially simple stc assembler and inlining the kernel words
will catch on with both classic virtual machine implementations
and MISC virtual machine implementations. I did some of that
sort of thing for a couple of years and gave Chuck lots
of feedback about the relative usability of the changes
to the instructions by comparing the simulated performance
of code matched to one set of instructions compared to another
set.
It could be mixed with tokenized Forth to get smaller opcodes
that pack like MISC along with bit threading. That would
certainly be an interesing implemention to see documented
and compared to other approaches.
...
It was always easy to change the instructions on a simulated
processor, modify the Forth, port code and compare. You can
also do the same thing easily on any computer by implementing
different virtual machines, writing some code for them
and comparing results.
I don't really think we want to standardize too much on
this set of instructions and stick to it. Chuck won't.
If he thinks of a better one he will switch to it tomorrow.
Do you know how much fun it is to call him up and tell him
about your new instruction and have him say great I
will add that. thanks. You can do that folks. Think,
experiment. Design your improvements, add new optimizations
to the trivial compiler. Don't be afraid of a new
virtual machine that makes you think about moving the
code to it to take advantage of new things. The main thing
is look down at the machine and think about it.
...
Jeff Fox
Fervorish to the point that maybe feverish is a better term. ;-)
</BLOCKQUOTE>
Reuben Thomas
>On Fri, 05 Mar 1999 13:24:13 -0600, Mike Eggleston <mi...@spindle.net>
>wrote:
>
>>Is there source not on an odd port? I'm behind a firewall and can't reach
>>8080.
>>
>
>Most relevant is:
>
><http://www.UltraTechnology.com/f21cpu.html#cpu>
I had a look at the original ref. given, and have a few questions for
anyone who can answer them:
1. Several of the 27 instruction codes don't have associated F21
instructions. Are they higher level instructions? Or what?
2. Surely "call" is not equivalent to : in Forth, but to EXECUTE.
3. There's something wrong with the section on the analog processor
because several lines about interrupt handling are repeated there. I
looked on Jeff's site, but the stuff there is even more garbled,
especially the ref. given above.
4. The first word in the code to end an interrupt should, it seems to me,
be A@, not A (there's no instruction "A" anyway).
--
http://www.cl.cam.ac.uk/users/rrt1001/ | maxim, n. wisdom for fools
brad...@hotmail.com
> But I found that I learned it really fast and it was so much easier
> and better than the old one that my productivity went way up. I
> wrote the code at about the same speed as before but it was way
> smaller and way faster and simpler and had way fewer bugs and
> was way easier to maintain. IT REALLY WAS JUST LIKE LEARNING
> FORTH ALL OVER AGAIN. Except this time it was 10x better than
> classic Forth.
Well you have our attention! I've been mulling over a set of low level
primitives that I could base my Forths on, but I just kept to CORE words.
But, your 27 F21 primitives look very useful -- I like 'em. They ought to
map well to the processors I have to choose from. Looking at the instruction
set, I gather that a lot of ANS words need at least a few F21 instructions.
More importantly, some awkward ANS Forth sequences I use sometimes can be
replaced by very few F21 instructions. This must have been the case with
your "quick speedup" example.
> For years all they talked about was his keyboard. Nothing about
> his code. I am tired of doing presentations. The insults roll
> off Chuck's back and he just keeps on telling people what
> they should hear even when after he explains this at Forth
> Day the first two questions were "what kind of keyboard do you use?"
> and "how can you tell the differnce between one and the letter i
> in your CAD font."
>
I think you or FIG should sell videos of his presentations. I'd buy one. FIG
is already an informal atmosphere (kind of a social gathering), and Chuck's
humor probably makes it more so. Is it any wonder he gets flippant
questions? The home viewer will more likely be out for information. Plus,
he/she can rewind the tape on the tough parts.
> I have seen ANSI Forth programmers nose to nose with Chuck. He
> smiles while they shout in his face. He knows he is right. He is
> not out of logical arguments or patience.
>
A good respone for this kind of situation is "Let's settle this in the lab".
Apparently, Chuck figured out human nature long ago.
> why do you people do that?
>
You ought to know "us" better than that. Most of the people who read this
newsgroup don't post very often. But when somebody flames Forth, some of the
best minds in the business come out of the woodwork.
Please keep posting your ideas, they don't fall on deaf ears. Good ideas
usually take years to be accepted, but somebody has to plant the seed.
-- Brad Eckert
M.Simon
Jeff needs to take some time off. I think he has lost it. I hope he
gets better.
Here is something I wrote to the MISC list as a general reply to
Jeff's concerns:
FORTH chips are a hard sell.
Technology businesses are about risk management.
(Don Lancaster has some interesting things to say about this)
So how do we sell FORTH while keeping risk low?
FPGAs.
Companies are putting processors on FPGAs as we speak.
We can provide better, faster, cheaper.
And the risk is low because if our processor isn't as advertized
there are other places to get something to do the job.
Once we make our mark in FPGAs some of Chuck's and Jeff's
wilder designs will be saleable.
I offer tools at a very reasonable price for FPGA processor design.
M.Simon
hardware. Especially when you can experiment with hardware structures.
The power to try instruction sets in real hardware. And change them.
See my sig at the bottom of the page for a URL. FORTH in FPGA.
A desktop silicon foundry. And the price is reasonable.
Simon
=======================
On Fri, 05 Mar 1999 13:30:42 -0600, Mike Eggleston <mi...@spindle.net>
wrote:
>I second this heartily!
>I'd really like to see an implementation of Machine Forth (MForth?)!
>
>he...@albany.net wrote:
>
>> In article <7bolbt$ig9$1...@nnrp1.dejanews.com>,
>> jf...@ricochet.net wrote:
>>
>> >
>> > Machine Forth is classic Forth with a greatly improved virtual machine
>> >
>>
>> I hope that Frank Sergeant (and a few others) will take this and
>> run with it.
>>
>> Leo Wong
>> he...@albany.net
>> http://www.albany.net/~hello/
>>
>> -----------== Posted via Deja News, The Discussion Network ==----------
>> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
=========================================================
M.Simon
If people keep asking the same dumb questions then your explanations
are unclear.
OTOH it wasn't until I started designing FORTH chips that I saw the
deeper beauty of Chuck's designs.
He uses inherent gate delays in his chips to make them faster with
less hardware. Brilliant.
My answer:
Do it yourself. See the Design Your Own Processor Tools at my URL.
M.Simon
I think Jeff has given up too soon.
Perhaps what we need is a commercialize FORTH consortium.
Perhaps we could computerize Habitat for Humanity Houses or some other
humaitarian project to get more recognition.
I will be glad to design and build any hardware required to prototype
the design. And provide the software to interface to the hardware.
Open system. Totally free.
Lets get together.
M.Simon
portable more or less effort than just porting it?
If you can do it in 10 or 20K of code who cares if you have to rewrite
a bunch to optimize it for a particular machine.
Windows -2K
TCP/IP -3K
Hardware interface .5K
Rest of application ~15K
Ideas are portable. Implimentations are not.
I think the model here is appliance programming. You program for the
hardware you have rather than all possible sets of hardware.
The concept is difficult to hack because most software people are not
deep into hardware and most hardware people are not deep into
software.
With the above type of interface you could have an affordable Internet
Toaster.
Simon
========================================================
>(
>----------
>Virtually,
>
>Bruce McFarling, Newcastle,
>ec...@cc.newcastle.edu.au
>)
M.Simon
Machine FORTH. Designing the application for a specific machine rather
than all possible machines. Keep the application simple. Throw out
enough so that it fits in 16K of RAM and 20K of EPROM.
We get bloated slow systems by trying to do too many what-ifs.
Suppose word processors only did the few things that 80% want. And the
output is some standard type file. Call another program to print the
file. A simple window program could tie all the stuff together. And
each piece is replaceable without having to know the internals of
other pieces. Passed parameters on the stack because simple systems
require few passed parameters. An old fashioned menu system with a
pretty interface.
Make the internals of your FORTH such that FORTH words can be replaced
with machine OP codes. There should be no FORTH interpreter per se
just a FORTH assembler. This is what Chuck means when he says he can
do Machine FORTH on any machine.
This is very different than the interpreted or virtual machine style
of programming. Nothing is interpreted, nothing is virtual. Its just
assemble and run.
Am I getting it Jeff?
Simon
======================================================
On Sat, 6 Mar 1999 00:21:02 -0500, "Michael and Anne Losh"
<ml...@tir.com> wrote:
>James Hague wrote in message ...
>>Jeff Fox wrote:
>>
>>>It bugs me to see him snubbed by listening him explain to everyone
>>>how to learn Forth again and get that 10x again and have them
>>>ask him about his keyboard and font or say, same as hardware forth.
>>
>>I'm always eager to hear what Chuck has to say, as he always has a
>>profound effect on my thinking. I think it would be worthwhile for Chuck
>>to write an informal paper about programming in machine Forth. ...
>
>>I've read the fireside chats over the last eight or so years. I've read
>>the ColorForth bits at <http://www.ultratechnology.com>. I've read the
>>specs of P21 and friends. I even bought a copy of OK from Offete. But
>>apparently I'm missing the big picture. I don't know what the new
>>abstract machine is. I don't know where the 10x benefit is coming from.
>>
>>I'd love to hear about this in a direct way, and not necessarily a
>>confrontational way.
>>
>>--
>>James Hague
>
>
>James has put this very well. I too have been following Chuck and Jeff Fox
>for the same length of time, in the same ways. I think several of us feel a
>sense of disconnection... we hear bits about what they do and a brief
>explaination of how they do it, but feel that we are missing some critical
>information. Or we cannot see how work is really done because we are not
>there. I have tried to read the older source code listings for Chuck's OK
>system from Dr. Ting's journals. It was very interesting, but much was
>difficult to understand. Without extensive documentation or "being there,"
>I can only guess at some of the thought-process that went into it, such as
>the failed experiments, alternative implementations, the engineering
>trade-offs, the things intentionally left out (and why), etc. etc.
>
>Perhaps Machine Forth is so simple that we are yearning to find something
>that really isn't there. We miss what is right in front of us because we
>are looking farther out. I can say that the video tapes that Ultra
>Technology sells did help me get a clearer picture of how Chuck's tools work
>and a bit about how are used.
>
>Chuck and Jeff and Dr. Ting have been influential in my own work and
>projects. My version of eForth for Java is based on a VM that has a few
>similarities to the Machine Forth VM. That system is now being expanded by
>others, including some ANS complience changes. I have mixed feelings about
>this. The code contributions from others have been good quality. The
>eForth model I started with has significant deficiencies, both in terms of
>features and performance, so some of the ANS features make this Forth more
>comfortable. My goal was a web-based Forth Demo system. Perhaps a basic
>level of ANS-complience makes this demo relevant to a wider number of
>people. But it is also making this applet larger and perhaps more difficult
>to understand. (To see the older, non-ANS eForth for Java, click over to
>http://www.amsystech.com/mlosh/ . The ANS version should be ready for
>public consumption in a few weeks or months, and will be released under the
>GPL. Due to family responsibilities and other conflicts, I wll be naming a
>code custodian to take over the guidance of this project.) It will be
>interesting to see how this system evolves now that I have opened it up to
>other contributors.
>
>I too would also be interested in a two-hour tutorial video by Jeff about
>Machine Forth or an overview in print or on video of the Machine Forth
>programming process from Chuck himself. I know these people have their own
>projects and agendas, but obviously there are several of us here with open
>minds and an interest in a fresh approach to Forth.
>--
>Michael A. Losh
>
jf...@ricochet.net
describe their machine, then give numbers.
> \ data structure: tag1 1 cell
> \ tag2 1 cell
> \ link1 1 cell
> \ link2 1 cell
> \
>
> : TAG1
> I did some timings on a 486/66:
>
> LINK2 FLINK2 SLINK2 ASLINK2
> Gforth 0.4.0 138.51 50.17 11.02 53.37
> bigForth 1.22 65.26 22.12 - 34.15
but they never post units! This is honestly a problem for me. Are
we talking femtoseconds, picoseconds, nanoseconds, microseconds,
milliseconds, or seconds here?
How can I compare it to my code? I know we are talking about the
same process technology but what people do with it means that if
you don't post units it hard to follow for people who constantly
see several orders of magnitudes differences between systems.
makes it hard for me. I am not familiar enough with your Forths
to know the units you are talking about.
2-42
Jeff Fox Ultra Technology
www.UltraTechnology.com
-----------== Posted via Deja News, The Discussion Network ==----------
jf...@ricochet.net
> But that's just an indication that the compiler has a
> higher IQ than the user ;-).
;-)
Anton Ertl
jf...@ricochet.net writes:
[I wrote (but Jeff Fox apparently has a problem attributing stuff he
criticizes:-):]
> > I did some timings on a 486/66:
> >
> > LINK2 FLINK2 SLINK2 ASLINK2
> > Gforth 0.4.0 138.51 50.17 11.02 53.37
> > bigForth 1.22 65.26 22.12 - 34.15
>
> but they never post units!
Careful reading before deleting would have revealed that I wrote:
> The times are times in seconds, with the time needed for running the
> empty loop subtracted. Due to the loop count, the times also represent
> the number of cycles needed on the 486/66.
- anton
jf...@ricochet.net
msi...@tefbbs.com wrote:
>
> Machine FORTH. Designing the application for a specific machine rather
> than all possible machines. Keep the application simple. Throw out
> enough so that it fits in 16K of RAM and 20K of EPROM.
Machine Forth includes the concept of thinking that you are above
the machine. The machine is below you, look down at it and think
about the code you are writing. Look for obvious ways to improve
it now that you know more than you did when you or someone else
wrote the code. Take any advantage of the machine you are looking at.
You may be looking down at a Virtual Machine, you may be looking
down at real machine, but see it for what it is and think about
what you are doing.
This is the opposite of looking up away from the machine and abstracting
your code to make universal. If you start with that approach there
is a lot of code out there you can grab and use the same way with
minimal thinking.
It is almost as simple as this: one side likes minimal effort and
thinks the way to do it is with abstraction and looking away from
the machine to minimize maintenance and porting work by having
portable code and being able to use other's people code without
thinking about it.
The other side likes minimal effort and thinks the way to do it is
to look at the present situation, problem and machine and think
about the code that is written. They think that this minimizes
maintenance by minimizing bugs and making the best code. They
are also not afraid to maintain it or rewrite it because they
enjoy thinking about it again and doing a better job now that
they have learned how to think better. They want to keep thinking
better and better all the time.
Forth is not just about writing code. How to think through the
problem and then write good code is part of Forth that is hard
to put into a particular implementation or standard.
These two opposing points of view are what distinguished us, the
Forth community from most of the rest of comp sci, not our
smaller, faster, better code or higher productivity. It gave
us a way to think better.
Avoiding thinking will not minimize your work or the overall effort
folks.
This is the underlying idea as I see it behind Forth and Machine
Forth.
Look down at the machine even if it is virtual, think of yourself
as smart, maybe smarter than the machine, maybe smarter than the
compiler. Don't be afraid to give it a try. Look down at the
machine, think, and face reality.
Don't throw out anything useful, but whenever you have the opportunity
throw out anything that you can. Don't be afraid to think, revisit
or rewite code. You just might be smarter now, and you just might
get a little smarter if you look at it again, think about it again,
and rewrite it again.
> This is very different than the interpreted or virtual machine style
> of programming. Nothing is interpreted, nothing is virtual. Its just
> assemble and run.
Well by looking at the machine you can get closer to it. Chuck and
those working on designs, or even those simulating machines can
even get inside of them. In that case your Machine Forth is facing
the machine and if you don't like what you see, you can change it
if you think enough and find a way to improve it.
Chuck still calls it Machine Forth on his Pentium even though he
has a virtual F21 implementation in Pentium opcodes. He sees this
as the easiest way to program Pentium. He can switch to assembler
and insert Pentium opcodes other than those in the 27 macros but
hasn't seen a need. He is pleased with the size and speed of his code
and is facing a simpler machine than Pentium. Much the same way
that we faced the virtual machine in the old days.
> Am I getting it Jeff?
Yes, but you are like Chuck in that your perspective moves from
how to improve the insides of a chip to improve what you do on
the outside to some other problems. You are working on two problems
at once and this confuses many people. Just as metacompilation
confuses newbies, that sort of machine/software metacompilation of
Forth tends to confuse people doing software only.
I saw Chuck last night and we talked for about six hours about
the sad direction of the Forth community for so long and what our
options are at the crossroads that we each are facing.
I told him how the first time he talked about F21 for FIG he would
mix one sentance about what he had to think about while wearing his
CAD hat and from inside of the chip and then in the next sentance how
it would look to Chuck the programmer in the mirror from outside
of the chip. Then he talked about his persective of trying to improve
both to get the simplest combination of hardware and software. He
was doing this while mixing examples of his concepts of numbers
and patterns (that he was using at time to do this mental gymnastics)
while using a simple addition problem for an example. Whew.
I understood everything he said and it made me dizzy. I knew that not
only did almost no one else in the room follow him at all, but that
almost everyone in the room had the impression that F21 was going
to be impossible to program. I worried that they had lost any
interest in the project after their first impression and never
open their minds again about it. I was worried that they would
spread their misconceptions and never see F21 again except as
a quirky toy that could not be programmed. I still hear stories
about this being told to people in Forth meetings around the
world.
Chuck said that he was aware that that happened and that he had
been thinking aloud and exploring his own thoughts outloud and
that he after we talked about it that day that he needed to make
an effort to stick to one perspecitive at a time in his presentations.
He still covers way too much ground in his yearly presentations to
FIG. How is going to cover OKAD enhancements, Color Forth developments,
new chip results, his ideas about internet products, and most importantly
his totally revolutionary break through discovery in transistors in
a short lecture?
He moves forward very fast and the folks at FIG never noticed Machine
Forth when was talking about that for ten years. They are still fifteen
years behind what his doing because he is so far away and moving so
fast. Still he takes the time out of his busy schedule to come and
cover the topics and put up with the insulting jokes afterwards.
I have even video taped him and sent out copies to people from my
store. I was telling Jet yesterday how much money I lose on each
tape and how many hours I put in on each one. I enjoy trying
to educate people even if only a few people in the world are
interested in the second half of the evolution of Forth so far.
He and I were talking last night about just how remarkable it was
that he discovered what he did about the effects of temperature on
transistors and how violated he felt to have been lied to about
this by the whole electronics industry for so long. If they don't
know they should not lie about it. It was also remarkable the
way the backtracked the quantum mechanics so cleverly to figure
it out and arrive at the remarkable simple conclusion that makes
everything work. We both thought it was so exciting.
I told him that I had goosebumps when he explained to the people
at FIG. I loved it when he said, "and no one else in the world
knows this, except now this room full of people." There was a
lot of joyous laughter. I hoped that meant that some people
had followed Chuck well enough to ask good follow up questions
to this incredibly exciting thing, like telling them e=mc^2.
I worried that like almost everything else he has said at FIG
in the last ten years was lost in the noise and that they were going
ask him about his keyboard ten years ago and his CAD font from
ten years ago again. At least I got it on video that time.
I got tired of people calling me a liar for saying that it
happened every time.
> >>I'm always eager to hear what Chuck has to say, as he always has a
> >>profound effect on my thinking.
He was talking last night about how depressed he was that so many
selfless people who understood his ideas and wanted to help other
people learn to think, and to wake up, had suffered so much. He
ran though this long list of all the people who had put in a
half million dollars of their money in efforts to support him,
help educate other people and be willing to risk it all on something
were monetary returns were very unlikely and about all you could
expect might be a sense of helping other people learn to think
or getting some recognition. He felt bad that so many different efforts
had met all of their goals except for anyone paying any attention,
learning, or ever selling any Forth chips.
He was feeling pretty bad about feeling like he had ruined the lives
of so many people who liked very much personally. He was agonizing
about the problems and what options where available to him.
Before I went over to see him yesterday I asked him what he had thought
of the essay that I wrote on Anti ANSI Forth. He said:
"I like your essays. That figures, since I agree with them. The last
months I've thought heavily about these issues, with no useful results."
> >>abstract machine is. I don't know where the 10x benefit is coming from.
When I first started working with Chuck ten years ago I could see where
he got the first 100x, but it took me a long time to understand how
he gets that last 10x. I couldn't do it for a very long time.
> >>I'd love to hear about this in a direct way, and not necessarily a
> >>confrontational way.
I am sorry if my tone sounds confrontational. We both worried a lot
ten years ago that since we were headed in one direction and that
everyone else in the Forth communtity seemed permanently headed in
the opposite direction that no one would ever pay any attention to
what we were doing because it was just too much in their face just
like Forth was originally too much in the face of conventional comp sci.
Jeff Fox Ultra Technology
www.UltraTechnology.com
-----------== Posted via Deja News, The Discussion Network ==----------
jf...@ricochet.net
r...@sc3d.org wrote:
> 3. There's something wrong with the section on the analog processor
> because several lines about interrupt handling are repeated there. I
> looked on Jeff's site, but the stuff there is even more garbled,
> especially the ref. given above.
It was funny last night. Chuck and I talked about the posted F21 specs.
Chuck said that when he writes the spec he likes it to be very short
and clear. He goes back and rewrites it to remove an extra word that
isn't needed to covey the meaning. When he is done he has about
five pages.
I take it and translate it into English. It is about fifty pages. I
go back and compare each sentance of Chuck's to each few paragraphs
that I have written. I often find that I missed several things
implied in what he says, by cross reference to something else if
you are thinking that I didn't explain in five paragraphs and go
back and add a little more.
When done I wonder if anyone can read either set of redundant
documentation and worry that almost no one could. Chuck said last
night that something as complex as F21, a complete and very clever
computer, needs at least a series of books to understand it. We
lamented that working 100 hour weeks for ten years that we couldn't
also do that.
lis...@zetnet.co.uk
On 1999-03-03 m...@iaehv.iaehv.nl(MarcelHendrix) said:
:"Jeff's article contrasts ANS Forth with what Jeff
:says Chuck calls Machine Forth, ..."
:Isn't it time somebody interviews Chuck again, like
^
You omitted "I can trust". HTH.
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
Anton Ertl
Bernd Paysan <bernd....@gmx.de> writes:
> Well, just add "macro" behind the offset words (or use bigFORTH's
> structure package). On my P200, FLINK2 gives 6,08 sec, whereas with
> "macro" behind LINK2 it gives 0,698 sec (which is somewhat faster than
> the empty loop, so don't trust you overcomplex CPU ;-).
I know why I insist that we do not upgrade the 486:-)
Ok, I have taken a few more timings with various native code compilers:
LINK2 FLINK2 SLINK2 ASLINK2
Gforth 0.4.0 138.51 50.17 11.02 53.37
bigForth 1.22 65.26 22.12 - 34.15
flk 1.3 56.30 28.13 - 37.24
iForth 1.08 66.31 18.07 - 24.15
bigF 1.22+macro 3.97 2.97 - 33.18
For a description of the benchmarks see <7br2iv$o3v$1...@news.tuwien.ac.at>.
The "bigF 1.22+macro" puts "macro" after every field word (including
slink2).
Conclusion: the native code compilers produce comparable code, and
they do not inline automatically. Inlining gives a dramatic speedup,
but in bigForth not for a does>-defined word.
Reuben Thomas
>In article <slrn7e3om...@persephone.joh.cam.ac.uk>,
> r...@sc3d.org wrote:
>
>> 3. There's something wrong with the section on the analog processor
>> because several lines about interrupt handling are repeated there. I
>> looked on Jeff's site, but the stuff there is even more garbled,
>> especially the ref. given above.
>
>It was funny last night. Chuck and I talked about the posted F21 specs.
>Chuck said that when he writes the spec he likes it to be very short
>and clear. He goes back and rewrites it to remove an extra word that
>isn't needed to covey the meaning. When he is done he has about
>five pages.
I'm much more fond of this approach than the "several paragraphs"
approach: it lets readers learn it rather than simply try to understand
what was written.
Some examples help, but that's all that need be added.
Jonah Thomas
>jf...@ricochet.net <jf...@ricochet.net> wrote:
>>It was funny last night. Chuck and I talked about the posted F21 specs.
>>Chuck said that when he writes the spec he likes it to be very short
>>and clear. He goes back and rewrites it to remove an extra word that
>>isn't needed to covey the meaning. When he is done he has about
>>five pages.
>I'm much more fond of this approach than the "several paragraphs"
>approach: it lets readers learn it rather than simply try to understand
>what was written.
>Some examples help, but that's all that need be added.
Particularly examples that show the tricky bits. It's *very* easy to look
at a few sentences and think you understand them, thinking that they mean
what they'd mean if it was a regular technical writer writing them.
It's the most natural thing in the world to assume that there are no
interactions except the ones you want.
jf...@ricochet.net
and discussions that took place at iTV between the two groups
that always saw these things from a different point of view. I
would like to post the iTV code line by line, show you the
compiled object code, trace it cycle by cycle etc. Unfortunately I am
not an employee of iTV, do not have access to their code, and should
not publish it anyway.
However the two best examples I could give you are the jpeg decode and
the structure package. Let me go though the logic and reconstruct
some of the comments that I made repeatedly about this when we were
wrestling with these issues.
To make the work go faster the ANSI programmers wanted to use standard
techniques and standard library code. The Machine Forth programmers
worried that stuff in these public libraries was not appropriate for
three reasons:
1. it was written to be portable. It had a lot of extra coded added
to support his. This was code that we felt wasn't needed to get our
single product out the door to keep the company in business.
2. it was written for portability and clarity not for size of performance
of the code. We did not argue that this is by definition is bad. For
most people who have big expensive computers all of the software is
equally inefficient so it really doesn't matter. Grabbing stuff that
works as efficiently as everything else there is what gets done. It
is good in some environments but we didn't see it as good for ours.
3. it was essentially based on the notions from 'C' but, with the 'C'
compiler is smart enough to use more early binding and make for smaller
faster code. The portable ANSI Forth copy of this code could not expect
this amount of smarts from the compiler and it is just shifting stuff from
compile time to runtime.
Now Chuck has said that you should shift what you can from runtime
to compile time and shift what you can from compile time to design time.
This is his approach, invest the thinking up front to do this sort of
thing. Extend the compiler to be smarter when you need to to prevent
doing more at runtime than you must. Do as much at design time and
compile time as you can to reduce the runtime load. Don't expect
the compiler to be smarter than you and do this for you. If you
are using Forth don't just count on the compiler to do all this.
example:
take this code as an example, it is structure code and at a low enough
level in the system that it deserves attention. We were told that it
was acknowledged that it came from a standard library and that it
might not be very appropriate in this form for our embedded product
with minimal resources. We have been able to make the whole product
an order of magnitude smaller than the nearest compeditor but we still
have a lot of code in there where we have a lot of FAT. Let's look at
this a little more closely.
This code was modified for our embedded use, but the effort to do so was
so minimal that it deserves our attention so that next time we can
do a better job. This line right here is a good example, all the
words on this page work like this.
The original portable ANSI Forth library code is carrying a lot more
FAT than we want. It can be reduced so easily that lets make an effort
do things like this in the future. Please listen:
The first problem I have is that all these words had some sort of
diagnositic or status display message facility in them that we don't
need for our embedded product. We do not need to carry this extra
code to support this diagnositic message. But look at how it was
removed, the word DIAGNOSTIC-MESSAGE (or whatever it was called) is
simply redefined at the top of the file as
: DIAGNOSTIC-MESSAGE ( d -- ) 2DROP ;
Ok, that is what was done to this code to trim the fat before putting
it in our product. Now I am not going to argue about the amount of
FAT introduced by redefining this word and adding the overhead of
DOCOLON and EXIT on to 2DROP rather than simply substituting 2DROP
for DIAGNOSTIC-MESSAGE on this page because it is negligable and
someone might argue that the code is clearer with this name.
My problem with this is that in my opinion someone who has had two
hours of Forth training can see that this is not the way to do that.
Look at these words! Look at the big picture. The word
DIAGNOSTIC-MESSAGE is the last work in each of these definitions.
Replacing it with a verion that does 2DROP does removed some unneeded
stuff but we can do better. Look at the defintion, there is a 2DUP
at the front of the word, a 2DROP at the end and half of the words
in this defintion are 2OVER 2SWAP etc to carry this double to the
end of the word and then drop it. That doesn't make much sense to
me. Why carry all this overhead all though this word just to do
a 2DROP at the end. Every word on this page is like this.
Take this one, lets follow the unneeded stuff backwards through the
word and instead of adding a 2DROP on to then of this word to clean
it up I would suggest that would better to do this. Cancel this
2DROP, cancel this 2OVER, cancel this 2SWAP, cancel this 2DROP
cancel this 2OVER, ... , ... , and we come back almost to the start of
the word so now lets cancel this original 2DUP. Oh the word does exaclty
the same thing but it but most of the words removed. It took three
seconds to throw out all that FAT. Why was more fat
added rather than simply do that?
If we put in a few more seconds work on these low level systems words
they can be sped up by 10x. Not bad for 10 seconds work. Why are we
not doing this?
Next, why stop there. We used to call them ANSI Forth and assembler
until Chuck insisted that we should call the assembler Machine Forth.
All the Machine Forth programmers insist that they can write it just
as fast as the ANSI Forth. I was going to convert this low level
system words to our Machine Forth but as soon as I looked at them
which apparently hadn't been done when it was pulled from the library
they were crying out for a 10x speedup and cleanup before being
rewritten in Machine Forth. After I took out the obvious FAT that
everyone should see I converted this to Machine Forth. Here is the
code, very simple, a couple of minutes, another 50x speedup on each
of these words and another 10x speedup overall on the package, and
in ten minutes work. That is 100x speedup on important code in ten
minutes. I hope people are listening so next time we will have
more people doing it this way.
Of couse what I really don't understand is why it should be done
like this anyway. Design time is better than compile time. Compile
time is better than runtime. 'C' does this at compile time, we
are doing it at runtime. That is where the real loss comes from.
We are imitating some of 'C' style but by doing so producing the
worst Forth code possible.
If we asked Chuck or any of the Machine Forth programmers in theto do
this, or how it should be done, they would think about it, figure out
how to get the compiler to do the right thing, extend it a little, and
then produce optimal Machine Forth code to do this. How many of
you think this should be done in 2-42ns with a # produced by an
extention to the compiler that does this at compile time? That is
what the 'C' compiler would do here. This is another example where
after taking ten seconds to speed the code up 100x we are still
living with code that is about 10,000x slower than what the Machine
Forth programmers would write. Why, because code was grabbed from
a library to minimize the amount of effort. This is going to take
some effort somewhere believe me. Let's think about what we are doing.
One group was always assuming that the units were nanoseconds or
sometimes microseconds and the other group was always assuming that
the units were milliseconds or seconds. We had two very different
cultures trying to coordinate work. Chuck would often get upset.
He was working with working with femtoseconds and picoseconds and
couldn't comprehend that so many programmers were not concerned
about so many orders of magnitude discrepancy between what they
could do and what they were doing. They were happy because they
were producing ANSI Forth code.
I would try to patch over the cultural differences so we could
merge everyone's code to get the product out the door. That was
the bottom line and I often would tell Chuck after the meeting
that the Machine Forth programmers code was so good that it was
going to make up for the FAT in the ANSI code well enough to
impress the investors. Technical goals and product specs were met
but as in most companies there is more to it than making a good
product or getting prototypes working and debugged.
This group is not interested in business problems or anything like
that. But those of us in those meetings listed to discussions like
this week after week for years. One side complaining about things
that were many many orders of magnitude slower and bigger than the
way they would have done it. The other side explaining their
problems and the advantages of doing things the way they were
doing it.
Everyone had different perspectives and it is not a case of one side
being right vs other being wrong in many cases but more of a case
of different jobs having different perspectives. Programmers specialize
in what they know, managers try to coordinate work and smooth out
personel problems, upper management decides how much risk can be taken
on new experimental things and part of that risk is related to how
conservatively the investors see things. Upper management must keep
the investors happy and not too worried that the staff is trying too
many new things to create too much risk. Middle management is trying
to coordinate different programming groups with upper management plans,
and the programmers are all trying to work with each other and coordinate
work yet we clearly had two very distinct groups.
I felt that I had more understanding of the constraints that some people
were facing than some people who's work was more technical focus. Chuck
had less patience with programmers who insisted that they were hired
to do ANSI and they were doing it well. I had little patience when
someone would shout at Chuck that he should not make software suggestions
in our staff meetings because he was just a hardware guy and knew nothing
about Forth, but I would try to smooth over it and move forward.
I think that people can follow the logic of what I was saying and imagine
the code pretty clearly in their mind. I don't feel that the concepts
were hard to grasp.
All the Machine Forth programmers really felt that they were on to
something good and wanted to help the other programmers use the stuff
they had discovered to be more productive too. The ANSI Forth
programmers were being productive at ANSI Forth and if they didn't
deliver on time we were all in trouble. I can understand some
reluctance on their part to gamble with changing horses in midstream.
They were busy with critical work and it had to get done.
However I repeat this same sequence of logical arguments for the
people in c.l.f so that they might be able to consider the differences
between these two very different approaches to Forth. I hope that
this explanation has clarified my position on this issue. I think
I speak pretty well for Chuck on this issue too. I realize that
some people in this newsgroup who don't trust me to report what Chuck
says about these things honestly.
Walter Rottenkolber
threaded 'C'. My CP/M Wordstar works a bit like the wordprocessor M.Simon
describes. Seriously, how does this differ from the compiled Forths out
there, except that it runs on a Forth chip? A better description of Machine
Forth from Jeff might provide more light than hot air.
I don't see how the Standard prevents you from writing code for a specific
chip, provided you document the dependencies. However, Jack Woehr in his
'The New Forth' (?) spent an entire chapter pointing out hidden dependencies
buried in code for which the standard may not provide a solution. Standard
Forth code may be more portable than what came before, but is it really 100%
portable to all systems? What say you?
Walter Rottenkolber
-----------------------------------------------
M.Simon wrote in message <36e22d20...@news.megsinet.net>...
>
>Machine FORTH. Designing the application for a specific machine rather
>than all possible machines. Keep the application simple. Throw out
>enough so that it fits in 16K of RAM and 20K of EPROM.
>
>We get bloated slow systems by trying to do too many what-ifs.
>
>Suppose word processors only did the few things that 80% want. And the
>output is some standard type file. Call another program to print the
>file. A simple window program could tie all the stuff together. And
>each piece is replaceable without having to know the internals of
>other pieces. Passed parameters on the stack because simple systems
>require few passed parameters. An old fashioned menu system with a
>pretty interface.
>
>Make the internals of your FORTH such that FORTH words can be replaced
>with machine OP codes. There should be no FORTH interpreter per se
>just a FORTH assembler. This is what Chuck means when he says he can
>do Machine FORTH on any machine.
>
>This is very different than the interpreted or virtual machine style
>of programming. Nothing is interpreted, nothing is virtual. Its just
>assemble and run.
>
>Am I getting it Jeff?
>
>Simon
Elizabeth D. Rather
>
>...
>
> To make the work go faster the ANSI programmers wanted to use standard
> techniques and standard library code. The Machine Forth programmers
> worried that stuff in these public libraries was not appropriate for
> three reasons:
>
> 1. it was written to be portable. It had a lot of extra coded added
> to support his. This was code that we felt wasn't needed to get our
> single product out the door to keep the company in business.
>
> 2. it was written for portability and clarity not for size of performance
> of the code. We did not argue that this is by definition is bad. For
> most people who have big expensive computers all of the software is
> equally inefficient so it really doesn't matter. Grabbing stuff that
> works as efficiently as everything else there is what gets done. It
> is good in some environments but we didn't see it as good for ours.
>
> 3. it was essentially based on the notions from 'C' but, with the 'C'
> compiler is smart enough to use more early binding and make for smaller
> faster code. The portable ANSI Forth copy of this code could not expect
> this amount of smarts from the compiler and it is just shifting stuff from
> compile time to runtime.
It's bothering me no end that you're equating "ANSI Forth" with "C
translated literally into bad Forth." I know many too many fine programmers
who write very efficient ANS Forth, well-factored, with good code density.
You obviously have a culture gap here, that can be addressed by getting
folks to agree on objectives and then providing some training as to achieving
those objectives (e.g., tight, fast Forth code). Instead, you're describing
a cultural divide which you're attempting to resolve by shouting, which
rarely works.
Some clear, written guidelines as to when it's acceptable/desirable to
depart from ANS Forth would also be helpful.
Cheers,
Elizabeth
--
===============================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-372-8493
111 N. Sepulveda Blvd. Fax: +1 310-318-7130
Manhattan Beach, CA 90266
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
===============================================
lis...@zetnet.co.uk
On 1999-03-05 mi...@spindle.net said:
:I second this heartily!
:I'd really like to see an implementation of Machine Forth (MForth?)!
Not quite, but I'm working on something close. The code will almost
certainly live inside 1k. The dictionary may have to wait outside. And
it optimises by keeping TOS in a register occasionally (which is nicer
than a permanent cache) and using constants.
The advantage of A is that the store operation only changes the stack
depth by one cell. That's not to be underestimated. :>
jf...@ricochet.net
"Elizabeth D. Rather" <era...@forth.com> wrote:
I used to agree with Elizabeth about this and argued with Chuck for
years before we both worked at iTV and sat through the same staff
meetings for years.
> It's bothering me no end that you're equating "ANSI Forth" with "C
> translated literally into bad Forth." I know many too many fine programmers
> who write very efficient ANS Forth, well-factored, with good code density.
I am sure. As I said before I would be very suprised if Forth Inc. had
these kind of problems because they are experts on Classic Forth and
teach people how to do it properly.
I would listen to arguments like, "it is no accident that this code
is factored exaclty like the original 'C', it is no accident that it
has exaclty the same names for every function, that was the idea.
That is what is in the library.
I began to realize that ANSI Forth makes it possible to that although
I had never thought of it. I realized that we had not only made this
possible but posted examples on the internet and invited many more
people than we had to come in and join us to do this. It sounds like
a good idea to 'C' programmers, and there are a lot more of them
out there than people who have been trained by Forth Inc.
> You obviously have a culture gap here, that can be addressed by getting
> folks to agree on objectives and then providing some training as to achieving
> those objectives (e.g., tight, fast Forth code). Instead, you're describing
> a cultural divide which you're attempting to resolve by shouting, which
> rarely works.
I never shouted in those meetings. It did bother me to see people shout
at Chuck for thinking that he knew something about Forth. I saw many
patterns develop over the years, not just at iTV but at FIG and in
the Forth community at large. Chuck and I often talked about this
trend. I have recently done some shouting about it and so far I have
had about 50 pieces of mail all saying, I am so glad someone finally said it.
Forth Inc. doesn't give away their excellent software or their excellent
training in how to write and think Forth. People learn by example and
when the examples we are using for promotion cannot be distinguished
from 'C' code to a lot of people we are asking for trouble.
Unlike Chuck I don't hate 'C'. I learned it after Forth and used it
for years on various consulting projects. I just think that there is
room for Forth and 'C' and hate to see everyone in the Forth community
focused only on ANSI Forth and many headed toward embracing 'C' code,
'C' style, and 'C' libraries to turn Forth into just another 'C' library.
John Drake
Jonah Thomas wrote:
> jf...@ricochet.net wrote:
>
> >On another subject the ANSI stance that I have recently published.
> >So far about ten people have said, right on, I didn't know that
> >I wasn't the only one who felt that way. Thanks.
>
> >Not a single person has sent me mail saying "I don't agree at all."
> >That is not hate mail and I would not respond to it that way.
> >I am willing to be convinced that I am wrong, but I am also
> >very stuborn.
>
> I don't completely agree. First off, though, you're describing
> your own experience, and I have no intention of telling you that
> what you've seen didn't happen. Clearly it's possible to misuse
> ANS Forth. It has some possible values. For example, if the iTV
> Forth OS was written so that the higher-level functions were mostly
> ANS then iTV might be able to port it to other processors fairly
> easily. I've heard nothing to indicate whether they'd care about
> that. Similarly, inefficient ANS routines could get ported to
> other systems easily and optimised at will. Often it's easier to
> optimise when you have a working model than when you don't have
> anything that works on the system in question.
You have a valid point here. From what I can tell the wordsize of
the F21 is quite unique. Most processors use wordsizes that are
powers of 2. (8, 16, 32, 64 ect.) The F21 wordsize is and its cell
size is ???? Well??? I guess 5 (since 4 instructions of 5 bits can
be packed into one word.) Trying to write software for such an
architecture while being oblivious to its peculiarities is probably
a fools errand. Assumptions that you could make about an ANSI
Forth running on top of a "power of 2" architecture simply would
not hold in the F21 case. Porting software across architectures
with different wordsizes is bad enough.
I suppose what I'm saying is, to see a fair comparison on ANSI
Forth versus a "minimal 27 instruction Forth" the target processor
for both should be a neutral one. Like maybe comparing ANSI
Forth performance against a 27 instruction Forth for an 8051?
If having a stack-based architeture is the prime goal than what
about a comparison of a 27 instruction Forth for the Shaboom
chip versus ANSI Forth? I really think wordsize is a problem
with Jeff's comparison, though I could be wrong.
Elizabeth D. Rather
>
> In article <36E437FC...@forth.com>,
> "Elizabeth D. Rather" <era...@forth.com> wrote:
>
> I used to agree with Elizabeth about this and argued with Chuck for
> years before we both worked at iTV and sat through the same staff
> meetings for years.
>
> > It's bothering me no end that you're equating "ANSI Forth" with "C
> > translated literally into bad Forth." I know many too many fine programmers
> > who write very efficient ANS Forth, well-factored, with good code density.
>
> I am sure. As I said before I would be very suprised if Forth Inc. had
> these kind of problems because they are experts on Classic Forth and
> teach people how to do it properly.
You can, too. It's a matter of exercising leadership and establishing
corporate standards, and having management stand behind them. If you
fail to do this, the failure is in your management, not ANS Forth.
> Forth Inc. doesn't give away their excellent software or their excellent
> training in how to write and think Forth. People learn by example and
> when the examples we are using for promotion cannot be distinguished
> from 'C' code to a lot of people we are asking for trouble.
No, but we sell them at prices many companies find quite cost-effective,
because it saves problems such as you describe!
> Unlike Chuck I don't hate 'C'. I learned it after Forth and used it
> for years on various consulting projects. I just think that there is
> room for Forth and 'C' and hate to see everyone in the Forth community
> focused only on ANSI Forth and many headed toward embracing 'C' code,
> 'C' style, and 'C' libraries to turn Forth into just another 'C' library.
I don't hate C either, but it's a very different "building material" than
Forth, and programmers (like all craftsmen) need to respect their tools.
An architect wouldn't design a building the same using bricks as using
reinforced concrete. People must appreciate this in order to get good
results.
M.Simon
operation finally brought home the advantage of A. Thank you.
I had always hated the time to load A without thinking of the other
ramifications.
Thanks again.
Simon
=============================================
William Tanksley
>I am designing hardware for a FORTH chip. Your comment about 1 stack
>operation finally brought home the advantage of A. Thank you.
I've done this, and realized the need for A by experience. It's cool, too,
because in my design it allowed prefetches. Load A, do some other stuff,
then read from memory (the memory read would be done in one cycle, because
it was actually only a register move).
I was simulating this chip in software, so I didn't need to worry about
gatecount; one of the things I had to do was sort 16 cells. No problem; I
wired the top 16 stack elements (I had 32 stack elements, all on-chip) with
a perfect shuffle network, and used a one-cycle instruction to run a single
permutation of the shuffle. Four shuffles, and all sixteen elements are
sorted.
Thanks to this and other things, I had the fastest chip in the class :).
Had a pretty good part count, too, thanks to MISC.
It was fun.
>Simon
--
-William "Billy" Tanksley
"But you shall not escape my iambics."
-- Gaius Valerius Catullus
M.Simon
Make FORTH part of the machine vs. run on the machine.
Easy on a 68000, a little more difficult on an x86. Trivial with the
F21.
No compiled code. Only assembled code. FORTH assembler. Interactive.
With a fast assembler(small number of opcodes) assembly is as fast as
compiling and after assembly it runs very fast.
You might have to bootstrap the first system or two with F-PC. Or your
favorite assembler.
Simon
==================================================
M.Simon
machine.
No more IP. Just the processor's PC.
Simon
M.Simon
right mindset.
Assume the chip you have on hand is a FORTH chip ( x86, 68xxx, Z80,
whatever). Assume the program counter of the chip is its IP. Write a
FORTH assembler to embody these ideas. Keep the instruction set small
to make the assembler small. Add instructions that will take advantage
of your processor to solve your particular problem. But keep the
kernel small.
Simon
=====================================================
M.Simon
<wal...@sierratel.com> wrote:
>This kinda looks like what you could get with a twin stack, subroutine
>threaded 'C'.
Primitives are inlined not called.
Mary Murphy and Leo Wong
>
>I have recently done some shouting about it and so far I have
>had about 50 pieces of mail all saying, I am so glad someone finally said it.
>
I hope they're sending you money.
I hope they will post actual "ANSI Forth" code and their improvements
(why not, if Kernighan and Plauger could quote and correct in a famous
book? why, if I could quote from and improve on Brodie in a series of
articles that later found a place in the Forth Programmer's
Handbook?).
I hope that some of the "ANSI Forth" and "Machine Forth" programmers
who worked at iTV will tell us their experiences and opinions.
I hope that we will have less heat and more light concerning Machine
Forth. Jeff, you have our attention. Stop complaining and stop
claiming; start explaining, and most of all, start showing.
Leo Wong
he...@albany.net
http://www.albany.net/~hello/
Bruce R. McFarling
> I began to realize that ANSI Forth makes it possible to that although
But could you please refer to ANS Forth itself as American
National Standard Forth, and leave the Institute out of it (very few ANS
Forths originate at ANSI), except for the obviously punny reference to
people trying to write ANSI C in ANS Forth.
Virtually,
Bruce R. McFarling, Newcastle, NSW
ec...@cc.newcastle.edu.au
Neal Bridges
> > 3. it was essentially based on the notions from 'C' but, with the 'C'
> > compiler is smart enough to use more early binding and make for smaller
> > faster code. The portable ANSI Forth copy of this code could not expect
> > this amount of smarts from the compiler and it is just shifting stuff from
> > compile time to runtime.
>
> translated literally into bad Forth." I know many too many fine programmers
> who write very efficient ANS Forth, well-factored, with good code density.
Is *that* what you means, Jeff? Good grief. Anyone reading your messages to
date (including me) would swear blind that you hate the ANS Forth Standard
itself, and blame it for the development failures in your shop. I've been
scratching my head wondering how you came to that conclusion, and here it
seems you didn't mean that at all.
Jeff, please be so kind as to write clearly; type slowly and use extra words
if you need to. I daresay to most who are reading your postings, the phrase
"ANSI Forth programmer" means "programmer writing code for an ANS Standard
Forth system". Since in fact it now appears you mean "programmer with an
ANSI C background who inappropriately transliterates C code into Forth" -- a
horse of an appreciably different colour -- say so! Deliberately confusing
the meaning of what you say won't help get your ideas across.
Neal Bridges
<http://www.interlog.com/~nbridges/> Home of the Quartus Forth compiler!
John Passaniti
jf...@ricochet.net wrote in message <7bui0m$bdd$1...@nnrp1.dejanews.com>...
>It was funny last night. Chuck and I talked about the posted
>F21 specs. Chuck said that when he writes the spec he likes
>it to be very short and clear. He goes back and rewrites it to
>remove an extra word that isn't needed to covey the meaning.
>When he is done he has about five pages.
>
>go back and compare each sentance of Chuck's to each few
>paragraphs that I have written. I often find that I missed several
>things implied in what he says, by cross reference to something
>else if you are thinking that I didn't explain in five paragraphs
>and go back and add a little more.
I'm not sure why this should be surprising. Chuck is no different from
every person in this conference who has ever written a complex system. His
specification documentation can be complete, but extremely concise and
terse. That's because when anyone writes a specification, they necessarily
leave out the implied details that they assume the reader already knows. If
I was (for example) to document my toy Forth system, I wouldn't spend
paragraphs on the token threading method that I use. That's because I would
expect that anyone who would read my document would already be familiar with
it (or could easily infer how it works), and that they understood the
ramifications of such a threading model.
Of course, the moment you try to translate such a document to a more general
audience, you necessarily have to add detail, bulk, and cross-references.
That's because instead of writing for a specific audience who knows the
assumptions and details, you are now writing for a more ambigious audience.
That five pages turned into fifty doesn't sound at all unusual. I recently
had to go back and take a specification I wrote that was seven pages long,
and it came out around 67 pages when I "translated" it for a more general
audience. A drawing in my specification itself resulted in three pages of
explanation.
I find both kinds of documentation are necessary. For example, on a new
processor, I usually go for the bloated "user manuals" first that take the
time to lay out all the details and "bootstrap" the reader into the way the
processor works. Then, once I am comfortable with that, I usually go for
the much shorter specifications that concisely detail how things work.
>When done I wonder if anyone can read either set of
>redundant documentation and worry that almost no one could.
>Chuck said last night that something as complex as F21, a
>complete and very clever computer, needs at least a series of
>books to understand it.
Not at all surprising. There is a big difference between describing a
processor and describing how best to use it. The F21 isn't the first
processor that requires such documentation. My shelves are filled with
manufacturer's data books that concisely detail processors, and then the
other books from other people that show how to effectively use the chips.
Again, both kinds of documentation are necessary.
>We lamented that working 100 hour
>weeks for ten years that we couldn't also do that.
I guess that's part of the danger of keeping a design so close to yourself.
We've talked before about the need to keep a roof over your head, and I
don't have a problem with that. I just wish more in the hardware end would
see that the "Open Source" model applies to hardware as well as software.
One wonders where the F21 could be now if instead of dribbling bits of
information about it here and there, you made it an open project (ala Linux,
Perl, Apache, Zope, etc.) that anyone who was serious about contributing
could. You could have your documentation done, chips in the hands of people
who wanted them, and perhaps most importantly from my perspective, public
discourse on the technology so that others knew if it was right for their
needs. You would benefit from massive parallel debugging, tapping a larger
pool of minds and experience, and more user experience.
That is after all what helped to bring thousands to Forth in the first
place.
Then, instead of people like myself trying their best to piece together the
various bits of information you leak out into something meaningful, we all
would have the same access to information, and we could then have more
meaningful discussions.
As it stands now, you automatically "win" in any and all discussions about
the F21. That's because when someone gets a detail wrong, you can shake
your head, cite a conspiracy, toss in a fruit salad, and claim the other
person is an idiot for not getting it right. Then you can gleefully release
the missing details that weren't know before (or which were presented
ambiguously) and pretend that everyone already knew it. But I digress...
The only problem I see with a more "Open Source" mentality with the F21 (and
other hardware) is that I doubt many Forth folk will believe it can work.
To put it nicely, most Forth folk are "individualistic." To put it another
way, they are largely anti-collaborative. They can't make the mental jump
that the Linux (et. al.) folk did-- that you don't have to make your money
in the actual product, but in the support, extension, and publicity of that
product. For perhaps the best statement from a small consulting company on
the paradigm shift and mental gymnastics needed to make the transition to
Open Source, I highly recommend reading about Digital Creation's Zope (visit
http://www.zope.org/Information/BusinessDecision for a good read).
Bart Lateur
>It's bothering me no end that you're equating "ANSI Forth" with "C
>translated literally into bad Forth." I know many too many fine programmers
>who write very efficient ANS Forth, well-factored, with good code density.
Urm... not "C" code. "Abstract FORTH" code. I can imagine, and I think
this is what Jeff Fox is actually referring to, is that there are a lot
of programmers who do (ANSI) FORTH programming, without any feel at all
for what is actually done by the CPU. Who don't think twice about the
speed difference between DUP and 10000 BL FILL . The first is one word,
the second is three. That's a speed comparison of 1 to 3, isn't it?
Of course, *I* know it's not so. But, does everybody?
Bart.
Bernd Paysan
jf...@ricochet.net wrote:
[...]
I think you face two problems: first, your compiler technology sucks. There
is a huge discrepancy between high-level Forth and low-level "machine Forth",
and this discrepancy is by factors larger than on conventional systems (e.g.
Gforth is about 6 times slower than assembly on average, bigFORTH about two
times for integer and almost as fast as assembly on FP, given that you use
inlining when appropriate). Since your machine language is very similar to
Forth, there isn't much productivity loss when you use machine language. As
you observed, there is indeed some productivity *gain*, since the machine
language actually is simpler than Forth (because it has less words to learn).
The second problem are your "ANS Forth programmers". Their standard just is
too low (for whatever reason), and they blame the TC, while it's their fault.
But after all, this has almost nothing to do with ANS Forth. In contrast to
previous Forth standards, ANS Forth permits high efficient compilers such as
bigFORTH or RAFTS (the latter does even automatic inlining, constant folding,
register allocation and other things dump programmers hand over to the
compiler). It's also Chuck's "fault" that his F21 doesn't make an easy target
for a Forth compiler. He decided to leave traditional Forth, and broke the
bridge behind him (limited stack size, making DUP and SWAP inefficient,
etc.). For him, the decisions seemed logical and appropriate. But four iTV's
situation, it meant to invest more into compiler technology to overcome the
limitations. Or, well, write a lot of code in machine Forth by hand, which
turned out to be not very difficult.
The point is: ANS Forth is not inefficient, iTV's Forth compiler is. ANS
Forth doesn't necessarily lead to bad, slow code, but iTV's "ANS Forth
programmer" write bad, slow code - whereas the "machine Forth" programmers
write good, efficient code. I suppose they did a sort of programmer's Peter
principle: let the worse programmers write the higher level code, where it
hurts more that they write so inefficient (because in the higher level part
you have many more orders of magnitude to waste). My two word summary is
"false generalization".
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/
Reuben Thomas
>
>jf...@ricochet.net wrote in message <7bui0m$bdd$1...@nnrp1.dejanews.com>...
>>It was funny last night. Chuck and I talked about the posted
>>F21 specs. Chuck said that when he writes the spec he likes
>>it to be very short and clear. He goes back and rewrites it to
>>remove an extra word that isn't needed to covey the meaning.
>>When he is done he has about five pages.
>>
>>I take it and translate it into English. It is about fifty pages. I
>>go back and compare each sentance of Chuck's to each few
>>paragraphs that I have written. I often find that I missed several
>>things implied in what he says, by cross reference to something
>>else if you are thinking that I didn't explain in five paragraphs
>>and go back and add a little more.
>
>I'm not sure why this should be surprising. Chuck is no different from
>every person in this conference who has ever written a complex system. His
>specification documentation can be complete, but extremely concise and
>terse. That's because when anyone writes a specification, they necessarily
>leave out the implied details that they assume the reader already knows. If
>I was (for example) to document my toy Forth system, I wouldn't spend
>paragraphs on the token threading method that I use. That's because I would
>expect that anyone who would read my document would already be familiar with
>it (or could easily infer how it works), and that they understood the
>ramifications of such a threading model.
I firmly believe that specs can be short. The trick is telling the
difference between ambiguity (essentially, "what are your undefined
terms") and explanation ("what do my readers need to learn before they can
understand this document?"). While these are not cut-and-dried categories,
it's generally possible to make the first category very small (tie it down
to a few formal definitions and leave assumptions like knowing how to
count, linear memory addressing &c.) and then use pointers to other
documents to cover the second category. The virtual machine I'm working on
at the moment has a three-layer definition:
1. A semi-formal definition (basically it's mathematical, but it's not
watertight, hence the "semi-")
2. A concrete syntax (this also changes and extends some of the semantics
of the formal definition, but basically just converts it into a concrete
assembler code)
3. An encoding (specifies what the assembler should produce)
Each document is 5-8 pages long. I've written a tutorial too, which is
currently incomplete, but about 5 pages long, relying on the fact that the
assembler code looks very like generic RISC assembler, so I don't need to
put too much effort into explaining three-operand instructions like "ADD
a,b,c".
If anyone's interested, they can find the documents on my web page under
"Research". The VM itself, Mite, was presented at EuroForth '98 and is an
attempt to attack the same problem as Java (binary-compatible code) but
without all the libraries and security and concentrating on efficiency
aspects.
he...@albany.net
bart....@skynet.be (Bart Lateur) wrote:
> Elizabeth D. Rather wrote:
>
> >It's bothering me no end that you're equating "ANSI Forth" with "C
> >translated literally into bad Forth." I know many too many fine programmers
> >who write very efficient ANS Forth, well-factored, with good code density.
>
> Urm... not "C" code. "Abstract FORTH" code. I can imagine, and I think
> this is what Jeff Fox is actually referring to, is that there are a lot
> of programmers who do (ANSI) FORTH programming, without any feel at all
> for what is actually done by the CPU.
But we won't really know, do we, until we see actual code? Jeff
has not always explained well. Fortunately, he now has an audience
that will respond to him. Our misunderstandings should help him
make his explanations clearer. Certainly his audience deserves as
much patience and attention as a piece of software or a chip that
he is debugging.
> Who don't think twice about the
> speed difference between DUP and 10000 BL FILL . The first is one word,
> the second is three. That's a speed comparison of 1 to 3, isn't it?
>
> Of course, *I* know it's not so. But, does everybody?
>
And your point is we don't need 10000 BL FILL because we have DUP ?
I hope that people will be interested enough to implement and
test Machine Forth. It probably has a place in the Forth arsenal.
I'd like to know: what place?
We've been saying "27 instructions", but that doesn't include
i/o, display, and other instructions needed for many applications.
How many instructions would be needed to, say, write Leo Brodie's
Starting Forth programs in Machine Forth?
Show me the code.
-----------== Posted via Deja News, The Discussion Network ==----------
he...@albany.net
"John Passaniti" <jp...@rochester.rr.com> wrote:
>
> jf...@ricochet.net wrote in message <7bui0m$bdd$1...@nnrp1.dejanews.com>...
> >We lamented that working 100 hour
> >weeks for ten years that we couldn't also do that.
>
> I guess that's part of the danger of keeping a design so close to yourself.
> We've talked before about the need to keep a roof over your head, and I
> don't have a problem with that. I just wish more in the hardware end would
> see that the "Open Source" model applies to hardware as well as software.
> One wonders where the F21 could be now if instead of dribbling bits of
> information about it here and there, you made it an open project (ala Linux,
> Perl, Apache, Zope, etc.) that anyone who was serious about contributing
> could. You could have your documentation done, chips in the hands of people
> who wanted them, and perhaps most importantly from my perspective, public
> discourse on the technology so that others knew if it was right for their
> needs. You would benefit from massive parallel debugging, tapping a larger
> pool of minds and experience, and more user experience.
>
> That is after all what helped to bring thousands to Forth in the first
> place.
>
> Then, instead of people like myself trying their best to piece together the
> various bits of information you leak out into something meaningful, we all
> would have the same access to information, and we could then have more
> meaningful discussions.
>
From the very beginning Chuck has played it close to the vest. Here
it is in plain Tinglish (eForth and Zen):
> Very early in the development of Forth, a state of closure was
> reached. Chuck was able to generate new Forth systems from an
> existing Forth system through meta-compilation. He did not
> need other programming tools to build new Forth systems, and
> Forth started to evolve independent of the existing operating
> systems and programming languages. This state of closure was
> very interesting, like the ying-yang cycle. One could not find
> an entry point once the cycle was closed. In that Chuck had
> the monopoly on Forth, because very few people possessed the
> understanding to cut in the cycle in order to build new Forth
> systems. He felt quite secure in giving useers the complete
> source listings, fairly sure of that nobody could reversed
> engineered the Forth technology, even though the source
> listings were complete and truthful.
Dr. Ting writes that the cycle was broken by figForth.
Coming down from the mountain once or twice a year to give
a talk is not what I would call a change to openness.
I guess I could understand this if iTV could sell its
"killer-app" product and pay its programmers, if Chuck was
a billionaire and could pay to fix his roof, and if Jeff
could sell his chip and eat a good meal.
Maybe I'm wrong and iTV, Chuck, and Jeff will strike it
rich. What's clear from Jeff's own reports is that
"Forth community" is yet another oxymoron.
Jerry Gitomer
John Passaniti wrote:
> <Great big snip here>
> The only problem I see with a more "Open Source" mentality with the F21 (and
> other hardware) is that I doubt many Forth folk will believe it can work.
> To put it nicely, most Forth folk are "individualistic." To put it another
> way, they are largely anti-collaborative. They can't make the mental jump
> that the Linux (et. al.) folk did-- that you don't have to make your money
> in the actual product, but in the support, extension, and publicity of that
> product. For perhaps the best statement from a small consulting company on
> the paradigm shift and mental gymnastics needed to make the transition to
> Open Source, I highly recommend reading about Digital Creation's Zope (visit
> http://www.zope.org/Information/BusinessDecision for a good read).
I think much of the difference in attitude between the Linux folks and the Forth
folks is that the Linux folk -- forced to work in "C" -- are not accustomed to
producing significant pieces of software unassisted. The Forth folk, on the
other hand, don't think twice about implementing a virtual machine, operating
system, high level language, and a full complement of utilities unaided by
others.
Based on many of the comments I have read in this newsgroup I think that things
*could* change :-) but I suspect they won't :-(
regards
Jerry Gitomer
--
Jerry Gitomer
Computers were made for selling, not for using.
They don't give you any grief until you try to use them.
Michael and Anne Losh
M.Simon wrote in message <36e47b6b...@news.megsinet.net>...
>You don't need the right kind of chip to do machine FORTH. Just the
>right mindset.
>
>Assume the chip you have on hand is a FORTH chip ( x86, 68xxx, Z80,
>whatever). Assume the program counter of the chip is its IP. Write a
>FORTH assembler to embody these ideas. Keep the instruction set small
>to make the assembler small. Add instructions that will take advantage
>of your processor to solve your particular problem. But keep the
>kernel small.
>
>Simon
Yes, when I ported eForth to an Internet Java applet, I redesigned it to run
as a token/subroutine threaded Forth. The eForth kernal words were short
Java instruction sequences in a large CASE structure. The compiler inlines
the token for primitives and inlines a subroutine "call" to high-level
words. The "machine forth" Java routine calls the case structure for the
primitives and handles nesting and unnesting for subroutines. The
difference between primitive token numbers and subroutine addresses is
highlighted by a specific bit in the address/token "value". I did not
implement some of the unconventional instructions from Chuck and Jeff's
chips or Chuck's software MACHINE FORTH like -IF, but it could be done
fairly easily. Perhaps I will do this at some point.
If any other readers want to look at the Java source code for this system,
it is easily downloaded from the eForth for Java web page:
http://www.amsystech.com/mlosh. This applet is not very impressive in terms
of performance, due to the many levels of interpretation it contains, but
several of the Machine Forth ideas are there.
So, you can see that I understant the basic approach, and have used it to a
degree is a demo system. But it may be quite an adjustment to use the
approach on a down-to-the-metal implementation of a complex system.
Say I wanted to automate the "workflow" of electronic documents (paper form
replacements) among physically separated offices. I would have to build up
in MACHINE FORTH routines for FTP (or a similar protocol), document
presentation, data entry, and file and net I/O. I think _I_ could do this,
given enough time. Perhaps an expert who already has a lot of practice
could do it much more quickly. But can anyone do it in a timeframe and
budget that businesses can afford -- for example, in two or three
person-weeks?
I sense that businesses are very hesitant to spend more for a great system
when the "good enough" one works most of the time, is adequately fast, and
is available quickly. I agree that programming for portability is often a
misguided effort, and that it is often better in terms of performance, size,
and reliability to focus on and optimize for the actual target platform.
But the approach "I won't use any libraries for this project -- they are
slow, buggy, and limiting" is a tough sell to clients/bosses who have been
hearing for ten or more years "buy off the self... don't reinvent the
wheel." Jeff came up with a good response to this attitude in one of his
web essays... "for many jobs you want to invent the new wheels that you need
and Forth is good for that" (LOW FAT COMPUTING,
http://www.dnai.com/~jfox/lowfat.htm).
I'll keep looking for good candidate project where something like MACHINE
FORTH can be used effectively and safely for me or my company. I really
want to see how it works for myself.
--
Michael Losh
M.Simon
>Yes, when I ported eForth to an Internet Java applet, I redesigned it to run
>as a token/subroutine threaded Forth. The eForth kernal words were short
>Java instruction sequences in a large CASE structure. The compiler inlines
>the token for primitives and inlines a subroutine "call" to high-level
>words. The "machine forth" Java routine calls the case structure for the
>primitives and handles nesting and unnesting for subroutines. The
>difference between primitive token numbers and subroutine addresses is
>highlighted by a specific bit in the address/token "value". I did not
>implement some of the unconventional instructions from Chuck and Jeff's
>chips or Chuck's software MACHINE FORTH like -IF, but it could be done
>fairly easily. Perhaps I will do this at some point.
I just figured out the value of the A register a couple of days ago.
Someone in this group pointed me in the right direction. Wow. All
stack instructions are single cycle. And no access to NOS is needed in
the machine. And auto increment becomes a feature. And you eliminate a
lot of stack thrashing for block moves. Say maybe we need a B
register?
A@+ B!+
Could you explain how -IF works. I'm ready for another revalation.
Reuben Thomas
>I just figured out the value of the A register a couple of days ago.
>Someone in this group pointed me in the right direction. Wow. All
>stack instructions are single cycle. And no access to NOS is needed in
>the machine. And auto increment becomes a feature. And you eliminate a
>lot of stack thrashing for block moves. Say maybe we need a B
>register?
>A@+ B!+
Gosh, you'll be inventing the register machine next! Seriously though,
this reminds me of my experience with the real ARM machine, whose
instruction set was designed by an expert programmer (Sophie Wilson)
from a software point of view. It's by far the smallest instruction set of
any of the so-called RISC processors, and yet it's also one of the most
concise. It's altogether a joy to work with. The only problem with it from
the point of view of the current discussion is that register machines are
more complex to implement virtually either as interpreters (when they're
slow) or as translators (when you get stuck on the exact number of
registers). Also, some of the ARM's features, such as conditional
execution of *any* instruction and multiple push/pop using *any* register
as the stack pointer/fifo pointer, are tricky to emulate efficiently on a
real machine.
Also, Martin Richards's Cintcode VM for BCPL uses two registers which
themselves operate as a stack (though he doesn't have a data stack
underneath it). I suspect that 2 or 3 registers is the most you can have
in a VM before you need to start dealing with register numbers in the VM
translator/interpreter and add an extra layer of complexity.
M.Simon
Source - Destination - Data is a common form.
I agree about too many registers. But address registers can be
special purpose.
I will look into how these ideas change the architecture I am working
on.
Simon
================================================
On 10 Mar 1999 10:04:40 GMT, r...@persephone.joh.cam.ac.uk (Reuben
Thomas) wrote:
Jonah Thomas
>Could you explain how -IF works. I'm ready for another revalation.
It's for carry.
Lots of processors have a carry flag in a status register. If you
use it you have problems. You can't transparently call code that
might change the carry flag unless you save it and restore it, which
adds overhead whether you use it or not. There may be assembly
commands you'd like to use in your inner interpreter etc that change
the carry flag. The traditional answer was not to allow any direct
access to the carry flag, and only use it during double operations.
A limitation.
What Chuck did was to allow an extra bit in the onchip data stack,
for the carry. You can call as many commands as you like between
an addition and checking carry for that addition, provided they leave
that stack item alone. Carry has become re-entrant.
-IF branches depending on the carry bit in TOS. Nice and simple.
IF branches depending on whether TOS is zero.
There's no 0< but if you want to branch if TOS<0 you can do 2* -IF .
None of these consume the flag from the stack. It's another tradeoff.
One way you sometimes have to do DUP IF and the other way you sometimes
have to do IF DROP ... ELSE DROP ... THEN .
I've spent a few hours playing around with it, and when I tried to write
very tight fast code sometimes it helped to have garbage lying on the
stack left over from IF . The reason is that on F21 a literal takes one
slot to create the operation and then it takes the next whole cell for
the number -- a total of 5 slots and probably a whole cycle. But if the
number is 0 you can do DUP DUP XOR to do it in 3 cycles, and for -1 you can
do DUP DUP XOR INVERT to do it in 4 cycles. If you have an undropped piece
of garbage on the stack already you can do those in 2 cycles or 3 cycles
instead.
I have no idea how hard it is to read code that does that sort of trick.
I'll go back and look at my code next week. If I can still read it then
that will be a little bit promising.
0< looks hard to me, it would go something like
: 0< ( n -- 0|-1 )
2*
-IF
DUP XOR INVERT
ELSE
DUP XOR THEN ;
A slot for 2*, a cell for -IF, a cell for DUP XOR INVERT, a cell for ELSE,
2 slots for DUP XOR . Big. And kind of slow. But I haven't picked up
the tricks to it yet, maybe there's a much better way.
Say Chuck wanted to emulate F21 on another processor. He might as well
turn a pentium into a 31-bit system, with room for carry bits. He could
use tests for negative numbers to test the carry bit, and use the same
workarounds he uses on his own chips to workaround bit 30 as the sign bit.
It seems like he'd get some overhead by ignoring the sophisticated
instructions, but at least the simple instructions he uses should mostly
be very quick ones, and they'll be quick on any processor he uses. So
his code should be reasonably fast, and completely portable among
processors.
I can see why Chuck would want to minimise branches. An IF takes an
entire clock cycle, as long as 4 instructions. And ELSE takes another
entire clock cycle. But with the minimal instruction set it looks to me
like it would be hard to do a lot without branches. Literals are also
big and slow, and there just isn't a lot to work with --
AND XOR 2* 2/ INVERT +
(and +* which I don't get yet -- it does the add only if the TOS is odd)
It's, well, minimal.
Bruce R. McFarling
> (and +* which I don't get yet -- it does the add only if the TOS is odd)
I'm pretty sure that's a multiplication primitive
Jonah Thomas
>On Wed, 10 Mar 1999, Jonah Thomas wrote:
>> (and +* which I don't get yet -- it does the add only if the TOS is odd)
> I'm pretty sure that's a multiplication primitive
That makes sense!
I don't see quite how it would work, but it ought to be something
like that.
....
Actually, I've stood here in front of the screen for several minutes
and I still don't see how it would work. Does anybody have a hint?
Mary Murphy and Leo Wong
Not a hint, but some code that Jeff wrote (from bmp.seq in the F21
emulator package):
': OUT_LINE ( DEST -- DEST )
dup push push nop
dup dup com -or
2* WIDTH_W # A! nop
@A com 2* com
+* BUFFER # A!
BEGIN
+* 4COLOR
!R+ -UNTIL
drop WIDTH_W # A! @A
com 2* com nop
+* pop drop pop
dup push 80 # nop
+ push BUFFER # A!
BEGIN
+* 4COLOR1
!R+ -UNTIL
drop drop pop drop
pop FF # com nop
+
;
Now explicate that!
M.Simon
I'm doing a Novix style 16 bitter. Because I am doing it in FPGA a 17
bit stack consumes extra resources. I do have instructions that use
the carry. Most of the places where this are valuable are either small
in size or arithmetic. If the interrupt routines do not use the carry
flag (easy) or restore it (a few instructions) there should be few
problems.
One of the neat things about trying different ideas. You can customize
the instructions and see what it does to the real world performance.
Simon
======================================================
>(and +* which I don't get yet -- it does the add only if the TOS is odd)
>
>It's, well, minimal.
>
William Tanksley
>On Wed, 10 Mar 1999 05:16:42 GMT, M.Simon <msi...@tefbbs.com> wrote:
>>I just figured out the value of the A register a couple of days ago.
>>Someone in this group pointed me in the right direction. Wow. All
>>stack instructions are single cycle. And no access to NOS is needed in
>>the machine. And auto increment becomes a feature. And you eliminate a
>>lot of stack thrashing for block moves. Say maybe we need a B
>>register?
>>A@+ B!+
>Gosh, you'll be inventing the register machine next!
An understandable mistake, but a mistake nonetheless. It turns out that a
stack machine has FAR more registers than a register machine; the difference
is that the stack machine addresses the registers implicitly by the type of
operation being performed. For example, all ALU operations take the two TOS
registers as inputs.
This speeds up decoding, and also makes instructions never have to specify
which register they're talking about.
>http://www.cl.cam.ac.uk/users/rrt1001/ | maxim, n. wisdom for fools
--
Jonah Thomas
>Now explicate that!
Well, it doesn't exactly look self-documenting.
>': OUT_LINE ( DEST -- DEST )
> dup push push nop \ R: dest dest
> dup dup com -or \ -1
> 2* WIDTH_W # A! nop \ -2 A: WIDTH_W
> @A com 2* com \ -2 width*2+1
> +* BUFFER # A! \ -2 (width-1)*2+1 A: BUFFER
> BEGIN
> +* 4COLOR \ -2 (width-n)*2+1 4COLOR?
> !R+ -UNTIL \ R: dest dest+n
> drop WIDTH_W # A! @A \ -2 width A: WIDTH_W
> com 2* com nop \ -2 width*2+1
> +* pop drop pop \ -2 (width-1)*2+1 dest
> dup push 80 # nop \ -2 width' dest 80 R: dest
> + push BUFFER # A! \ -2 width' A: BUFFER R: dest dest+80
> BEGIN
> +* 4COLOR1 \ -2 width'-2n 4COLOR1?
> !R+ -UNTIL \ R: dest dest+80+n
> drop drop pop drop \ R: dest
> pop FF # com nop \ dest FFF00
> + \ dest-100
>;
It isn't completely clear what's going on here, but the use of +*
is clear. He increments a number, and he keeps the increment on the
stack. +* doesn't consume NOS, it only conditionally changes TOS.
He first shifts both numbers so he can use the low bit to tell +*
to do it. This means he loses the carry, if he generates a carry
he'll never know. So what he gets from it is the increment isn't
consumed, he doesn't have to OVER it or generate it fresh.
It almost looks like he's using it for a loop. He starts out with a
number at WIDTH_W and he counts down, and when it counts down far
enough to overflow, the loop ends.
I'm pretty sure +* isn't just a multiply primitive. It's a long
knife. It will get used to punch open tin cans, and pry open paint
cans, and whittle, and skin game and slice meat and everything else
you think of when you only have 27 instructions total including NOP .
Bart Lateur
>And your point is we don't need 10000 BL FILL because we have DUP ?
No. Different beast altogether.
But it's easy to imagine how people simply initialize an "object", as
soon as it's allocated, as empty, even if that's not necessary. It never
hurts, does it? You could well end up with code that looks (or behaves)
like:
2VARIABLE origin
: drawit ( x y) origin 2 cells erase
origin 2!
... ;
Simple inspection clearly indicates that clearing ORIGIN is utterly
useless. That doesn't mean code like this won't be written. And so, the
fat creep begins...
Bart.
Reuben Thomas
>On 10 Mar 1999 10:04:40 GMT, Reuben Thomas wrote:
>>Gosh, you'll be inventing the register machine next!
>
>An understandable mistake, but a mistake nonetheless. It turns out that a
>stack machine has FAR more registers than a register machine; the difference
>is that the stack machine addresses the registers implicitly by the type of
>operation being performed. For example, all ALU operations take the two TOS
>registers as inputs.
Not a mistake: stack locations aren't registers (let's not quibble, let's
define: I say a register is directly accessible by machine instructions,
which stack locations aren't: you have to ROLL or PICK them first).
My virtual machine, Mite, has a stack of registers: instructions address
stack items directly, and the stack cannot be permuted. The only
difference from a normal register machine is that registers can be created
and destroyed (in stack order).
<plug>Look under research on my web page (see below) for more information
about Mite.</plug>
--
lis...@zetnet.co.uk
On 1999-03-10 msi...@tefbbs.com said:
:Could you explain how -IF works. I'm ready for another revalation.
-IF, or T0, tests the top bit. It means you don't need a word like 0< -
you can test for negativity right there. If pushed for uses, I'd suggest
that it's handy for loops that count down, or even up:
x + -UNTIL
However, there's another point to that. The P21 core works with words 1
bit longer than memory; any number you load on to the stack must leave
the 0 bit free. Therefore, having the extra bit removes the need to
worry about overflow, and having -IF gives you a way to test it. And a
'+ -IF dest' pairing fits neatly into a P21 word. Also, the combination
of the extra bit and -IF can give you an arithmetically correct <.
Somewhere in all the text on Jeff's site is something else that may give
a clue. Something about Chuck liking to justify constants. I would guess
that this is because a left-justified constant can be tested for
overflow into the 21st bit with -IF.
It isn't so useful on conventional processors, which don't have an extra
bit for each register. A single carry bit is a damned poor substitute.
I've omitted it, in fact, from my designs, simply because it would
appear to be of limited use on a 486. (It may come back for the 32-bit
version.)
I'm not sure that counts as a revelation, but it struck me as an
eminently sensible word to have around. So did +*, once I got it
(although I'm still wondering how to get it into a division operator -
and once again, I suspect -IF would help with that.)
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
lis...@zetnet.co.uk
On 1999-03-10 msi...@tefbbs.com said:
:Source - Destination - Data is a common form.
:I agree about too many registers. But address registers can be
:special purpose.
:I will look into how these ideas change the architecture I am
:working on.
Don't think of A as a register. Think of it as an address bus latch that
has the benefit of being readable too. Especially, don't attempt to
preserve it across calls, or you'll go barmy. ;>
he...@albany.net
lis...@zetnet.co.uk wrote:
>
> I'm not sure that counts as a revelation, but it struck me as an
> eminently sensible word to have around. So did +*, once I got it
> (although I'm still wondering how to get it into a division operator -
> and once again, I suspect -IF would help with that.)
Yes, the "minimal" 27 instructions include a few instructions that
the fattest Forths don't have. It would be interesting if adding
these instructions would make for a better Forth no matter what
size the Forth.
-----------== Posted via Deja News, The Discussion Network ==----------