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

On Mon, 16 Sep 2024 12:47:10 +0000, dxf wrote:
[..]

FVALUEs may be the way to go for hardware stack.
Is this any better?
>
: tri_mf ( f: x a b c -- mv)
  3 fpick ( x) 3 fpick ( x a) f>=
  3 fpick ( x) 2 fpick ( x b) f< and if
    fdrop               \ x a b
    frot 2 fpick  f-    \ a b x-a
    fswap frot f-       \ x-a b-a
    f/ exit
  then
  3 fpick ( x) 2 fpick ( x b) f>=
  3 fpick ( x) 1 fpick ( x c) f< and if
    frot fdrop          \ x b c
    frot fover fswap f- \ b c c-x
    fswap frot f-       \ c-x c-b
    f/ exit
  then
  fdrop fdrop fdrop fdrop  0e
;

No, it (no locals3) is worse. FPICK is a
problem for iForth because in principle
there can be many values on the FPU stack.
The easy way out was to flush to memory
(assuming real Forthers would balk at
PICK and ROLL anyway).
The title of this thread is quite
appropriate: don't pile on the stack,
don't try to grow it, sparingly re-arrange
and then consume items with operators
that do real work.
FORTH> tnb
\ no locals:  4.9ns/call.
\    locals:  18.3ns/call.
\    globals: 6ns/call.
\ no locals2: 21.9ns/call.
\ no locals3: 23.5ns/call. ok
-marcel