Re: [Flashforth-devel] For-next loop - full 16bit count?

[Mikael N. <mik...@fl...>]

If you do a decrement and skip if zero, it means that one index will 
not be counted (=0).
So you would not get the full 16-bit range.
2 for ---> 2 1   (2 counts)
1 for ---> 1     ( 1 counts)
0 for ---> 65535 65534 .. 1 (65535 counts)

So my NEXT uses decrement and skip if carry

Therefore it has work like this
2 for ---> 2 1 0 (3 counts)
0 for ---> 0     ( 1 counts)
65535 for ---> 65535 65534 .. 0 (65536 counts)

BR Mike


On 26.05.2015 11:21, om1zz wrote:
> Some reasoning to mu suggestion below:
> 1. we talking here forth - a better macro assembler
> 2. with your scenario we move towards a primitive function with "more
> intelligence" than one would expected from a better assembler..
> 3. imho for-next in forth is an equivalent of "decrement and skip if
> zero" construct, where (at least me since '82) observed the behaviour
> when putting zero in it loops for a lot of times around :)
> Igor
>
>>Hmm, the old FOR shall behave, I think:
>>
>>2 for ---> 1 0 (2 counts)
>>0 for ----> 65535 65534 .. 0 (65536 counts)
>>
>>new ?FOR
>>
>>2 ?for ---> 1 0 (2 counts)
>>0 ?for ---> skip (none count)
>>
>>So no change with 99,99999% of old code.
>>I.
>>
>>______________________________________________________________
>>> Od: Mikael Nordman <mik...@fl...>
>>> Komu: <fla...@li...>
>>> Datum: 26.05.2015 06:38
>>> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>>>
>>>I did some experiments with this and have now two for..next loops
>>>: t for r@ u. next ;  ok<#,ram>
>>>: tt for2 r@ u. next ;  ok<#,ram>
>>>9 t 8 7 6 5 4 3 2 1 0  ok<#,ram>
>>>9 tt 9 8 7 6 5 4 3 2 1 0  ok<#,ram>
>>>
>>>The only problem is the naming of the words.
>>>The old FOR ideally should be called ?FOR
>>>and the new one FOR.
>>>But that introduces a problem with existing FF code...
>>>
>>>Mike
>>>
>>>On 24.05.2015 16:00, om1zz wrote:
>>>> Yea, I do understand the zero loop skip intention, but I consider 
>>>> that a bug.
>>>> There is no way to do full 65536 loops with 16bit without doing 0 
>>>> for..next.
>>>>
>>>> As the web knowledge says - there are only incompatible for-next 
>>>> loops and inefficient and lazy do-loops :)
>>>>
>>>> I would recommnd to change the behavior to full 16bit, entering 0 
>>>> should be the users responsibility (similar as divide by zero).
>>>