Re: I found a FORTH stack optimzer, but could use a better version.

On Jan 14, 9:31 am, astrobe <fduboi...@[EMAIL PROTECTED]
> wrote:
> > After a decade of arguing with Chuck about this I concluded a decade
> > ago that he had been right in the first place. It was more productive
> > to write the optimized code in the first place because the best
> > optimizing compilers could not achieve even a 1 to 1 let alone a
> > 10 to 1 compared to that.

A couple of decades noted pinpoints context of this long argument to
the early 90s.  My best optimizing compilers for real but non-optimal
source could could not produce code of equal quality of Chuck's
optimized source.

> Your point of view is a bit unclear to me, so let me ask again a
> question this topic.
> You say that we don't need "big" optimizers if we don't plan
> to write bad code in the first place.

Optimized source will not need and can not use all the optimizations
that make those big optimizers big.  They have optimizations that
apply to badly written code but which end up being useless when
applied to well written code.

> However until recently (well, more or less), Chuck did use in his
> previous Forth systems. Forgive me if I'm wrong, but in CF remains at
> least tail call elimination. I know it is actually needed for CF to
> work, but that's also an optimisation. I'm not sure, but I also
> remember of an optimization of Pentium code when adding a literal.

The spec on the compiler is that some things generate inlined tokens.
But it fact it doesn't have to be 'native' code and could as easily
be ****table token threaded Forth with a virtual machine interpreting
the tokens.  The Forth script in the iTV products could be run in
your PC's browser by invoking an appropriate Forth interpreter. If
you think of it that way the 'native code inlining' (optimization)
looks more like traditional threaded implementations.

In the quest to simplify the compiler and enforce simpler and/or
less syntax and shorter code structures Chuck used self-recursion
instead of BEGIN constructs.  The tail-recursion optimization
is a line of code. It lets one re-use a name that compiles a call
to compile a jump.  It is a sort of syntactic sugar form of
optimization to make the code code shorter and simpler than
using some other symbol to compile a jump to a called word.

Maybe if one uses a different symbol like "-;" to manually
specify a jump instead of a call instead of overloading the
";" symbol with both functions as Chuck does in colorforth
one might not consider it optimization. But aside from
inlining some tokens, having macros that inline tokens
or modify some compiled code machineForth has no optimizations.
colorforth overloads ";" to compile a token or modify a token.
It is a very simple optimization and it takes only a little
code either way.

> Where do you draw the line between a good optimization and a wrong
> one?
>
>  Amicalement,
>   Astrobe

It is not good vs wrong.

It is a matter of where to place effort to get the best results
and varies by person and assignment.  It is hard to be
completely precise, and as always one really needs a hardware
context to answer a question like that and I will provide some
of that below.

I think the im****tant line is between optimizing the im****tant code
and trying to optimize everything equally.  Global-optimization may
be pre-mature optimization. and result in less than optimal code
where it really counts.

Yes, machineForth and colorforth use inlined primitives.  They are
in a macro wordlist in colorforth.  colorforth does and machineForth
may sup****t tail recursion converting calls to jumps.  These are
primitive things.  When you have a 5-bit opcode that can be inlined
at run at on-chip stack speed it makes sense to compile that and
use it instead of a bigger and slower call which also requires
a routine in memory to be called.  And yes, those are generic
optimizations, but at a low level in a very simple form of
compiler.

Im****tant code, identified after profiling or at design
time, can be optimized to the smallest or fastest version as
needed.  Other code can be expressed at a less optimized
performance level but perhaps more easily.

One of the first things I noticed about Chuck's code was that
it had fewer levels, and words had more primitives than the
kind of code I had been writing, it was also more optimized.

So I agree with Chuck that primitives should be favored
in source code where optimization is im****tant.  And yes,
you are right that there are some optimizations in the modern
Forths that Chuck has used.  But one of the things that
distinguishes them from more aggressive globally optimizing
compilers is that the optimizations done by the compiler are
simple and at a low level and that the im****tant optimizations
are left to the programmer.

One of the things I noticed that was different between my code
and Chuck's code was that I had more layers, and more than I
really needed.  I did build complex optimizing compilers that
could take any code and covert it into the best optimized native
machine code that I could.  What I learned in the process was
that this was never quite as optimized as the code produced
with Chuck's approach.  The code generated that way could be
ten or more times faster than simple traditional unoptimized
threaded Forth. But when the compiler tries to optimize all
code it is unlikely to produce as much effective optimization
as the more focused approach.

My experience, especially observing Chuck's code, is that
programmer focus and optimization can produce the highest
quality code and allow a programmer with that mindset to
be most productive.  I think it is an approach that offers
most of the advantages of traditional Forth favoring
simple methods with high programmer productivity and
produces the most optimized code in a certain programming
context.

I once thought that a complex compiler for a simple machine
could generate most efficient native machine code and
equal hand optimized code.  And my complex compilers could
achieve almost the same level of my hand optimized code,
but the problem was that it was still well below the
level of the code Chuck would write.  I could attempt to
write an expert system with a large number of rules to
do real optimization at the design level, perhaps someday.

I thought it would be im****tant to allow "DROP" to remove
a "DUP" if the two opcodes got inlined by different macros.
In my experience it wasn't and the compiler didn't generate
that sort of code often except on very bad code.  In fact I
might want to write "DUP DROP" and really mean just that
and I don't want to fight the tool.

To understand the argument one should recall the context.
You can streamline Forth software and you can streamline
hardware to run streamlined software.  There is a synergy
in the simplicity, the match, and in the completeness.

If you want hardware optimized for performance on bad or
bloated software you cannot optimize that hardware as
much for size, power or cost as much as you can hardware
optimized for performance with streamlined software.
You will need more hardware and more complexity  which
leads to more software and more complexity and to more
difficult to program hardware and software.

If it is a situation of streamlined hardware and you have
streamlined software then complex but dumb (compared to
humans) optimizing compilers won't lead to better code.
If it is a situation with people who really are not
smarter than the dumb compiler then it is a different
situation.  If you intend to use dumb code it is a
different situation.

I think justifying the optimizing compilers by saying
that programs like optimizing compilers are too big
and too complex for humans to really understand or
second guess and have to be that way because hardware
is too big and too complex for humans to really
understand or second guess and has to be because
it has to run big and complex programs like optimizing
compilers (GCC?) is just circular logic and I don't
see myself as inside of that circle.  I know other
people are inside that circle and the logic is
complete as far as that system (circle) is concerned.
But I maintain that a reality also exists outside
that circle.

I also see the situation in that circle as a symptom
that those systems have approached a tipping point
were control and sensible operation become impossible.
I think humans being able to understand more of a
system and not have to second guess it is a good thing.

Best Wishes