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

On Sun, 15 Sep 2024 8:14:17 +0000, dxf wrote:

>
That appears no better than FVALUEs ...
>
0e fvalue a
0e fvalue b
0e fvalue c
0e fvalue x
>
: tri_mf() ( f: x a b c -- mv)
  to c  to b  to a  to x
  x a f>=
  x b f< and if
    x a f- b a f- f/ exit
  then
  x b f>=
  x c f< and if
    c x f- c b f- f/ exit
  then
  0e
;

I knew about this solution and also the use of fvariables,
I wanted tri_mf() to be used in defining for example:
   neg_big, zero and pos_big like this:
: neg_big -1e309 -1e 0e tri_mf() ;
: zero    -1e    0e  1e tri_mf() ;
: pos_big 0e     1e  1e309 tri_mf() ;
It is ok.
Here the fvalues a, b and c are shared between these words without
problem.
Using the same test to estimate the speed (gforth under wsl) gives about
88 ns/call.
: go 0 do -0.1e neg_big fdrop loop ;  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f. 0.08933806  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f. 0.08499321  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f. 0.08958042  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f. 0.09034804  ok
And with fvariables, the timing gives about 86 ns/call
utime 100000000 go utime d>f d>f f- 1e-8 f* f.  0.08831171  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f.  0.08438598  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f.  0.08442013  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f.  0.08619858  ok
( with locals: 99 ns/call,
  without locals and no fvalues nor fvariables: 67 ns/call) (see
previous posts)
So naming (cells, ...) ( locals, values, variables, ...) simplifies the
elaboration of the solution (code) leaving away heavy stack juggling but
with a loss in speed (not so much).
Ahmed