I'm using ESP32Forth v v7.0.6.14

I have a (BIG) problem with FOR NEXT loop....

A simple example:

: myLoop

5 for r@ . next ;

display 5 4 3 2 1 0

So, 6 iterations !!!

And not 5 iterations as attempted....

Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations

BR

On 13 Feb 2022 at 12:12:43 CET, "Marc Petremann" <mpetremann93m@gmail.com>
wrote:

> I'm using ESP32Forth v v7.0.6.14
>
> I have a (BIG) problem with FOR NEXT loop....

Now you know why standards are important. They help to avoid (BIG) problems.

Why not write a proposal for FOR ... NEXT and submit it to forth-standard.org.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

On 13/02/2022 22:12, Marc Petremann wrote:
> I'm using ESP32Forth v v7.0.6.14
>
> I have a (BIG) problem with FOR NEXT loop....
>
> A simple example:
>
> : myLoop
>
> 5 for r@ . next ;
>
> display 5 4 3 2 1 0
>
> So, 6 iterations !!!
>
> And not 5 iterations as attempted....
>
> Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations

They differ too ...

Gforth 0.7.9_20200709

: t for r@ . next ; ok
5 t 5 4 3 2 1 0 ok
0 t 0 ok

E FlashForth 5 ATmega328P

: t for r@ . next ; ok<#,ram>
5 t 4 3 2 1 0 ok<#,ram>
0 t ok<#,ram>

Marc Petremann <mpetremann93m@gmail.com> writes:
>I'm using ESP32Forth v v7.0.6.14
>
>I have a (BIG) problem with FOR NEXT loop....
>
>A simple example:
>
>: myLoop
>
> 5 for r@ . next ;
>
>display 5 4 3 2 1 0
>
>So, 6 iterations !!!
>
>And not 5 iterations as attempted....
>
>Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations

There is no common practice for FOR..NEXT. USE ?DO..LOOP instead!

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Sunday, February 13, 2022 at 12:12:45 PM UTC+1, mpetre...@gmail.com wrote:
> I'm using ESP32Forth v v7.0.6.14
BTW, talking about ESP32 - how do you transfer stuff over the serial line (e.g. if you want to back up a block). Is there a kind of XMODEM implementation or what?

Hans Bezemer

On Sunday, February 13, 2022 at 12:12:45 PM UTC+1, mpetre...@gmail.com wrote:
> I'm using ESP32Forth v v7.0.6.14
> I have a (BIG) problem with FOR NEXT loop....
> A simple example:
>
> : myLoop
> 5 for r@ . next ;
> display 5 4 3 2 1 0
> So, 6 iterations !!!
> And not 5 iterations as attempted....
> Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
But it does make sense.

FORTH> help FOR
....
Each pass through the loop, the loop control parameter is tested
for zero. If it becomes zero the loop is exited, if it does not,
the control parameter is decremented by one. If the limit n|u is
0 to start with, one pass will be made. As this behavior is not
very useful, the FOR AFT ... THEN NEXT construct has gained
popularity.

FORTH> : test 5 for i@ . next ; test 5 4 3 2 1 0 ok
FORTH> : test2 5 for i . next ; test2 5 4 3 2 1 0 ok
FORTH> : test3 5 for r@ . next ; test3 5 4 3 2 1 0 ok

-marcel

On Sunday, February 13, 2022 at 10:42:18 AM UTC-5, Marcel Hendrix wrote:
> On Sunday, February 13, 2022 at 12:12:45 PM UTC+1, mpetre...@gmail.com wrote:
> > I'm using ESP32Forth v v7.0.6.14
> > I have a (BIG) problem with FOR NEXT loop....
> > A simple example:
> >
> > : myLoop
> > 5 for r@ . next ;
> > display 5 4 3 2 1 0
> > So, 6 iterations !!!
> > And not 5 iterations as attempted....
> > Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
> But it does make sense.
>
> FORTH> help FOR
> ...
> Each pass through the loop, the loop control parameter is tested
> for zero. If it becomes zero the loop is exited, if it does not,
> the control parameter is decremented by one. If the limit n|u is
> 0 to start with, one pass will be made. As this behavior is not
> very useful, the FOR AFT ... THEN NEXT construct has gained
> popularity.
>
> FORTH> : test 5 for i@ . next ; test 5 4 3 2 1 0 ok
> FORTH> : test2 5 for i . next ; test2 5 4 3 2 1 0 ok
> FORTH> : test3 5 for r@ . next ; test3 5 4 3 2 1 0 ok

