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

On Jan 6, 9:34 am, Bernd Paysan <bernd.pay...@[EMAIL PROTECTED]
> wrote:
> foxchip wrote:
> > Simple peephole optimizers are often used
> > to patch badly generated code this way.
>
> The quite simple peephole optimizer I've implemented in bigFORTH nearly
20
> years ago wasn't there to improve badly code; most patterns I've put in
> were there to improve good code.

I suppose I was being too black/white.  Chuck once asked how it should
be phrased, "Optimized/not optimized?"  "Optimal/non-optimal?"
In any event he asked, "Is it your goal to write non-optimal code?"

When you write optimized code a peephole optimizer is useless. It can
only improve non-optimal code.  Maybe not the worst code ever, and
maybe
you call it 'good' code.  I was simply saying that optimized code
cannot be optimized by something like a peephole optimizer.

A simple code optimizer that does macro-inclining in a brain-dead way
will not generate optimimal code, and it is the sort of things I
called the 'bad' code that a cheap peephole optimizer can improve.

> But it is a peephole optimizer on the machine code level
> (68k and later x86 machine code). The intention was to
> be simple (the rule interpreter is two screens, the rules themselves
take a
> line each), fast and reversible. SEE can undo most of the optimizations
to
> figure out what kind of source code might have generated the machine
code.

That's a bit more sophisticated than a simple peephole optimizer that
attempts to combine code segments at the Forth primitive level.  You
are
talking about native code optimization in environments with more
details
there.  In that context I understand your comment that the technique
can
'optimize' the native code generated by a native code compiler.

That's not quite the same thing as wanting to optimize "SWAP +"
which is what I was talking about.  You are getting away from the
idea that optimizers are good for the "OVER DROP DUP DROP SWAP + DROP"
problem and come back to the issue of what one has to do to translate
between what is efficient on a processor designed to run some kind of
code and code expressed in some language.

> Today, a real native code compiler can be a factor 1.5-2 faster for good
> code, and a factor 5-10 for bad code.

That is exactly the sort of thing that I was addressing.  You are
using
the phrase 'real native code' in a way that assumes that it means C
style hardware and software.  Worse yet is assumes that what it is
comparing too is so universally understood that it does not even need
to be stated explicitly.

You don't even state 'what' a 'real native code compiler' is being
compared to.  It is easy to say 'it is ten times faster' if you don't
give what you compare to because you can always produce something
ten times as lame as the example claimed to be ten times better.

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.

> I've started a real native code
> compiler for my 4stack processor (quite different target), and I'm
planning
> to implement one with similar algorithms for x86_64, where the
additional
> registers increase the benefit vs. the peephole optimizer. As time
permits,
> for sure.

I have written 'real native code' compilers for stack processors.
Other
people were happy with simple compilers but I wanted to see whether
having
hundreds of native code sequences and dozens of rules for code
optimization.
After lots of work, lots of experience, and lots of observing master
Forth
programmers in action I concluded that it was better for some people
to
have the intention to write optimized code in the first place.

I understand that this is not popular and as Chuck has said is
responsible
for Forth having a reputation as an elitist language.  The real value
of
code optimizers is for the intention to write bad code in the first
place.

Best Wishes