Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Stack vs stackless operation
Date: Mon, 24 Feb 2025 21:50:21 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 74
Message-ID: <2025Feb24.225021@mips.complang.tuwien.ac.at>
References: <591e7bf58ebb1f90bd34fba20c730b83@www.novabbs.com>
Injection-Date: Mon, 24 Feb 2025 23:10:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a1540ae6aa62a663c7f1bc29fd6d7ec5";
	logging-data="1544648"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19KTvLalj1N5uObBRZieG5X"
Cancel-Lock: sha1:nz5s7WWGTE/ACEoXAvrpq4Lzaz8=
X-newsreader: xrn 10.11
Bytes: 3719

zbigniew2011@gmail.com (LIT) writes:
>I wonder: wouldn't it be useful to have stackless basic
>arith operations? I mean instead of fetching the values
>first and putting them on the stack, then doing something,
>and in the end storing the result somewhere wouldn't it
>be practical to use directly the variables?

I don't remember ever doing that, so no, it would not be practical.

Forth has had values for quite a while, so you could avoid the need to
write @ and !; you would instead write something like:

a b + to c

For global values the code is typically not better than when using
variables, though.

>But after I came up with this idea I realized someone
>surely invented that before - it looks so obvious — yet
>I didn't see it anywhere.

The VAX architecture has instructions with three memory operands,
including ADD3.  That feature makes it pretty hard to implement
efficiently.

>Did anyone of you see something
>like this in any code?

No.

>If so — actually why somehow
>(probably?) such solution has not become widespread?

Probably because the case where the two operands of a + are in memory,
and the result is needed in memory is not that frequent.

>Looks good to me; math can be done completely in ML
>avoiding "Forth machine" engagement, therefore saving many
>cycles.

Not sure what you mean with "Forth machine engagement"; with good
Forth compilers these days, a typical stack-to-stack addition is
faster than the best machine code for a memory-to-memory addition.
E.g. VFX64 turns

: dec-u#b ( u1 -- u2 )
    dup #-3689348814741910323 um* nip 3 rshift tuck 10 * - '0' + hold ;  ok

into

( 0050A300    48BACDCCCCCCCCCCCCCC )  MOV     RDX, # CCCCCCCC:CCCCCCCD
( 0050A30A    488BC2 )                MOV     RAX, RDX
( 0050A30D    48F7E3 )                MUL     RBX
( 0050A310    48C1EA03 )              SHR     RDX, # 03
( 0050A314    486BCA0A )              IMUL    RCX, RDX, # 0A
( 0050A318    482BD9 )                SUB     RBX, RCX
( 0050A31B    4883C330 )              ADD     RBX, # 30
( 0050A31F    488D6DF8 )              LEA     RBP, [RBP+-08]
( 0050A323    48895500 )              MOV     [RBP], RDX
( 0050A327    E87CA7F1FF )            CALL    00424AA8  HOLD
( 0050A32C    C3 )                    RET/NEXT
( 45 bytes, 11 instructions )

I don't think that it would be faster or shorter to use
memory-to-memory operations here.  That's also why the VAX died: RISCs
just outperformed it.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/