Since FOR is not part of the standard, the question is what is expected of FOR NEXT? I would like to see it streamlined as much as possible. So the decrement, test and jump should be integral since implementations can use efficient instructions for this. That would make it part of NEXT. In that case, you would get numbers printed from 5 down to 0 inclusive.

I assume the OP is looking for a match in range with DO where 5 0 DO i . LOOP would run for 0 1 2 3 4 but not 5. To do that in FOR NEXT it would require the decrement to be done first, the body of the loop executed, then the exit test done in NEXT. Or the loop can be arranged differently, but there would need to be two jumps, either one into a later point in the loop, or one for looping back and one for exiting the loop.

FOR NEXT is not DO LOOP. It counts in the other direction. If you consider the definition of DO with a negative index using +LOOP, I believe the two will count the same way since the exit condition is crossing the boundary between the loop limit and the loop limit minus one. When counting down this means the loop will be executed for 0 as well as 5 in the examples above and also by

: test 0 5 DO I . -1 +LOOP ; test 5 4 3 2 1 0 ok

So maybe the OP doesn't understand this is a consequence of using the same algorithm with a negative index?

I had not seen the FOR AFT THEN NEXT construct. I like it.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

gnuarm.del...@gmail.com schrieb am Sonntag, 13. Februar 2022 um 18:50:12 UTC+1:
> On Sunday, February 13, 2022 at 10:42:18 AM UTC-5, Marcel Hendrix wrote:
> > On Sunday, February 13, 2022 at 12:12:45 PM UTC+1, mpetre...@gmail.com wrote:
> > > I'm using ESP32Forth v v7.0.6.14
> > > I have a (BIG) problem with FOR NEXT loop....
> > > A simple example:
> > >
> > > : myLoop
> > > 5 for r@ . next ;
> > > display 5 4 3 2 1 0
> > > So, 6 iterations !!!
> > > And not 5 iterations as attempted....
> > > Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
> > But it does make sense.
> >
> > FORTH> help FOR
> > ...
> > Each pass through the loop, the loop control parameter is tested
> > for zero. If it becomes zero the loop is exited, if it does not,
> > the control parameter is decremented by one. If the limit n|u is
> > 0 to start with, one pass will be made. As this behavior is not
> > very useful, the FOR AFT ... THEN NEXT construct has gained
> > popularity.
> >
> > FORTH> : test 5 for i@ . next ; test 5 4 3 2 1 0 ok
> > FORTH> : test2 5 for i . next ; test2 5 4 3 2 1 0 ok
> > FORTH> : test3 5 for r@ . next ; test3 5 4 3 2 1 0 ok
> Since FOR is not part of the standard, the question is what is expected of FOR NEXT? I would like to see it streamlined as much as possible. So the decrement, test and jump should be integral since implementations can use efficient instructions for this. That would make it part of NEXT. In that case, you would get numbers printed from 5 down to 0 inclusive.
>

F.ex. match NEXT efficiently to x_86 processor LOOP instruction (counter in _CX register)
and you'll happily count down from 5 to 1.

On Sun, 13 Feb 2022 10:45:33 -0800 (PST)
"minf...@arcor.de" <minforth@arcor.de> wrote:

