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

On Jan 6, 2:58 am, m...@[EMAIL PROTECTED]
 (Marcel Hendrix) wrote:
> Now, with that definition of "sane Forth code," an optimizing Forth
> compiler will succeed in removing (behind the scenes) all uses of
> Forth stack operators.

That it a description of what software needs to do do map Forth
software that describes stack operations to optimized code for
a register machine.  Simple Forth code designed to use stacks,
and which when compiled actually uses stacks is not insane.
It is simply a matter of how much work has to be done to
compile code.

Compared to simply compiling stack code directly the idea that
it the compilers job to eliminate the stack code by turning it
into register manipulations on machines not designed to do
stack manipulations efficiently simple Forth looks a lot more
sane.

I think your argument is simply that hardware does C so the
job of Forth compiler is to transform Forth stack into something
close to what hardware designed to run C code needs to do. I
think your argument is simply that sane means C.

 That does not mean that such a compiler does
> not have DUP SWAP or NIP as primitives (e.g. because it needs to handle
> DEFER xt  ' SWAP IS xt ...). OTOH, if your perform run-time profiling
> and find high counts for DUP, ROT etc., then probably either your
> "optimizing Forth compiler" or your profiler is no good.

There could be many reasons for that; badly written code, poor
optimizer, or an efficient SWAP.  The first two things are not good,
but I think it is silly to argue that an efficient SWAP is no good.

> Example:

Take a Forth where a SWAP is one bit in the opcode field that
executes in parallel to returns stack and memory operations
like on the old Novix design.  It would be insane to think
that SWAP should be eliminated.

Admittedly if you are writing Forth code that looks like C
with lots of locals, and compiling to a processor that is
designed to run C, then the compiler will have to do a lot
of things just like a C compiler would do and the
simplicity of the Forth approach is mostly lost.

> iForth version 2.1.2740, generated 20:57:59, December 27, 2007.
> x86 binary, native floating-point, double precision.
> Copyright 1996 - 2008 Marcel Hendrix.
>
> FORTH> : word1 over over -rot dup + + + - ;  ok
> FORTH> see word1
> Flags: TOKENIZE, ANSI
> : word1  OVER OVER -ROT DUP + + + - ;  ok
> FORTH> : test 1 2 word1 drop ;  ok
> FORTH> see test
> Flags: TOKENIZE, ANSI
> : test  1 2 word1 DROP ;  ok
> FORTH> ' test idis ( disassemble generated code )
> $005564C0  : [trashed]
> $005564C8  ;
>
> ( no generated code for test )

Easier to not write the nonsense word1 in the first place.

But if you plan to write nonsense source code and want to
generate decent runtime code then you have the problem
of trying to transform insane code into sane code.  Better
to avoid that kind of problem in the first place.  Why
do people want to write nonsense code?  So they can write
an optimizing compiler that will eliminate the nonsense
that they bothered to write in the first place?

Best Wishes