Re: Stack vs stackless operation

Earlier you wrote about performance, now you switch to clarity of the
code.  What is the goal?

>
Both — one isn't contrary to another.

>
Sometimes the clearer code is slower and the faster code is less clear
(as in the FAXPY-NOSTRIDE example).
>

What I have in mind is: by performing OOS operation
we don't have to employ the whole "Forth machine" to
do the usual things (I mean, of course, the usual
steps described by Brad Rodriguez in his "Moving
Forth" paper).

>
What does "OOS" stand for?

It's an acronym for the term I propose: "out-of-stack" (operation).

 What do you mean with "the usual steps"; I
am not going to read the whole paper and guess which of the code shown
there you have in mind.

I mean the description how the "Forth machine" works:
"Assume SQUARE is encountered while executing some other Forth word.
Forth's Interpreter Pointer (IP) will be pointing to a cell in memory --
contained within that "other" word -- which contains the address of the
word SQUARE. (To be precise, that cell contains the address of SQUARE's
Code Field.) The interpreter fetches that address, and then uses it to
fetch the contents of SQUARE's Code Field. These contents are yet
another address -- the address of a machine language subroutine which
performs the word SQUARE. In pseudo-code, this is:
   (IP) -> W  fetch memory pointed by IP into "W" register
              ...W now holds address of the Code Field
   IP+2 -> IP advance IP, just like a program counter
              (assuming 2-byte addresses in the thread)
   (W) ->  X  fetch memory pointed by W into "X" register
              ...X now holds address of the machine code
   JP (X)     jump to the address in the X register
This illustrates an important but rarely-elucidated principle: the
address of the Forth word just entered is kept in W. CODE words don't
need this information, but all other kinds of Forth words do.
If SQUARE were written in machine code, this would be the end of the
story: that bit of machine code would be executed, and then jump back to
the Forth interpreter -- which, since IP was incremented, is pointing to
the next word to be executed. This is why the Forth interpreter is
usually called NEXT.
But, SQUARE is a high-level "colon" definition… [..]” etc.
( https://www.bradrodriguez.com/papers/moving1.htm )
Many of these steps in particular cases can be avoided
by the use of proposed OOS words, making (at least sometimes)
the Forth program faster — and, as a kinda "bonus", clarity
of the code increases.
Probably in case of the "optimizing compiler" the gain
may not be too significant, from what I already learned
here, still in the case of simpler compilers — and maybe
especially in the case of the ones created for CPUs not
that suitable for Forth at all (lack of registers, like
8051, for example) — probably it may be advantageous.

[..]

Clarity of the code comes as a "bonus" :) yes, we've
got VALUEs and I use them when needed, but their use
still means employing the "Forth machine".

>
What do you mean with 'the "Forth machine"', and how does "OOS"
(whatever that is) avoid it?

By the "Forth machine" I mean that internal work of the
Forth compiler - see the above quote from Brad's paper
- and when we don't need to "fetch memory pointed by
IP into "W" register, advance IP, just like a program
counter" etc. etc. — replacing the whole process,
(which is repeated for each subsequent word again and
again) by a short string of ML instructions — we should
note significant gain in the processing speed.
More I'll able to say after I do the comparison, at
least for fig-Forth on x86 under DOS control - because
so far everything of the above are just my conclusions.
I'll publish first results today in the evening.
--