> gnuarm.del...@gmail.com schrieb am Sonntag, 13. Februar 2022 um 18:50:12 UTC+1:
> > On Sunday, February 13, 2022 at 10:42:18 AM UTC-5, Marcel Hendrix wrote:
> > > On Sunday, February 13, 2022 at 12:12:45 PM UTC+1, mpetre...@gmail.com wrote:
> > > > I'm using ESP32Forth v v7.0.6.14
> > > > I have a (BIG) problem with FOR NEXT loop....
> > > > A simple example:
> > > >
> > > > : myLoop
> > > > 5 for r@ . next ;
> > > > display 5 4 3 2 1 0
> > > > So, 6 iterations !!!
> > > > And not 5 iterations as attempted....
> > > > Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
> > > But it does make sense.
> > >
> > > FORTH> help FOR
> > > ...
> > > Each pass through the loop, the loop control parameter is tested
> > > for zero. If it becomes zero the loop is exited, if it does not,
> > > the control parameter is decremented by one. If the limit n|u is
> > > 0 to start with, one pass will be made. As this behavior is not
> > > very useful, the FOR AFT ... THEN NEXT construct has gained
> > > popularity.
> > >
> > > FORTH> : test 5 for i@ . next ; test 5 4 3 2 1 0 ok
> > > FORTH> : test2 5 for i . next ; test2 5 4 3 2 1 0 ok
> > > FORTH> : test3 5 for r@ . next ; test3 5 4 3 2 1 0 ok
> > Since FOR is not part of the standard, the question is what is expected of FOR NEXT? I would like to see it streamlined as much as possible. So the decrement, test and jump should be integral since implementations can use efficient instructions for this. That would make it part of NEXT. In that case, you would get numbers printed from 5 down to 0 inclusive.
> >
>
> F.ex. match NEXT efficiently to x_86 processor LOOP instruction (counter in _CX register)
> and you'll happily count down from 5 to 1.
>
But if cx=0 at start you'd perform the 'for' loop a large number of times; unless the code starts with
JCXZ end-loop-addr

--
Bah, and indeed Humbug.

Kerr-Mudd, John schrieb am Sonntag, 13. Februar 2022 um 20:52:44 UTC+1:
> On Sun, 13 Feb 2022 10:45:33 -0800 (PST)
> "minf...@arcor.de" <minf...@arcor.de> wrote:
>
> > gnuarm.del...@gmail.com schrieb am Sonntag, 13. Februar 2022 um 18:50:12 UTC+1:
> > > On Sunday, February 13, 2022 at 10:42:18 AM UTC-5, Marcel Hendrix wrote:
> > > > On Sunday, February 13, 2022 at 12:12:45 PM UTC+1, mpetre...@gmail.com wrote:
> > > > > I'm using ESP32Forth v v7.0.6.14
> > > > > I have a (BIG) problem with FOR NEXT loop....
> > > > > A simple example:
> > > > >
> > > > > : myLoop
> > > > > 5 for r@ . next ;
> > > > > display 5 4 3 2 1 0
> > > > > So, 6 iterations !!!
> > > > > And not 5 iterations as attempted....
> > > > > Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
> > > > But it does make sense.
> > > >
> > > > FORTH> help FOR
> > > > ...
> > > > Each pass through the loop, the loop control parameter is tested
> > > > for zero. If it becomes zero the loop is exited, if it does not,
> > > > the control parameter is decremented by one. If the limit n|u is
> > > > 0 to start with, one pass will be made. As this behavior is not
> > > > very useful, the FOR AFT ... THEN NEXT construct has gained
> > > > popularity.
> > > >
> > > > FORTH> : test 5 for i@ . next ; test 5 4 3 2 1 0 ok
> > > > FORTH> : test2 5 for i . next ; test2 5 4 3 2 1 0 ok
> > > > FORTH> : test3 5 for r@ . next ; test3 5 4 3 2 1 0 ok
> > > Since FOR is not part of the standard, the question is what is expected of FOR NEXT? I would like to see it streamlined as much as possible. So the decrement, test and jump should be integral since implementations can use efficient instructions for this. That would make it part of NEXT. In that case, you would get numbers printed from 5 down to 0 inclusive.
> > >
> >
> > F.ex. match NEXT efficiently to x_86 processor LOOP instruction (counter in _CX register)
> > and you'll happily count down from 5 to 1.
> >
> But if cx=0 at start you'd perform the 'for' loop a large number of times; unless the code starts with
> JCXZ end-loop-addr
>

Yep, an endless source of fun in a 64 bit system ...

Le dimanche 13 février 2022 à 12:12:45 UTC+1, Marc Petremann a écrit :
> I'm using ESP32Forth v v7.0.6.14
>
> I have a (BIG) problem with FOR NEXT loop....
>
> A simple example:
>
> : myLoop
>
> 5 for r@ . next ;
>
> display 5 4 3 2 1 0
>
> So, 6 iterations !!!
>
> And not 5 iterations as attempted....
>
> Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
>
> BR

I have replaced FOR..NEXT with DO..LOOP in my code:
https://github.com/MPETREMANN11/ESP32forth/blob/main/displays/SSD1306-5x8rusFonts.txt

