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

foxchip wrote:
> 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?"

Yes, that's my goal. The reason is that with traditional, widely available
architectures, optimal code is too difficult to generate. I want to keep
my
compiler simple.

> When you write optimized code a peephole optimizer is useless. It can
> only improve non-optimal code.

But I don't write the code. I write Forth. The code is produced by a small
Forth program, which is not producing perfect code, because producing
perfect code on an 68k or x86 is too complex.

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

Yes.

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

I think that's the main purpose of an optimizer. But if you do a good
mapping from stack operations to registers, your OVER DROP DUP DROP SWAP +
DROP sequence will be optimized away, anyway. The question is: Is your
primary goal to eliminate code like this, or is it just a side-effect? I'm
ok if it's just a side-effect, but I wouldn't spent the effort if it was
the primary goal.

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

The target architectures are for sure architectures like x86 - i.e.
ac***ulated cruft from the past 40 years. I won't say that x86 is an
instruction set optimized for C, because such instruction sets have been
done, and they were a lot easier to target for "real native code"
compilers
than x86 is (x86_64 is slightly better, but not that much).

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

I'm thinking about e.g. the LZ77 benchmark that comes with VFX-Forth.
There,
bigFORTH is about 5-10 times slower than VFX-Forth, while on all my "good"
benchmark code (which is more Forth-style than the LZ77 benchmark), the
factor is far less. On the other hand, I could just throw in my OOF
extension, and prove that VFX is a lot worse than bigFORTH, because the
source inliner of VFX doesn't work with my programming style in OOF and
therefore has to be disabled ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/