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

"Rod Pemberton" <do_not_have@[EMAIL PROTECTED]
> writes Re: I found a FORTH
stack optimzer, but could use a better version.

> "Marcel Hendrix" <mhx@[EMAIL PROTECTED]
> wrote in message
news:02231217223559@[EMAIL PROTECTED]
>> In a Forth optimizing compiler, stack words (in almost all cases for
>> "sane" code) do not generate any code. Such words do not do any 
>> useful "work," they just reorder the stack for words that do, and
>> instruction/address mode selection will take care of it.

> Well, they either have an allocator that keeps track of the adjusted
> position of elements on the stack or they must manually move "cells"
around
> on the stack, correct?

Yes.

> Let's see, Dr. CH Ting's eForth (36 primitives) has 11 stack 
> operators as primitives.  Mikael Patel's minimal FORTH machine
> (9 primitives) has 6 stack operators as primitives.  Mark Hayes
> MRFORTH (23 primitives) has 6 stack operators as primitives.  
> Koopman's high execution frequency list has 5 stack operators.
> GNU GFORTH has (46 primitives) has 16 stack operators as
> primitives.

> I guess the old and simple ones aren't too "sane"...  :-)  
> Of course, they aren't STC either but DTC or ITC.

I think there is a misunderstanding here. The primitives of these old,
non-optimizing, Forths are just fine. When I said 
 
 >> stack words (in almost all cases for "sane" code) do not generate 
 >> any code.

.... the "sane" part is not making making fun of these classic 
compilers. What I mean with "sane" code is Forth source code with
a limited number of integer and float stack entries (like 3, maybe
more when there are double parameters [e.g. strings]). For example,
A word which uses "4 ROLL" or "5 PICK 7 PICK" or "2>R >R >R 6 PICK 
>R 2R>" is not considered sane by me.

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 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.

Example:

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 )

-marcel