"minf...@arcor.de" <minforth@arcor.de> writes:
>gnuarm.del...@gmail.com schrieb am Sonntag, 13. Februar 2022 um 18:50:12 UT=
>C+1:
>> On Sunday, February 13, 2022 at 10:42:18 AM UTC-5, Marcel Hendrix wrote:=
>=20
>> > On Sunday, February 13, 2022 at 12:12:45 PM UTC+1, mpetre...@gmail.com =
>wrote:=20
>> > > I'm using ESP32Forth v v7.0.6.14=20
>> > > I have a (BIG) problem with FOR NEXT loop....=20
>> > > A simple example:=20
>> > >=20
>> > > : myLoop=20
>> > > 5 for r@ . next ;=20
>> > > display 5 4 3 2 1 0=20
>> > > So, 6 iterations !!!=20
>> > > And not 5 iterations as attempted....=20
>> > > Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 =
>iterations=20
>> > But it does make sense.=20
>> >=20
>> > FORTH> help FOR=20
>> > ...=20
>> > Each pass through the loop, the loop control parameter is tested=20
>> > for zero. If it becomes zero the loop is exited, if it does not,=20
>> > the control parameter is decremented by one. If the limit n|u is=20
>> > 0 to start with, one pass will be made. As this behavior is not=20
>> > very useful, the FOR AFT ... THEN NEXT construct has gained=20
>> > popularity.=20
>> >=20
>> > FORTH> : test 5 for i@ . next ; test 5 4 3 2 1 0 ok=20
>> > FORTH> : test2 5 for i . next ; test2 5 4 3 2 1 0 ok=20
>> > FORTH> : test3 5 for r@ . next ; test3 5 4 3 2 1 0 ok
>> Since FOR is not part of the standard, the question is what is expected o=
>f FOR NEXT? I would like to see it streamlined as much as possible. So the =
>decrement, test and jump should be integral since implementations can use e=
>fficient instructions for this. That would make it part of NEXT. In that ca=
>se, you would get numbers printed from 5 down to 0 inclusive.=20
>>=20
>
>F.ex. match NEXT efficiently to x_86 processor LOOP instruction (counter in=
> _CX register)
>and you'll happily count down from 5 to 1.

Yes, but why would one do this? As we have established in an earlier
discussion (see below), the LOOP instruction is typically not faster
than a sequence of simpler instructions:

<2018Jun6.184616@mips.complang.tuwien.ac.at>:
|minforth@arcor.de writes:
|>FOR..NEXT matches easily with the x86 LOOP instruction and ECX as counter.
|>Should do speedy enough. ;-)
| |Have you measured it? I have
|<2017Mar14.183125@mips.complang.tuwien.ac.at>
|<2017Mar15.141411@mips.complang.tuwien.ac.at> and compared the
|following loops:
| |.L5: .L5:
| subq $1, %rax loop .L5
| jne .L5
| |I found that for these loops Sandy Bridge, Haswell, and Skylake take
|~4 cycles per iteration using LOOP, and 1-2 cycles per iteration when
|using jne.

<2018Jun7.141731@mips.complang.tuwien.ac.at>:
|cycles for 1000 iterations
| K10 Excavator Zen
|Phenom II Athlon X4 845 Ryzen 1600X
| 3021 1314 1051 loop
| 2020 1484 1051 sub; jne
| 2026 1489 1053 add; cmp; jne

There is no performance advantage on modern AMD and Intel CPUs for the
instruction LOOP over a good implementation of the Forth word LOOP (as
in the third example).

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 14/02/2022 04:50, Rick C wrote:
>
> I had not seen the FOR AFT THEN NEXT construct. I like it.
Moore accepted FOR NEXT's quirks. Not so others - hence the various attempts
to 'fix it' which made it as complicated as DO LOOP but not as useful.

On Sunday, February 13, 2022 at 7:55:38 PM UTC-5, dxforth wrote:
> On 14/02/2022 04:50, Rick C wrote:
> >
> > I had not seen the FOR AFT THEN NEXT construct. I like it.
> Moore accepted FOR NEXT's quirks. Not so others - hence the various attempts
> to 'fix it' which made it as complicated as DO LOOP but not as useful.

Exactly which quirks where those?

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On 14/02/2022 15:25, Rick C wrote:
> On Sunday, February 13, 2022 at 7:55:38 PM UTC-5, dxforth wrote:
>> On 14/02/2022 04:50, Rick C wrote:
>> >
>> > I had not seen the FOR AFT THEN NEXT construct. I like it.
>> Moore accepted FOR NEXT's quirks. Not so others - hence the various attempts
>> to 'fix it' which made it as complicated as DO LOOP but not as useful.
>
> Exactly which quirks where those?

