Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: melahi_ahmed@yahoo.fr (Ahmed)
Newsgroups: comp.lang.forth
Subject: Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!]
Date: Mon, 16 Sep 2024 13:21:19 +0000
Organization: novaBBS
Message-ID: <37b7979d508f516f88f7e1fa1967a1b1@www.novabbs.com>
References: <nnd$61e0ad9a$48ed61c2@b4d945e456041481> <vasqjd$icjm$1@dont-email.me> <66d26c4b$1@news.ausics.net> <vaubf7$tbke$1@dont-email.me> <nnd$04cff141$0193ba04@301336b8dd8ed69a> <vbfqnd$v4c4$1@dont-email.me> <nnd$26b4d59b$27bdb181@ce638e508b04426e> <87bk0vbvgk.fsf@nightsong.com> <66e0fa58$1@news.ausics.net> <66e11d64$1@news.ausics.net> <877cbh4b6z.fsf@nightsong.com> <66e2a497$1@news.ausics.net> <2024Sep14.143207@mips.complang.tuwien.ac.at> <e29088cacf765cd0da6519e333fa78f1@www.novabbs.com> <2024Sep14.170836@mips.complang.tuwien.ac.at> <06f3574dfa63a100a731c944d8e16473@www.novabbs.com> <66e69759$1@news.ausics.net> <2407b32e4980726ab60611863c3d485e@www.novabbs.com> <19ef9c8626b9a9374535476f9073ad03@www.novabbs.com> <5631e74e91f46765ffe32945f12b748e@www.novabbs.com> <6e80829c88e569bb309120de17818b58@www.novabbs.com> <bc18049678801b31614fe87eba889a48@www.novabbs.com> <66e828ce$1@news.ausics.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2277886"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="hogn68ACS2mVV0PcPkBzD/3kIXL71Lu5zlxJ/QczJJE";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$2UCT1D57R1e.SSYkXyxRj.d4ZuG2e3CwH0kKyWfR2e0IFW5vfj/8m
X-Rslight-Posting-User: cdd77cd46f5cefdf617b921703a970831cf47f35
Bytes: 3953
Lines: 81

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

> On 16/09/2024 8:13 pm, mhx wrote:
>> [..]
>> FORTH> tnb
>> \ no locals:  5ns/call.
>> \    locals:  18.2ns/call.
>> \    globals: 6ns/call.
>> \ no locals2: 21.9ns/call. ok
>>
>> This appears not to be a good idea.
>> The root cause is piling up too many
>> items on the F-stack (exceeding the
>> hardware FPU stack limits).
>
> 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
> ;


Your solution gives the best speed compared to others. With gforth under
wsl, I find 59ns/call


Here is the code:
\ here is your definition

: 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
;

\ and then the code
: neg_big -1e308  -1e    0e    tri_mf ;
: zero    -1e      0e    1e    tri_mf ;
: pos_big  0e      1e    1e308 tri_mf ;

: fuzzify ( f: x)
    fdup neg_big cr f.
    fdup zero    cr f.
         pos_big cr f.
;

: go 0 do -0.1e neg_big fdrop loop ;

utime 100000000 go utime d>f d>f f- 1e-8 f* f. 0.05871598  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f. 0.05926772  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f. 0.05896149  ok
utime 100000000 go utime d>f d>f f- 1e-8 f* f. 0.05899284  ok


Ahmed