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

> "Jenny Brien" <jennybrien@[EMAIL PROTECTED]
> wrote in message
news:5b263ec7-3ae3-4c0c-b123-b9eab109e191@[EMAIL PROTECTED]
> On Jan 8, 3:57 am, "Rod Pemberton" <do_not_h...@[EMAIL PROTECTED]
> wrote:
>
> > Oddly, I see no discussion of this paper or his FORTH words in the
archives
> > of c.l.f. (?!?!) Or, on usenet in general...
> >
>
> Interesting, but limited to two stack items.

Yes, I'm looking for a single stack (just data, no rstack) implementation
of
FORTH style stack operators.  SWAP was the original problem, but ROT seems
to be the problem now.  Koopman's Dynamic Instruction Frequencies (which
is
a bit out of date today...) shows DUP, ROT, SWAP as high usage with SWAP
as
the highest.  I'm assuming Koopman's >R and R> are components of other
stack
operator words.

With zero registers (all stack), SWAP is relatively expensive for x86. 
With
two registers for the top two stack items, all operations seem fairly well
balanced and seem to have good pairing.  Instruction pairing on x86 should
get a SWAP operation to 1.5 cycles using 2 stack items in registers,
versus
7 cycles with no registers, since the x86 XCHG instruction can't be paired
and (like other x86 instructions) doesn't work memory-to-memory.

> There is, for example, no way to make ROT.
> For a complete set of operators you also need to be
> able to push and pop between both registers and the rstack.

Yes, you're correct.  With Chapman's solution, SWAP is fast but ROT is
unimplemenable without an "rstack".  The key feature of his solution is
the
elimination of the rstack for "most" operators.  ROT apparently wasn't
presented because it (and probably -ROT,ROLL) needs a single tem****ary
location, i.e., >R, R>.  The tem****ary location happens to be on the
rstack
for FORTH, but could be an available register or memory location for
x86...
Since I like the other perceived advantages, a pure x86 solution for ROT
might be the best choice.

> For a complete set of operators you also need to be
> able to push and pop between both registers and the rstack.

What do you consider "a complete set of operators"?  Or, a good set of
FORTH
stack operators?

> For a complete set of operators you also need to be
> able to push and pop ...[to] the rstack.

If you know of some other common operation(s) that requires R> and >R
besides the ones mentioned, let me know.

> For a complete set of operators

DUP,DROP,SWAP,OVER,NIP and TUCK were presented in the article.  Isn't ROT
(or -ROT, ROLL) the only one really missing?

My own experiments with the java app in my first post showed many common
FORTH stack operators, including the 2DUP, 2DROP, etc. can be reduced to
either 1) combinations of DUP,DROP and one of ROT,-ROT,ROLL, 2) native x86
instructions or 3) instructions using >R and R> for a single location on
the
rstack.  A few could be written using multiple items on the rstack
(inefficient...).  E.g., this abomination for ROT:

:ROT  >R OVER R> OVER >R >R DROP >R DROP R> R> R>;

  Anyway, it appeared that set 3) seemed to completely overlap 1) and 2)
except for SWAP which needed >R and R>.  With the two top stack items in
registers, AFAICT, no rstack (>R and R>) are needed for most of the common
operations, except those that require a stack ****ft: ROT,-ROT,ROLL, and
those only need a single tem****ary location (>R and >R), not a full stack
(rstack).

Except for the issue with ROT, I like Chapman's solution.  It comes the
closest to many features I desire, although it comes with the price of
consuming two more registers...


Rod Pemberton