Loops n+1 times and n=0 isn't a NOOP. Not the behaviour one usually wants.

On Monday, February 14, 2022 at 3:31:58 AM UTC-5, dxforth wrote:
> On 14/02/2022 15:25, Rick C wrote:
> > On Sunday, February 13, 2022 at 7:55:38 PM UTC-5, dxforth wrote:
> >> On 14/02/2022 04:50, Rick C wrote:
> >> >
> >> > I had not seen the FOR AFT THEN NEXT construct. I like it.
> >> Moore accepted FOR NEXT's quirks. Not so others - hence the various attempts
> >> to 'fix it' which made it as complicated as DO LOOP but not as useful.
> >
> > Exactly which quirks where those?
> Loops n+1 times and n=0 isn't a NOOP. Not the behaviour one usually wants.

That is exactly what DO +LOOP does with a negative index. It works fine for me. Addressing, such as in arrays, works exactly that way. You just need to subtract 1 from N before starting the loop to address n-1 down to 0.

Considering that FOR NEXT only decrements by 1, it seems logical to me for it to work this way.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

gnuarm.del...@gmail.com schrieb am Montag, 14. Februar 2022 um 10:40:33 UTC+1:
> On Monday, February 14, 2022 at 3:31:58 AM UTC-5, dxforth wrote:
> > On 14/02/2022 15:25, Rick C wrote:
> > > On Sunday, February 13, 2022 at 7:55:38 PM UTC-5, dxforth wrote:
> > >> On 14/02/2022 04:50, Rick C wrote:
> > >> >
> > >> > I had not seen the FOR AFT THEN NEXT construct. I like it.
> > >> Moore accepted FOR NEXT's quirks. Not so others - hence the various attempts
> > >> to 'fix it' which made it as complicated as DO LOOP but not as useful.
> > >
> > > Exactly which quirks where those?
> > Loops n+1 times and n=0 isn't a NOOP. Not the behaviour one usually wants.
> That is exactly what DO +LOOP does with a negative index. It works fine for me. Addressing, such as in arrays, works exactly that way. You just need to subtract 1 from N before starting the loop to address n-1 down to 0.
>
> Considering that FOR NEXT only decrements by 1, it seems logical to me for it to work this way.
>

FWIW apart from FOR .. NEXT, I use the following array walking words:
FOR> ( start number elementwidth -- ) walk forward, N yields the element address
<FOR ( start number elementwidth -- ) walk backwards, N yields the element address

On 14/02/2022 20:40, Rick C wrote:
> On Monday, February 14, 2022 at 3:31:58 AM UTC-5, dxforth wrote:
>> On 14/02/2022 15:25, Rick C wrote:
>> > On Sunday, February 13, 2022 at 7:55:38 PM UTC-5, dxforth wrote:
>> >> On 14/02/2022 04:50, Rick C wrote:
>> >> >
>> >> > I had not seen the FOR AFT THEN NEXT construct. I like it.
>> >> Moore accepted FOR NEXT's quirks. Not so others - hence the various attempts
>> >> to 'fix it' which made it as complicated as DO LOOP but not as useful.
>> >
>> > Exactly which quirks where those?
>> Loops n+1 times and n=0 isn't a NOOP. Not the behaviour one usually wants.
>
> That is exactly what DO +LOOP does with a negative index. It works fine for me.

Luckily such instances are rare.

> Addressing, such as in arrays, works exactly that way. You just need to subtract 1 from N before starting the loop to address n-1 down to 0.
>
> Considering that FOR NEXT only decrements by 1, it seems logical to me for it to work this way.
>

Not according to eForth, FlashForth etc who developed workarounds for the behaviour.

