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

On Jan 6, 12:16 pm, Coos Haak <chfo...@[EMAIL PROTECTED]
> wrote:
> Op Sun, 6 Jan 2008 08:27:20 -0800 (PST) schreef foxchip:
>
> <snip>> 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.
>
> Here you go again, blaming C.

I am not blaming C.  I was simply stating that argument present
was only about how to make Forth more like C because it involved
the assumption that the hardware was going to be hardware
optimized for C code.  This seems to be an implicit assumption
that only includes Forth for C environments as 'the logic'
behind Forth and excludes the logic where Forth is meant to
compete with C.

> You yourself know that there are processors
> that use Forth as their native language. I think there is no machine
that
> uses C as its native language.

That's a silly argument.  My argument is based on what the designers
say they are designing.  If they call Pentium a machine optimized to
run
Unix code they know that Unix is written in C and they probably assume
that other people know that too.

They don't try to claim that there isn't a layer of hardware and
an instruction set below that. But what they are saying is that they
hardware they designed was designed to run C code, one stack, not
two like in Forth.  It is optimized of register use not stack use.
Stacks are not very efficient if you don't design the hardware to
make them efficient.  They don't need much optimization for C use
because they are just generic memory access for the most part.

So when they design for C code they have the idea that a stack is
just an array in memory using pointers to the stack and to stack
frames for locals.  So the hardware is optimized for that, not
for a data stack for data and a return stack for calls.

So the job of a compiler writer in Forth who wants to generate
'efficient' code is to take advantage of the hardware.  When
the hardware looks like what C wants, the hardware likes locals
but doesn't like a data stack.  So the job of the a such a
Forth compiler is to make the code look more like C, de-emphasis
stack use, or eliminate it.  The job of the compiler to take
away the Forth notation and replace it with C style code for
C style hardware.

In this framework there seems to be the assumption that since
locals are needed for C, and hardware that is optimized for C
will be optimized for locals, and since the compiler will
attempt to make the compiled code look more like C and less
like Forth to sup****t things like these locals that locals
are a good thing and that it is even better when the
programmer adapts the source code to have less stack use
and more local use to look more like C to make the job of
the compiler from translating from Forth to C easier.

I just like to point out from time to time that not all
Forth requires the assumption that the job of Forth is
to remove the Forth code or write more C like code in
the first place. I just like to point out that while it
is always the assumption in the C world that software
is C that this is NOT always the assumption in Forth
despite the fact that it is for certain folks who
choose to write software that removes stacks and
favors locals or does the optimizations that C
programmers expect to be done for them.

> So your reasoning is not sane at all.

It is interesting that you equate assuming C, even in
Forth, as sanity.

Best Wishes