Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!]

On 12/09/2024 4:51 pm, Paul Rubin wrote:

dxf <dxforth@gmail.com> writes:

Looking at an application with 154 colon definitions...

From the same app:
The easiest stack operations (DUP DROP) account for most.

 
Is the code for this app available?

Previously posted.  You may have seen it.

https://pastebin.com/2xcRSbQW
 

SWAP averaged 1 in 7 definitions.  OVER 1 in 9.  Is 'stack juggling' a
problem in forth?  It doesn't appear to be.

 
The 100+ occurrences of DUP, DROP, and SWAP are either an abstraction
inversion (with a smart compiler, the data ends up in registers that
could be named by locals) or they are stack traffic whose cost has to be
compared with the cost of indexed references to locals in the return
stack.  I'd agree that they aren't necessary "juggling" which evokes
permuting stuff in the stack outside the usual FIFO order.  That does
happpen a little bit though, with OVER, ROT, etc.

If a cost, it's one the programmer can keep to minimum.  With locals there's
an upfront cost that can't be avoided.  Using registers is appealing until
one realizes a call to an external function necessitates placing it back on
the stack.  Costs multiply in the face of many small functions.  Moore touches
on this in one of his speeches:

"I keep asking that question.  What is Forth?  Forth is highly factored code.
 I don't know anything else to say except that Forth is definitions.  If you
 have a lot of small definitions you are writing Forth.  In order to write a
 lot of small definitions you have to have a stack.  Stacks are not popular.
 Its strange to me that they are not.  There is a just lot of pressure from
 vested interests that don't like stacks, they like registers.  Stacks are not
 a solve all problems concept but they are very very useful, especially for
 information hiding and you have to have two of them." - Chuck Moore 1999