On Monday, February 14, 2022 at 5:23:03 AM UTC-5, dxforth wrote:
> On 14/02/2022 20:40, Rick C wrote:
> > On Monday, February 14, 2022 at 3:31:58 AM UTC-5, dxforth wrote:
> >> On 14/02/2022 15:25, Rick C wrote:
> >> > On Sunday, February 13, 2022 at 7:55:38 PM UTC-5, dxforth wrote:
> >> >> On 14/02/2022 04:50, Rick C wrote:
> >> >> >
> >> >> > I had not seen the FOR AFT THEN NEXT construct. I like it.
> >> >> Moore accepted FOR NEXT's quirks. Not so others - hence the various attempts
> >> >> to 'fix it' which made it as complicated as DO LOOP but not as useful.
> >> >
> >> > Exactly which quirks where those?
> >> Loops n+1 times and n=0 isn't a NOOP. Not the behaviour one usually wants.
> >
> > That is exactly what DO +LOOP does with a negative index. It works fine for me.
> Luckily such instances are rare.
> > Addressing, such as in arrays, works exactly that way. You just need to subtract 1 from N before starting the loop to address n-1 down to 0.
> >
> > Considering that FOR NEXT only decrements by 1, it seems logical to me for it to work this way.
> >
> Not according to eForth, FlashForth etc who developed workarounds for the behaviour.

So? The thing about Forth is that everyone does what they personally prefer. Writing software is not the same as judging. There's nothing in either of these Forths that says FOR NEXT needs a work around. That's your judgement.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

gnuarm.del...@gmail.com schrieb am Montag, 14. Februar 2022 um 11:46:06 UTC+1:
> On Monday, February 14, 2022 at 5:23:03 AM UTC-5, dxforth wrote:
> > On 14/02/2022 20:40, Rick C wrote:
> > > On Monday, February 14, 2022 at 3:31:58 AM UTC-5, dxforth wrote:
> > >> On 14/02/2022 15:25, Rick C wrote:
> > >> > On Sunday, February 13, 2022 at 7:55:38 PM UTC-5, dxforth wrote:
> > >> >> On 14/02/2022 04:50, Rick C wrote:
> > >> >> >
> > >> >> > I had not seen the FOR AFT THEN NEXT construct. I like it.
> > >> >> Moore accepted FOR NEXT's quirks. Not so others - hence the various attempts
> > >> >> to 'fix it' which made it as complicated as DO LOOP but not as useful.
> > >> >
> > >> > Exactly which quirks where those?
> > >> Loops n+1 times and n=0 isn't a NOOP. Not the behaviour one usually wants.
> > >
> > > That is exactly what DO +LOOP does with a negative index. It works fine for me.
> > Luckily such instances are rare.
> > > Addressing, such as in arrays, works exactly that way. You just need to subtract 1 from N before starting the loop to address n-1 down to 0.
> > >
> > > Considering that FOR NEXT only decrements by 1, it seems logical to me for it to work this way.
> > >
> > Not according to eForth, FlashForth etc who developed workarounds for the behaviour.
> So? The thing about Forth is that everyone does what they personally prefer. Writing software is not the same as judging. There's nothing in either of these Forths that says FOR NEXT needs a work around. That's your judgement.
>

The thing with FOR .. NEXT is that it promises to not clutter the return stack
like DO/?DO .. LOOP. But when you nest words with FOR .. NEXT loops, you
have to save the index register nevertheless. So at the end of the day it does
not buy you much more than a prettier syntax.

On Monday, February 14, 2022 at 3:43:47 PM UTC+1, minf...@arcor.de wrote:
[..]
> The thing with FOR .. NEXT is that it promises to not clutter the return stack
> like DO/?DO .. LOOP. But when you nest words with FOR .. NEXT loops, you
> have to save the index register nevertheless. So at the end of the day it does
> not buy you much more than a prettier syntax.

I tried really hard to use it (it was in the iForth64 metacompiler as the exclusive
means of looping). I've abandoned it as DO LOOP is easier to remember and
get right (IMHO).

-marcel

On Sunday, February 13, 2022 at 1:12:45 PM UTC+2, mpetre...@gmail.com wrote:
> I'm using ESP32Forth v v7.0.6.14
> I have a (BIG) problem with FOR NEXT loop....
> A simple example:
> : myLoop
> 5 for r@ . next ;
> display 5 4 3 2 1 0
> So, 6 iterations !!!
> And not 5 iterations as attempted....
> Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
> BR
In hardware the simplest FOR NEXT implementation iterates at least one time.
But I wanted FlashForth to execute the loop as many times as requested,
and skip the loop if zero times is requested.
This is well aligned with my normal use cases in FlashForth and avoids
extra tests or adjustments before the loop. The index going from n-1 to 0
is well suited for indexing into a zero based array which is what I use a lot,
for example for running averages.
FOR is implemented so that it starts with jumping to NEXT to check if the index is zero,
if not zero NEXT jumps back to FOR (after the inital jump instruction).
The other implementations do not have this extra jump in the beginning and so they loop one extra time.

On Monday, February 14, 2022 at 11:34:42 AM UTC-5, Mike wrote:
> On Sunday, February 13, 2022 at 1:12:45 PM UTC+2, mpetre...@gmail.com wrote:
> > I'm using ESP32Forth v v7.0.6.14
> > I have a (BIG) problem with FOR NEXT loop....
> > A simple example:
> > : myLoop
> > 5 for r@ . next ;
> > display 5 4 3 2 1 0
> > So, 6 iterations !!!
> > And not 5 iterations as attempted....
> > Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
> > BR
> In hardware the simplest FOR NEXT implementation iterates at least one time.

What do you mean by this? A FOR NEXT loop is not exactly hardware. The hardware needs a counter that is decremented and the terminating condition is either reaching zero (internal =0 flag) or counting past zero (underflow or negative flag depending on data type). Depending on how you implement the details of the index numbers this can be at the beginning of the loop or the end. Put it at the beginning of the loop and you get N iterations including none for a starting count of zero. Put it at the end of the loop and you get N+1 iterations from N down to 0.

In all cases of the loop structure the number of iterations can be modified by jumping into the loop appropriately.

This all seems pretty simple and hardware independent to me. What are you thinking?

> But I wanted FlashForth to execute the loop as many times as requested,
> and skip the loop if zero times is requested.
> This is well aligned with my normal use cases in FlashForth and avoids
> extra tests or adjustments before the loop. The index going from n-1 to 0
> is well suited for indexing into a zero based array which is what I use a lot,
> for example for running averages.
> FOR is implemented so that it starts with jumping to NEXT to check if the index is zero,
> if not zero NEXT jumps back to FOR (after the inital jump instruction).

You mean check without decrementing? Does you loop exit when the index reaches zero or when zero is decremented below zero?

> The other implementations do not have this extra jump in the beginning and so they loop one extra time.

Horses for courses.

So if you are indexing a zero based array, how do you write code to handle 0 to N iterations?

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

On Monday, February 14, 2022 at 6:49:59 PM UTC+2, gnuarm.del...@gmail.com wrote:
> On Monday, February 14, 2022 at 11:34:42 AM UTC-5, Mike wrote:
> > On Sunday, February 13, 2022 at 1:12:45 PM UTC+2, mpetre...@gmail.com wrote:
> > > I'm using ESP32Forth v v7.0.6.14
> > > I have a (BIG) problem with FOR NEXT loop....
> > > A simple example:
> > > : myLoop
> > > 5 for r@ . next ;
> > > display 5 4 3 2 1 0
> > > So, 6 iterations !!!
> > > And not 5 iterations as attempted....
> > > Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
> > > BR
> > In hardware the simplest FOR NEXT implementation iterates at least one time.
> What do you mean by this? A FOR NEXT loop is not exactly hardware. The hardware needs a counter that is decremented and the terminating condition is either reaching zero (internal =0 flag) or counting past zero (underflow or negative flag depending on data type). Depending on how you implement the details of the index numbers this can be at the beginning of the loop or the end. Put it at the beginning of the loop and you get N iterations including none for a starting count of zero. Put it at the end of the loop and you get N+1 iterations from N down to 0.
>
> In all cases of the loop structure the number of iterations can be modified by jumping into the loop appropriately.
>
> This all seems pretty simple and hardware independent to me. What are you thinking?

There are some hardware looping implementations in native Forth processors and for example in PIC24/33.
Those typically execute the body of the loop once before decrementing and checking the index at the end of the loop.

> > But I wanted FlashForth to execute the loop as many times as requested,
> > and skip the loop if zero times is requested.
> > This is well aligned with my normal use cases in FlashForth and avoids
> > extra tests or adjustments before the loop. The index going from n-1 to 0
> > is well suited for indexing into a zero based array which is what I use a lot,
> > for example for running averages.
> > FOR is implemented so that it starts with jumping to NEXT to check if the index is zero,
> > if not zero NEXT jumps back to FOR (after the inital jump instruction).
> You mean check without decrementing? Does you loop exit when the index reaches zero or when zero is decremented below zero?

That was a simplification. Actually it decrements and checks if it is decremented below zero.

> So if you are indexing a zero based array, how do you write code to handle 0 to N iterations?

I let FOR NEXT count the iterations and use TOS, or a variable, or a pointer for the indexing.
Flashforth has a reentrant pointer register with indirect addressing (P@ P! etc.)

-- Mike

On Monday, February 14, 2022 at 12:20:47 PM UTC-5, Mike wrote:
> On Monday, February 14, 2022 at 6:49:59 PM UTC+2, gnuarm.del...@gmail.com wrote:
> > On Monday, February 14, 2022 at 11:34:42 AM UTC-5, Mike wrote:
> > > On Sunday, February 13, 2022 at 1:12:45 PM UTC+2, mpetre...@gmail.com wrote:
> > > > I'm using ESP32Forth v v7.0.6.14
> > > > I have a (BIG) problem with FOR NEXT loop....
> > > > A simple example:
> > > > : myLoop
> > > > 5 for r@ . next ;
> > > > display 5 4 3 2 1 0
> > > > So, 6 iterations !!!
> > > > And not 5 iterations as attempted....
> > > > Other FORTH versions (FlashForth, gForth) with FOR..NEXT make only 5 iterations
> > > > BR
> > > In hardware the simplest FOR NEXT implementation iterates at least one time.
> > What do you mean by this? A FOR NEXT loop is not exactly hardware. The hardware needs a counter that is decremented and the terminating condition is either reaching zero (internal =0 flag) or counting past zero (underflow or negative flag depending on data type). Depending on how you implement the details of the index numbers this can be at the beginning of the loop or the end. Put it at the beginning of the loop and you get N iterations including none for a starting count of zero. Put it at the end of the loop and you get N+1 iterations from N down to 0.
> >
> > In all cases of the loop structure the number of iterations can be modified by jumping into the loop appropriately.
> >
> > This all seems pretty simple and hardware independent to me. What are you thinking?
> There are some hardware looping implementations in native Forth processors and for example in PIC24/33.
> Those typically execute the body of the loop once before decrementing and checking the index at the end of the loop.
> > > But I wanted FlashForth to execute the loop as many times as requested,
> > > and skip the loop if zero times is requested.
> > > This is well aligned with my normal use cases in FlashForth and avoids
> > > extra tests or adjustments before the loop. The index going from n-1 to 0
> > > is well suited for indexing into a zero based array which is what I use a lot,
> > > for example for running averages.
> > > FOR is implemented so that it starts with jumping to NEXT to check if the index is zero,
> > > if not zero NEXT jumps back to FOR (after the inital jump instruction).
> > You mean check without decrementing? Does you loop exit when the index reaches zero or when zero is decremented below zero?
> That was a simplification. Actually it decrements and checks if it is decremented below zero.
> > So if you are indexing a zero based array, how do you write code to handle 0 to N iterations?
> I let FOR NEXT count the iterations and use TOS, or a variable, or a pointer for the indexing.
> Flashforth has a reentrant pointer register with indirect addressing (P@ P! etc.)

If you only want the FOR NEXT construct to count iterations and not provide an index to facilitate various addressing operations (which are mostly zero based, it is a computer after all), then why perform the xtra jump? As you say, the decrement and jump operation is typically one instruction. Jumps can muddy execution optimizations. Do an initial test prior to starting the loop. Heck, that can even be done prior to the FOR NEXT construct leaving the loop to be general purpose.

But to each his own.

I've never added registers outside the Forth virtual machine other than a CPU status register. I use flags for conditionals and optimize the code for a simple CPU. This results in 1 clock cycle per instruction for everything and provides for essentially 1 clock cycle interrupt response (or is it zero clock cycles?). When an interrupt is asserted the next instruction is a subroutine call to the interrupt handler that pushes the return address on the return stack and the processor status word on the data stack. The next instruction is the first instruction in the interrupt handler. The FPGA block RAM is large enough there are 8 stacks implemented, one for the main process and 7 interrupts.

The instructions for FOR/NEXT DO/LOOP loops use the return stack for the operands which can also serve as an address. The tools can adjust the index and limit to align with the array pointer and serve dual purposes. Memory instructions in my CPU use the return stack for the memory address completing the utility.

I like lean, simple architectures that are easy to use.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209