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

On Jan 6, 10:27 am, hel...@[EMAIL PROTECTED]
 wrote:
> Oh, I think you're missing the point a little here. Optimization is
> needed only for what you call "nonsense code".

No I get that. I just say that nonsense code is not good code.

> Most stack oriented code is nonsense in terms of a register machine.

It is not nonsense.  It is just different.  If you have no hardware
stack and you stack code you have to do one of two things.  Either you
implement a stack in software as you had to on a IBM 360 because it
had no stack opcodes or you have to translate the code from being
stack notation to something else.  If you assume a register machine
you might want to translate from stack notation to register notation
to produce efficient register machine code.  But a register machine
could also implement a stack in software and it would not be nonsense.

A code optimizer for a register machine can often compile a DUP with
the the code using the duplicated item as a register opcode that
uses the argument without consuming it.  It is not quite like saying
that 'DUP DROP' optimized away in the same way.  DUP is not gone in
the first case, it is just part of the functionality in some other
opcode that is using the 'stack item' cached in a register without
consuming it.

> So well, if you make
> a processor that is stack oriented, you'll be able to write a perfect
> Forth that does not need an optimizer. But even in this case: what's
> about code inlining? That means to combine separately made definitions
> that each for itself are optimal in terms of the things you can
> express with Forth.

I said that there were two uses for such optimizers, crudely inlined
code that produces short useless code sequences at the edges and badly
written code.  You have expressed it a different way.

> But in this case the compiler could be faced with
> the sequence "SWAP +". Iff for the target this makes no sense, then
> the optimizer is useful.

Yes.  That was the case I described.  But the problem that is being
fixed is a problem that was introduced by the compiler.  It is a
solution to an artificial problem that was added to the real problem.
If you use a crude inliner that produces bad code you then have
created a problem that can be addressed by such optimization.

I have certainly done it. I argued with Chuck about the subject
for a decade.

I concluded that like many other things Chuck sees it differently
than most people because he assumes that code and hardware are
understandable and that the best optimizations come from programmers.
Most people assume that compilers are black boxes, and that
hardware is so complicated that they cannot write code that is
as good as what a compiler will generate so they assume that
trust in optimizing compilers is needed.

When Chuck asked, "Is it your intention to write non-optimal code?"
I think he expressed a bigger difference between his notion of the
language that he created and what most programmers do than the
differences one can find in syntax, semantics, or implemenation
details.

Best Wishes