Re: DO..LOOP and stack shuffling

Liste des GroupesRevenir à cl forth 
Sujet : Re: DO..LOOP and stack shuffling
De : dxforth (at) *nospam* gmail.com (dxf)
Groupes : comp.lang.forth
Date : 03. Jul 2025, 04:59:16
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <1a695310e64de0b2d7589a73bfa9b2c35d2323a0@i2pn2.org>
References : 1 2 3 4 5 6
User-Agent : Mozilla Thunderbird
On 1/07/2025 9:53 pm, Hans Bezemer wrote:
On 28-06-2025 19:46, Anton Ertl wrote:
And while DO has an obvious shortcoming (partially addressed by ?DO),
I have found that variations on ?DO..LOOP are quite helpful in keeping
the number of items on the data stack manageable.  They mean that I
don't have to deal with the index and limit in the loop body, and that
they are also out of the way, so I don't have to think about them in
the loop body.  And when I need the loop index, "I" gives it to me,
like an automatically-defined local.
 
Wow.. I learned this about 20 years ago from the creator of the FIG Forth editor. You find it in the "c" and "delete" commands.
 
And yeah - you're completely right: it works like a "read-only" local.
The TORS can be used as a "r/w" local - with the additional penalty of a R> >R pair (like 2OS comes with a SWAP SWAP penalty). BTW, knowing this gives you hints on how to organize your stacks.
 
The DO..LOOP advantages - nah, not really. E.g. an "address" loop can be done like (a n = address count):
 
  OVER SWAP /ELEMENT * + >R
  BEGIN DUP R@ < WHILE ( ..) /ELEMENT + REPEAT R> DROP DROP
 
No need for BOUNDS DO..LOOP ..
FOR..NEXT is even easier:
 
  >R BEGIN R@ 0> WHILE ( ..) R> 1- >R REPEAT R> DROP
 
So for a lot of applications, I don't really need DO..LOOP and its deeply flawed implementation. And since R@ and I are synonyms, I can even use I if I prefer I! :)
...

When I need a 'counted' loop DO LOOP is always shorter/faster than a BEGIN REPEAT.
I provide a couple FOR NEXTs in the distribution for the curious however they provide
no practical advantage (same footprint and in the case of CP/M even slower).  So for
me the issue was settled long ago.  I imagine it's the same for most forthers even if
their circumstances mean they've opted differently.


Date Sujet#  Auteur
23 Jun 25 * OOS approach revisited23LIT
24 Jun 25 `* Re: OOS approach revisited22dxf
26 Jun 25  `* Re: OOS approach revisited21LIT
27 Jun 25   +* Re: OOS approach revisited19minforth
27 Jun 25   i+* Re: OOS approach revisited14dxf
27 Jun 25   ii`* Re: OOS approach revisited13minforth
27 Jun 25   ii +* Re: OOS approach revisited3LIT
27 Jun 25   ii i`* Re: OOS approach revisited2minforth
28 Jun 25   ii i `- Re: OOS approach revisited1Stephen Pelc
28 Jun 25   ii `* LOOP (was: OOS approach revisited)9Anton Ertl
28 Jun 25   ii  +* Re: LOOP7dxf
28 Jun 25   ii  i`* Re: LOOP6sean
28 Jun 25   ii  i +* Re: LOOP4Anton Ertl
3 Jul 25   ii  i i`* Re: LOOP3minforth
7 Jul 25   ii  i i `* Re: LOOP2Gerry Jackson
7 Jul 25   ii  i i  `- Re: LOOP1minforth
29 Jun 25   ii  i `- Re: LOOP1dxf
28 Jun 25   ii  `- Re: LOOP (was: OOS approach revisited)1Anton Ertl
28 Jun 25   i+* DO..LOOP and stack shuffling (was: OOS approach revisited)3Anton Ertl
3 Jul 25   ii+- Re: DO..LOOP and stack shuffling1dxf
3 Jul 25   ii`- Re: DO..LOOP and stack shuffling1Anton Ertl
30 Jun 25   i`- Re: OOS approach revisited1Hans Bezemer
27 Jun 25   `- Re: OOS approach revisited1dxf

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal