Re: Why is GForth-ITC fast?

In article
<62b620ea-05c4-4817-8e52-e2c81e640693@[EMAIL PROTECTED]
>,
 <brian.fox@[EMAIL PROTECTED]
> wrote:
>I have been dis-assembling pieces of GForth and I don't understand why
>it is generally faster than other ITC Forths that are written in
>Assembler like CI-Forth or my old 16 bit HS/Forth.  The Assembler
>primitives seem to be so much smaller from what I can see.  Is the C
>compiler smarter than we are?
>
>Here are some examples
<code samples snipped>

Speed out of the box is no design goal of ciforth.
Without looking at assembler code you see this in ciforth:
: 1+ 1   + ;
: <> -   0=   0= ;
: 2/   S>D   2   FM/MOD   SWAP   DROP ;

Steve Pelc notes in an other reply that POP and PUSH instructions
may be unfavourable for certain i86 processors. In the code examples
you can see that ciforth uses them instead of faster instructions.
This has to do with optimisation philosophy.

I've published about optimisation in this forum before and you
can read about it on my website.

The ciforth philosophy to optimisation is total introspective
capability. The pop's serve very nicely there. Then this
introspective knowledge is used to optimise in a separate step.
Release 5.0 of ciforth will be totally introspective,
meaning that the stack effect of all kernel words are known by
the kernel or can be derived by simple rules plus few exceptions.
Replacing the pops and other microscopic inefficiencies up front
would defeat that.
A non-optimised program spends most of its time by jumping around and
pu****ng data around. The payload is in operations like ADD, XOR AND
and writing the output files. My first goal is to use the
introspective knowledge to reduce the pu****ng and jumping to a
minimum, then worry about what's left.
If this is ever realized, the results on recursive benchmarks
will be spectacular without even the use of information beyond the
80386 programmers manual.

I expect that ciforth as it is now can be made quite a lot faster by
more classic techniques. If someone is inspired to do so, be my guest.
Have a look at iforth first, that is the Forth to beat. It could
take your inspiration away. Anyway I'm certainly willing to help.
Large f.p. calculations is where speed counts the most.
Speeding up a Forth without floating point could be a waste of
time, depending on your POV.

A further note. I think ciforth is amenable to experimentation, like
changing the threading method, but then you should use the generic
system, that is one step before the ci86.lina.asm such as used by
Spykerman. Putting the code field manually at the end of a header
or changing next is best done at one place in a macro not all over
the place.

>Brian Fox

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@[EMAIL PROTECTED]
 &=n http://home.hccnet.nl/a.w.m.van.der.horst