flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] For-next loops - the New Design

[craig b. <dab...@ya...>]

As the self-designated dinosaur of this group, I'm afraid I see this whole discussion as a lot of gas in the wind...  This is not a problem with the language, the language is functioning normally as it has since I started playing with it on my Apple ][ early in the eighties.  The problem is with the programmer's imagination.  If a ForNext loop is counting up and won't give you a Zero to start off with, you do the operation once then start the loop.  If it's counting down and won't do a Zero Pass at the end, you do the operation once after the loop finishes.  I leave enumeration of the rest of the possabilities as an exercise for the student.

There's no future in rewriting a classic language to suit niggling small annoyances,  remember what happened with C+?  Object oriented junk is destroying the programmers' minds...hack...cough...pitui...harumph!...Sorry about that, I had promised not to rant.  But if Forth isn't a high-level language by modern definitions, then ANSI C, BASIC, and PASCAL aren't either.  Granted, FORTRAN was only ever an intermediate-level language, but we all had to start somewhere.

Point is, Mike's handed us a great little tool here that's amazingly true to the spirit and execution of its historical roots.  Why screw it up?  If a non-standard loop structure is desirable for your application, another loadable textfile in the toolbox collection is always welcome, I say.

Carry on and don't mind me (grin).
craig

Re: [Flashforth-devel] For-next loops - the New Design

[Herman A. <exp...@vn...>]

I think the best solution of the  n for ... next  cycle, witch run 
n-times, including n=0, as it is in the FF now. This principle 
incopatible to cover the for full 16-bit range.

To rich the full 16bit range must be defined an other for-next like 
cycle, with different approach. In this case the goal is not to makes n 
count, but to cover a non-zero long range. The cycle must run n to 0, 
including n and 0. The 'next' decrements after testing for zero. We need 
only to find the appropriate word-names.
Because it is mostly usable for memory addressing, maybe mfor-mnext.
n mfor r@ u. mnext   --->  n ... 0
0 mfor r@ u. mnext   --->  0
5 mfor r@ u. mnext   --->  5 4 3 2 1 0
65535 mfor r@ u. mnext   --->  65535 65534 ... 1 0

BR
Attila

Re: [Flashforth-devel] For-next loops - the New Design

[Peter J. <pe...@me...>]

I don't have a FlashForth board handy tonight but I see that Gforth 
wraps around as you show for FF,
  and it implements a FOR loop that gives n+1 iterations.
: test2 for i u. next ;  ok
10 test2 10 9 8 7 6 5 4 3 2 1 0  ok
0 test2 0  ok
1 test2  1 0  ok
The Gforth manual also states (at the end of section 5.8.3): "This loop 
structure is not defined in ANS Forth. In Gforth, this loop iterates n+1 
times; i produces values starting with n and ending with 0. Other Forth 
systems may behave differently, even if they support FOR loops. To avoid 
problems, don’t use FOR loops."

It doesn't worry (greatly) me that FF is a little different.  It's 
important to me that it is stable and documented.  Whatever Mike settles 
on, I'll put into the tutorial/reference material that I give to students.

Peter J.


On 28/05/15 22:11, om1zz wrote:
> Peter,
>
> for people coming from high-level languages there will be ?for-next.
>
> 0 for-next may loop 65536 times, because the do-loop does the same (and it is therefore consistent),
> You may try (in FF btw.):
>
> : mytest do i u. loop ;
> 0 0 mytest
>
> what you will see? This:
>
> 0 0 mytest 0 1 2 3 4 5 6 7 8...
> 65533 65534 65535  ok<#,ram>
>
> It loops 65536 times (2^16). That is normal in forth.
>
> Forth is not a high-level language, that has to be explained to the people coming from high-level area..
>
> Igor
>
> ______________________________________________________________
>> Od: Peter Jacobs <pe...@me...>
>> Komu: <fla...@li...>
>> Datum: 28.05.2015 13:27
>> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>>
>> Igor,
>>     I'm going to disagree with you on preference.  I think that most
>> people will come to FF, not from assembler, but from some other
>> high-level language and they will expect "0 for" to iterate 0 times.  I
>> know that I do.  If I wanted to iterate 65536 times in one of my
>> programs, I'd likely be wanting to do more iterations at some point and
>> I'd use a 24-bit or 32-bit counter anyway.
>> Regards,
>> Peter J.
>>
>>
>> On 28/05/15 21:03, om1zz wrote:
>>> Do you insist on a single asm instruction for the entire for-next loop implementation?
>>> Do-loop is min 30 instructions in FF.
>>>
>>> I think that with N vs. N+1 idea when handling for (in any form) you break the consistency of for-loop implementation understanding.
>>>
>>> I would easily spend another 1-2 asm instructions and do it consistent. Speed plays no role here.
>>> When somebody wants to bitbang a pin it could be done in asm.
>>>
>>> N for ..
>>> N ?for ..
>>>
>>> both will do N loops through the body. The only diff is the ?for skips zero. That is very consistent.
>>>
>>> 0 for
>>>
>>> will do M loops where M=2^16 in this case. That is also consistent as you work with 16bit assembler.
>>>
>>> I am suggesting that as a standard for the for-loop design for any architecture on my github.
>>>
>>> Igor.
>>>
>>>
>>>
>>>
>>> ______________________________________________________________
>>>> Od: Mikael Nordman <mik...@fl...>
>>>> Komu: <fla...@li...>
>>>> Datum: 27.05.2015 17:59
>>>> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>>>>
>>>> Yes, Yes,
>>>> I understand what you want.
>>>> But you dont seem to understand that it cannot be done
>>>> in a simple for..next loop that has only one decrement and branch
>>>> instruction, and that has an index that counts down to zero.
>>>>
>>>> In order the get the full 16 bit loop count you have to give as input
>>>> the N+1 count.
>>>>
>>>> But if you have some idea how to implement it in PIC assembly code,
>>>> please write it out.
>>>>
>>>> BR Mike
>>>>
>>>> On 27.05.2015 10:32, om1zz wrote:
>>>>> 0 _for 65535 65534 ..
>>>>> .. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
>>>>> 65536 ok<#,ram>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Flashforth-devel mailing list
>>>> Fla...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>

Re: [Flashforth-devel] For-next loops - the New Design

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

Igor,
I don't think your HW arguement really works.

I had to introduce an extra "high level intelligence" branch and 
decrement to get the desired behavior.
See my previous post for that.

Also if you bother to take a look at the HW loops inside the PIC24/33 ( 
DO-LOOP and REPEAT )
these all loop N+1 times. Just because it is efficient in HW.

But from a programmer point of view I think it is good to make the 0 
FOR2 .. NEXT to loop $10000 times.

0 FOR .. NEXT will loop 0 times. I rely quite a bit on this in many 
places.

Still I am not convinced that the FOR2 is needed that much, so it could 
be left out also.
Most loops that I use are way smaller than $10000 times.
In your special case you can do that $10000 time loop with BEGIN UNTIL

BR Mike

On 28.05.2015 16:11, om1zz wrote:
> Peter,
>
> long time back (2009-10??) there was no do-loop implemented, and we
> had discusions about that, afaik.
> The reason was it was difficult to implement, heavy and therefore 
> slow.
>
> Instead of that, Mike did FOR, which is very fast, as it does just a
> single instruction check when passing index to zero.
>
> That introduces the bug (my interpretation) which has not been
> discovered till today (why?).
>
> Mike has written the do-loop recently (as the external .txt source)
> for compatibility reasons (as I claimed long time back mainly because
> my intention with floating point library which uses do-loop, and
> others).
>
> Forth is a "better assembler" or "clever assembler" used today for
> low level programming on hardware.
>  No high-level elements there. Just a simple puzzle.
>
> When working so close to the HW you must admit the hw-specific
> behaviour of the forth.
>
> So - shooting a zero into a loop means it will underrun (within the
> size of the basic cell, here 16bit) and loop over till zero (65536x).
> That is normal, and this is how the MCU works (all of them, PIC, AVR,
> ARM, MIPS, x86, etc).
>
> Pushing any "high-level intelligence" into the forth's primitive,
> basic, fundamental words changes the forth into a Frankenstein.. :)
>
> Igor,
> assistant to Mr. F.
>

Re: [Flashforth-devel] For-next loops - the New Design

[om1zz <om...@vo...>]

Peter, 

long time back (2009-10??) there was no do-loop implemented, and we had discusions about that, afaik.
The reason was it was difficult to implement, heavy and therefore slow.

Instead of that, Mike did FOR, which is very fast, as it does just a single instruction check when passing index to zero.

That introduces the bug (my interpretation) which has not been discovered till today (why?).

Mike has written the do-loop recently (as the external .txt source) for compatibility reasons (as I claimed long time back mainly because my intention with floating point library which uses do-loop, and others).

Forth is a "better assembler" or "clever assembler" used today for low level programming on hardware.
 No high-level elements there. Just a simple puzzle.

When working so close to the HW you must admit the hw-specific behaviour of the forth.

So - shooting a zero into a loop means it will underrun (within the size of the basic cell, here 16bit) and loop over till zero (65536x). 
That is normal, and this is how the MCU works (all of them, PIC, AVR, ARM, MIPS, x86, etc).

Pushing any "high-level intelligence" into the forth's primitive, basic, fundamental words changes the forth into a Frankenstein.. :)

Igor, 
assistant to Mr. F.


______________________________________________________________
> Od: "om1zz" <om...@vo...>
> Komu: Peter Jacobs <pe...@me...>, <fla...@li...>
> Datum: 28.05.2015 14:11
> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>
>Peter,
>
>for people coming from high-level languages there will be ?for-next.
>
>0 for-next may loop 65536 times, because the do-loop does the same (and it is therefore consistent),
>You may try (in FF btw.):
>
>: mytest do i u. loop ;
>0 0 mytest
>
>what you will see? This:
>
>0 0 mytest 0 1 2 3 4 5 6 7 8...
>65533 65534 65535  ok<#,ram>
>
>It loops 65536 times (2^16). That is normal in forth.
>
>Forth is not a high-level language, that has to be explained to the people coming from high-level area..
>
>Igor
>
>______________________________________________________________
>> Od: Peter Jacobs <pe...@me...>
>> Komu: <fla...@li...>
>> Datum: 28.05.2015 13:27
>> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>>
>>Igor,
>>    I'm going to disagree with you on preference.  I think that most 
>>people will come to FF, not from assembler, but from some other 
>>high-level language and they will expect "0 for" to iterate 0 times.  I 
>>know that I do.  If I wanted to iterate 65536 times in one of my 
>>programs, I'd likely be wanting to do more iterations at some point and 
>>I'd use a 24-bit or 32-bit counter anyway.
>>Regards,
>>Peter J.
>>
>>
>>On 28/05/15 21:03, om1zz wrote:
>>> Do you insist on a single asm instruction for the entire for-next loop implementation?
>>> Do-loop is min 30 instructions in FF.
>>>
>>> I think that with N vs. N+1 idea when handling for (in any form) you break the consistency of for-loop implementation understanding.
>>>
>>> I would easily spend another 1-2 asm instructions and do it consistent. Speed plays no role here.
>>> When somebody wants to bitbang a pin it could be done in asm.
>>>
>>> N for ..
>>> N ?for ..
>>>
>>> both will do N loops through the body. The only diff is the ?for skips zero. That is very consistent.
>>>
>>> 0 for
>>>
>>> will do M loops where M=2^16 in this case. That is also consistent as you work with 16bit assembler.
>>>
>>> I am suggesting that as a standard for the for-loop design for any architecture on my github.
>>>
>>> Igor.
>>>
>>>
>>>
>>>
>>> ______________________________________________________________
>>>> Od: Mikael Nordman <mik...@fl...>
>>>> Komu: <fla...@li...>
>>>> Datum: 27.05.2015 17:59
>>>> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>>>>
>>>> Yes, Yes,
>>>> I understand what you want.
>>>> But you dont seem to understand that it cannot be done
>>>> in a simple for..next loop that has only one decrement and branch
>>>> instruction, and that has an index that counts down to zero.
>>>>
>>>> In order the get the full 16 bit loop count you have to give as input
>>>> the N+1 count.
>>>>
>>>> But if you have some idea how to implement it in PIC assembly code,
>>>> please write it out.
>>>>
>>>> BR Mike
>>>>
>>>> On 27.05.2015 10:32, om1zz wrote:
>>>>> 0 _for 65535 65534 ..
>>>>> .. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
>>>>> 65536 ok<#,ram>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Flashforth-devel mailing list
>>>> Fla...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>>
>>------------------------------------------------------------------------------
>>_______________________________________________
>>Flashforth-devel mailing list
>>Fla...@li...
>>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>

Re: [Flashforth-devel] For-next loops - the New Design

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

No I do not insist.

Something like this should actually fullfill a 0 based index for-next 
that loops N times.

(FOR2):
cp0   [W14]
bra   nz, (FOR)
decf  [W14], [W14]
(FOR):
mov   [w14--], [w15++]
LABEL:

(NEXT):
decf  [--w15], [w15++]
bra   c, LABEL

Still there is the problem of renaming FOR to ?FOR that would break 
existing user code.
So I will call it FOR2.
I think that is reasonable because most words will never need to loop 
65536 times anyway.

BR Mike

On 28.05.2015 14:03, om1zz wrote:
> Do you insist on a single asm instruction for the entire for-next
> loop implementation?
> Do-loop is min 30 instructions in FF.
>

Re: [Flashforth-devel] For-next loops - the New Design

[om1zz <om...@vo...>]

Peter,

for people coming from high-level languages there will be ?for-next.

0 for-next may loop 65536 times, because the do-loop does the same (and it is therefore consistent),
You may try (in FF btw.):

: mytest do i u. loop ;
0 0 mytest

what you will see? This:

0 0 mytest 0 1 2 3 4 5 6 7 8...
65533 65534 65535  ok<#,ram>

It loops 65536 times (2^16). That is normal in forth.

Forth is not a high-level language, that has to be explained to the people coming from high-level area..

Igor

______________________________________________________________
> Od: Peter Jacobs <pe...@me...>
> Komu: <fla...@li...>
> Datum: 28.05.2015 13:27
> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>
>Igor,
>    I'm going to disagree with you on preference.  I think that most 
>people will come to FF, not from assembler, but from some other 
>high-level language and they will expect "0 for" to iterate 0 times.  I 
>know that I do.  If I wanted to iterate 65536 times in one of my 
>programs, I'd likely be wanting to do more iterations at some point and 
>I'd use a 24-bit or 32-bit counter anyway.
>Regards,
>Peter J.
>
>
>On 28/05/15 21:03, om1zz wrote:
>> Do you insist on a single asm instruction for the entire for-next loop implementation?
>> Do-loop is min 30 instructions in FF.
>>
>> I think that with N vs. N+1 idea when handling for (in any form) you break the consistency of for-loop implementation understanding.
>>
>> I would easily spend another 1-2 asm instructions and do it consistent. Speed plays no role here.
>> When somebody wants to bitbang a pin it could be done in asm.
>>
>> N for ..
>> N ?for ..
>>
>> both will do N loops through the body. The only diff is the ?for skips zero. That is very consistent.
>>
>> 0 for
>>
>> will do M loops where M=2^16 in this case. That is also consistent as you work with 16bit assembler.
>>
>> I am suggesting that as a standard for the for-loop design for any architecture on my github.
>>
>> Igor.
>>
>>
>>
>>
>> ______________________________________________________________
>>> Od: Mikael Nordman <mik...@fl...>
>>> Komu: <fla...@li...>
>>> Datum: 27.05.2015 17:59
>>> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>>>
>>> Yes, Yes,
>>> I understand what you want.
>>> But you dont seem to understand that it cannot be done
>>> in a simple for..next loop that has only one decrement and branch
>>> instruction, and that has an index that counts down to zero.
>>>
>>> In order the get the full 16 bit loop count you have to give as input
>>> the N+1 count.
>>>
>>> But if you have some idea how to implement it in PIC assembly code,
>>> please write it out.
>>>
>>> BR Mike
>>>
>>> On 27.05.2015 10:32, om1zz wrote:
>>>> 0 _for 65535 65534 ..
>>>> .. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
>>>> 65536 ok<#,ram>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] For-next loops - the New Design

[Peter J. <pe...@me...>]

Igor,
    I'm going to disagree with you on preference.  I think that most 
people will come to FF, not from assembler, but from some other 
high-level language and they will expect "0 for" to iterate 0 times.  I 
know that I do.  If I wanted to iterate 65536 times in one of my 
programs, I'd likely be wanting to do more iterations at some point and 
I'd use a 24-bit or 32-bit counter anyway.
Regards,
Peter J.


On 28/05/15 21:03, om1zz wrote:
> Do you insist on a single asm instruction for the entire for-next loop implementation?
> Do-loop is min 30 instructions in FF.
>
> I think that with N vs. N+1 idea when handling for (in any form) you break the consistency of for-loop implementation understanding.
>
> I would easily spend another 1-2 asm instructions and do it consistent. Speed plays no role here.
> When somebody wants to bitbang a pin it could be done in asm.
>
> N for ..
> N ?for ..
>
> both will do N loops through the body. The only diff is the ?for skips zero. That is very consistent.
>
> 0 for
>
> will do M loops where M=2^16 in this case. That is also consistent as you work with 16bit assembler.
>
> I am suggesting that as a standard for the for-loop design for any architecture on my github.
>
> Igor.
>
>
>
>
> ______________________________________________________________
>> Od: Mikael Nordman <mik...@fl...>
>> Komu: <fla...@li...>
>> Datum: 27.05.2015 17:59
>> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>>
>> Yes, Yes,
>> I understand what you want.
>> But you dont seem to understand that it cannot be done
>> in a simple for..next loop that has only one decrement and branch
>> instruction, and that has an index that counts down to zero.
>>
>> In order the get the full 16 bit loop count you have to give as input
>> the N+1 count.
>>
>> But if you have some idea how to implement it in PIC assembly code,
>> please write it out.
>>
>> BR Mike
>>
>> On 27.05.2015 10:32, om1zz wrote:
>>> 0 _for 65535 65534 ..
>>> .. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
>>> 65536 ok<#,ram>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
> ------------------------------------------------------------------------------
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] For-next loops - the New Design

[om1zz <om...@vo...>]

Do you insist on a single asm instruction for the entire for-next loop implementation?
Do-loop is min 30 instructions in FF.

I think that with N vs. N+1 idea when handling for (in any form) you break the consistency of for-loop implementation understanding.

I would easily spend another 1-2 asm instructions and do it consistent. Speed plays no role here.
When somebody wants to bitbang a pin it could be done in asm.

N for ..
N ?for ..

both will do N loops through the body. The only diff is the ?for skips zero. That is very consistent.

0 for 

will do M loops where M=2^16 in this case. That is also consistent as you work with 16bit assembler.

I am suggesting that as a standard for the for-loop design for any architecture on my github.

Igor.




______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 27.05.2015 17:59
> Předmět: Re: [Flashforth-devel] For-next loops - the New Design
>
>Yes, Yes,
>I understand what you want.
>But you dont seem to understand that it cannot be done
>in a simple for..next loop that has only one decrement and branch 
>instruction, and that has an index that counts down to zero.
>
>In order the get the full 16 bit loop count you have to give as input 
>the N+1 count.
>
>But if you have some idea how to implement it in PIC assembly code,
>please write it out.
>
>BR Mike
>
>On 27.05.2015 10:32, om1zz wrote:
>> 0 _for 65535 65534 ..
>> .. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
>> 65536 ok<#,ram>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] For-next loops - the New Design

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

Sorry,
I meant that the loop counts N+1 counts.
BR Mike

On 27.05.2015 18:58, Mikael Nordman wrote:
> in a simple for..next loop that has only one decrement and branch
> instruction, and that has an index that counts down to zero.
>
> In order the get the full 16 bit loop count you have to give as input
> the N+1 count.
>

Re: [Flashforth-devel] SPI FRAM and MRAM memory drivers

[om1zz <om...@vo...>]

Hi,
there is a new driver for magnetoresistive MRAM (Everspin) MR25H40, 512kBytes, 8pin.
Together with below FRAM (Ramtron, now Cypress) this is a great solution when you require a nonvolatile external 8pin SPI memory
with up to 40/50Mhz SPI clock and write such fast as read (no write delays like eeprom/flash, no page buffers).
Unlimited endurance.
Could be used as a standard SPI sram, but nonvolatile (no external backup battery needed).
Now we need a tiny filesystem written in forth :)
Igor

______________________________________________________________
> Od: "om1zz" <om...@vo...>
> Komu: "flashforth-devel" <fla...@li...>
> Datum: 26.05.2015 10:40
> Předmět: Re: [Flashforth-devel] SPI FRAM memory drivers
>
>Hi, much more optimized code there. WR/RD bytes, words, doubles and quads into/from FRAM, speeds up to 300kB/sec with quads at 27MHz Fcy. I may try with my magnetic MRAMs, but a microscope needed for the soldering job :)
>Igor
>
>______________________________________________________________
>> Od: om1zz <om...@vo...>
>> Komu: "flashforth-devel" <fla...@li...>
>> Datum: 24.05.2015 19:33
>> Předmět: [Flashforth-devel] SPI FRAM memory drivers
>>
>>Hi, at
>>https://github.com/igor-m/flashforth/tree/master/examples
>>are examples of SPI drivers for FRAM SPI memory (byte, word, double access) working with dspic33fjgp128/pic24 etc.
>>It is a quick hack to see how the stuff works, and it works.
>>Needs to be optimised a bit however, asm must be used where applicable in order to speed the stuff up. 
>>My memories are over 64kB so they have got 3 bytes long address. Currently there is a block number (64kB per block) and an address within 64kB. Mind you have to care about proper alignment as the address step is 1 or 2 or 4 for above types.
>>More in sources.
>>Igor.
>>
>>------------------------------------------------------------------------------
>>One dashboard for servers and applications across Physical-Virtual-Cloud 
>>Widest out-of-the-box monitoring support with 50+ applications
>>Performance metrics, stats and reports that give you Actionable Insights
>>Deep dive visibility with transaction tracing using APM Insight.
>>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>_______________________________________________
>>Flashforth-devel mailing list
>>Fla...@li...
>>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>

Re: [Flashforth-devel] For-next loops - the New Design

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

Yes, Yes,
I understand what you want.
But you dont seem to understand that it cannot be done
in a simple for..next loop that has only one decrement and branch 
instruction, and that has an index that counts down to zero.

In order the get the full 16 bit loop count you have to give as input 
the N+1 count.

But if you have some idea how to implement it in PIC assembly code,
please write it out.

BR Mike

On 27.05.2015 10:32, om1zz wrote:
> 0 _for 65535 65534 ..
> .. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> 65536 ok<#,ram>

Re: [Flashforth-devel] For-next loops - the New Design

[om1zz <om...@vo...>]

Mike,

-fortest
marker -fortest

2variable count
: _for 0. count 2! for count 2@ 1. d+ count 2! r@ u. next cr count 2@ ud. ; 
: _for2 0. count 2! for2 count 2@ 1. d+ count 2! r@ u. next cr count 2@ ud. ; 

FOR:
----------------------------
25 _for 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
25  ok<#,ram>

1 _for 0
1  ok<#,ram>

0 _for
0  ok<#,ram>

65535 _for 65534 65533 ..
.. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
65535  ok<#,ram>

FOR2:
___________________

25 _for2 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
26  ok<#,ram>

1 _for2 1 0
2  ok<#,ram>

0 _for2 0
1  ok<#,ram>

65535 _for2 65535 65534 ..
.. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
65536  ok<#,ram>

My comments:
It does not behave as it should (this is my personal point of view):
_for works as before, zero skips, not good
_for2 works not good, it means you do N+1 _for or something like that..

I strongly believe it should work as follows ("My Design"):
standard FOR-NEXT:
-------------------------------------------------

65535 _for 65534 65533 ..
.. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
65535  ok<#,ram>

25 _for 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
25  ok<#,ram>

1 _for 0
1  ok<#,ram>

0 _for 65535 65534 ..
.. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
65536 ok<#,ram>

?FOR-NEXT with zero skip:
--------------------------------------------------
65535 _?for 65534 65533 ..
.. 13 12 11 10 9 8 7 6 5 4 3 2 1 0
65535  ok<#,ram>

25 _?for 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
25  ok<#,ram>

1 _?for 0
1  ok<#,ram>

0 _?for
0  ok<#,ram>

IgorM


______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 26.05.2015 16:07
> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>
>I added printing of the index to your pseudocode.
>
>So     2 for r@ u. next
>prints  2 1
>
>And     0 for r@ u. next
>prints  0 65535 .... 1
>
>So will also your pseudocode below, but
>
>I want  65535 for r@ u. next
>prints  65535 .... 0
>
>This is what I have implemented in the FOR2
>You can pull it from git.
>
>BR Mike
>
>
>uint16 index;
>uint16 count = 0;
>
>index = 2;
>
>for_loop:
>
>blink_a_led;
>
>count = count + 1;
>
>print index;              <----------------NOTE
>
>/ / decrement and skip if zero test
>index = index  - 1;   /// decrement
>if index==0 goto out_of_loop // skip if zero
>// end of decrement and skip if zero test
>
>goto for_loop:   // this will be skipped when zero
>
>out_of_loop:
>
>print count;
>
>
>On 26.05.2015 13:28, om1zz wrote:
>> A loop with "decrement and skip if zero" construct in asm means condition evaluation and action around "next"-  like this (an example code):
>>
>> uint16 joe;
>> uint16 count = 0;
>>
>> joe = 2;
>>
>> for_loop:
>>
>> blink_a_led;
>>
>> count = count + 1;
>>
>> / / decrement and skip if zero test
>> joe = joe  - 1;   /// decrement
>> if joe==0 goto out_of_loop // skip if zero
>> // end of decrement and skip if zero test
>>
>> goto for_loop:   // this will be skipped when zero
>>
>> out_of_loop:
>>
>> print count;
>>
>> end
>>
>> With joe=2 the count will be 2, with joe=0 the count will be 65536.
>>
>> Igor
>>
>> ______________________________________________________________
>>> Od: Mikael Nordman <mik...@fl...>
>>> Komu: <fla...@li...>
>>> Datum: 26.05.2015 11:51
>>> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>>>
>>> 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).
>>>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>
>------------------------------------------------------------------------------
>One dashboard for servers and applications across Physical-Virtual-Cloud 
>Widest out-of-the-box monitoring support with 50+ applications
>Performance metrics, stats and reports that give you Actionable Insights
>Deep dive visibility with transaction tracing using APM Insight.
>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

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

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

I added printing of the index to your pseudocode.

So     2 for r@ u. next
prints  2 1

And     0 for r@ u. next
prints  0 65535 .... 1

So will also your pseudocode below, but

I want  65535 for r@ u. next
prints  65535 .... 0

This is what I have implemented in the FOR2
You can pull it from git.

BR Mike


uint16 index;
uint16 count = 0;

index = 2;

for_loop:

blink_a_led;

count = count + 1;

print index;              <----------------NOTE

/ / decrement and skip if zero test
index = index  - 1;   /// decrement
if index==0 goto out_of_loop // skip if zero
// end of decrement and skip if zero test

goto for_loop:   // this will be skipped when zero

out_of_loop:

print count;


On 26.05.2015 13:28, om1zz wrote:
> A loop with "decrement and skip if zero" construct in asm means condition evaluation and action around "next"-  like this (an example code):
>
> uint16 joe;
> uint16 count = 0;
>
> joe = 2;
>
> for_loop:
>
> blink_a_led;
>
> count = count + 1;
>
> / / decrement and skip if zero test
> joe = joe  - 1;   /// decrement
> if joe==0 goto out_of_loop // skip if zero
> // end of decrement and skip if zero test
>
> goto for_loop:   // this will be skipped when zero
>
> out_of_loop:
>
> print count;
>
> end
>
> With joe=2 the count will be 2, with joe=0 the count will be 65536.
>
> Igor
>
> ______________________________________________________________
>> Od: Mikael Nordman <mik...@fl...>
>> Komu: <fla...@li...>
>> Datum: 26.05.2015 11:51
>> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>>
>> 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).
>>>>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

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

[om1zz <om...@vo...>]

Hopefully other people here will provide their points too, and if it comes to voting at the end my suggestion (which comes from the assumption the FF primitives shall represent the primitive behavoiur of the assembler in the specific number range domain, here the 16bit type) is:

FOR

n FOR blink_led NEXT

n=65535 led blinks 65535x
n=25 led blnks 25x
n=1 led blinks 1x
n=0 led blinks 65536x

?FOR

n ?FOR blink_led NEXT

n=65535 led blinks 65535x
n=25 led blnks 25x
n=1 led blinks 1x
n=0 led does not blink

Igor
______________________________________________________________
> Od: om1zz <om...@vo...>
> Komu: <fla...@li...>
> Datum: 26.05.2015 13:12
> Předmět: Re: [Flashforth-devel]For-next loop - full 16bit count?
>
>corrected:
>uint16 joe;
>uint32 count = 0;
>...
>
>Your suggested scenario
>
>>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)
>
>is quite a novel approach, indeed, but not sure if it would be easy to understand by people like me :)
>
>Igor
>
>______________________________________________________________
>> Od: "om1zz" <om...@vo...>
>> Komu: <fla...@li...>
>> Datum: 26.05.2015 12:28
>> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>>
>>A loop with "decrement and skip if zero" construct in asm means condition evaluation and action around "next"-  like this (an example code):
>>
>>uint16 joe;
>>uint16 count = 0;
>>
>>joe = 2;
>>
>>for_loop:  
>>
>>blink_a_led;
>>
>>count = count + 1;
>>
>>/ / decrement and skip if zero test
>>joe = joe  - 1;   /// decrement
>>if joe==0 goto out_of_loop // skip if zero
>>// end of decrement and skip if zero test
>>
>>goto for_loop:   // this will be skipped when zero
>>
>>out_of_loop:
>>
>>print count;
>>
>>end
>>
>>With joe=2 the count will be 2, with joe=0 the count will be 65536.
>>
>>Igor
>>
>>______________________________________________________________
>>> Od: Mikael Nordman <mik...@fl...>
>>> Komu: <fla...@li...>
>>> Datum: 26.05.2015 11:51
>>> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>>>
>>>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).
>>>>>>
>>>
>>>
>>>------------------------------------------------------------------------------
>>>One dashboard for servers and applications across Physical-Virtual-Cloud 
>>>Widest out-of-the-box monitoring support with 50+ applications
>>>Performance metrics, stats and reports that give you Actionable Insights
>>>Deep dive visibility with transaction tracing using APM Insight.
>>>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>_______________________________________________
>>>Flashforth-devel mailing list
>>>Fla...@li...
>>>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>
>>
>
>------------------------------------------------------------------------------
>One dashboard for servers and applications across Physical-Virtual-Cloud 
>Widest out-of-the-box monitoring support with 50+ applications
>Performance metrics, stats and reports that give you Actionable Insights
>Deep dive visibility with transaction tracing using APM Insight.
>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

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

[om1zz <om...@vo...>]

corrected:
uint16 joe;
uint32 count = 0;
...

Your suggested scenario

>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)

is quite a novel approach, indeed, but not sure if it would be easy to understand by people like me :)

Igor

______________________________________________________________
> Od: "om1zz" <om...@vo...>
> Komu: <fla...@li...>
> Datum: 26.05.2015 12:28
> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>
>A loop with "decrement and skip if zero" construct in asm means condition evaluation and action around "next"-  like this (an example code):
>
>uint16 joe;
>uint16 count = 0;
>
>joe = 2;
>
>for_loop:  
>
>blink_a_led;
>
>count = count + 1;
>
>/ / decrement and skip if zero test
>joe = joe  - 1;   /// decrement
>if joe==0 goto out_of_loop // skip if zero
>// end of decrement and skip if zero test
>
>goto for_loop:   // this will be skipped when zero
>
>out_of_loop:
>
>print count;
>
>end
>
>With joe=2 the count will be 2, with joe=0 the count will be 65536.
>
>Igor
>
>______________________________________________________________
>> Od: Mikael Nordman <mik...@fl...>
>> Komu: <fla...@li...>
>> Datum: 26.05.2015 11:51
>> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>>
>>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).
>>>>>
>>
>>
>>------------------------------------------------------------------------------
>>One dashboard for servers and applications across Physical-Virtual-Cloud 
>>Widest out-of-the-box monitoring support with 50+ applications
>>Performance metrics, stats and reports that give you Actionable Insights
>>Deep dive visibility with transaction tracing using APM Insight.
>>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>_______________________________________________
>>Flashforth-devel mailing list
>>Fla...@li...
>>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>

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

[om1zz <om...@vo...>]

A loop with "decrement and skip if zero" construct in asm means condition evaluation and action around "next"-  like this (an example code):

uint16 joe;
uint16 count = 0;

joe = 2;

for_loop:  

blink_a_led;

count = count + 1;

/ / decrement and skip if zero test
joe = joe  - 1;   /// decrement
if joe==0 goto out_of_loop // skip if zero
// end of decrement and skip if zero test

goto for_loop:   // this will be skipped when zero

out_of_loop:

print count;

end

With joe=2 the count will be 2, with joe=0 the count will be 65536.

Igor

______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 26.05.2015 11:51
> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>
>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).
>>>>
>
>
>------------------------------------------------------------------------------
>One dashboard for servers and applications across Physical-Virtual-Cloud 
>Widest out-of-the-box monitoring support with 50+ applications
>Performance metrics, stats and reports that give you Actionable Insights
>Deep dive visibility with transaction tracing using APM Insight.
>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

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).
>>>

Re: [Flashforth-devel] SPI FRAM memory drivers

[om1zz <om...@vo...>]

Hi, much more optimized code there. WR/RD bytes, words, doubles and quads into/from FRAM, speeds up to 300kB/sec with quads at 27MHz Fcy. I may try with my magnetic MRAMs, but a microscope needed for the soldering job :)
Igor

______________________________________________________________
> Od: om1zz <om...@vo...>
> Komu: "flashforth-devel" <fla...@li...>
> Datum: 24.05.2015 19:33
> Předmět: [Flashforth-devel] SPI FRAM memory drivers
>
>Hi, at
>https://github.com/igor-m/flashforth/tree/master/examples
>are examples of SPI drivers for FRAM SPI memory (byte, word, double access) working with dspic33fjgp128/pic24 etc.
>It is a quick hack to see how the stuff works, and it works.
>Needs to be optimised a bit however, asm must be used where applicable in order to speed the stuff up. 
>My memories are over 64kB so they have got 3 bytes long address. Currently there is a block number (64kB per block) and an address within 64kB. Mind you have to care about proper alignment as the address step is 1 or 2 or 4 for above types.
>More in sources.
>Igor.
>
>------------------------------------------------------------------------------
>One dashboard for servers and applications across Physical-Virtual-Cloud 
>Widest out-of-the-box monitoring support with 50+ applications
>Performance metrics, stats and reports that give you Actionable Insights
>Deep dive visibility with transaction tracing using APM Insight.
>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

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

[om1zz <om...@vo...>]

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).
>>
>>------------------------------------------------------------------------------
>>One dashboard for servers and applications across Physical-Virtual-Cloud 
>>Widest out-of-the-box monitoring support with 50+ applications
>>Performance metrics, stats and reports that give you Actionable Insights
>>Deep dive visibility with transaction tracing using APM Insight.
>>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>_______________________________________________
>>Flashforth-devel mailing list
>>Fla...@li...
>>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>

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

[om1zz <om...@vo...>]

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).
>
>------------------------------------------------------------------------------
>One dashboard for servers and applications across Physical-Virtual-Cloud 
>Widest out-of-the-box monitoring support with 50+ applications
>Performance metrics, stats and reports that give you Actionable Insights
>Deep dive visibility with transaction tracing using APM Insight.
>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

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

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

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).

[Flashforth-devel] SPI FRAM memory drivers

[om1zz <om...@vo...>]

Hi, at
https://github.com/igor-m/flashforth/tree/master/examples
are examples of SPI drivers for FRAM SPI memory (byte, word, double access) working with dspic33fjgp128/pic24 etc.
It is a quick hack to see how the stuff works, and it works.
Needs to be optimised a bit however, asm must be used where applicable in order to speed the stuff up. 
My memories are over 64kB so they have got 3 bytes long address. Currently there is a block number (64kB per block) and an address within 64kB. Mind you have to care about proper alignment as the address step is 1 or 2 or 4 for above types.
More in sources.
Igor.

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

[om1zz <om...@vo...>]

Another Q: would it possible to implement for example a dfor-next loop with double index??
I.

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

[om1zz <om...@vo...>]

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).

Or to have for..next 16bit and mfor..next with less bits (like an 8bitter mcu processing 255 data values only) :)
I.


______________________________________________________________
> Od: Mikael Nordman <mik...@fl...>
> Komu: <fla...@li...>
> Datum: 24.05.2015 12:39
> Předmět: Re: [Flashforth-devel] For-next loop - full 16bit count?
>
>Yep,
>You are right. next works bu decrementing the index and checking for
>carry when the index goes from 0 to 65535.
>
>The 0 for..next loops zero times.
>The 2 for..next loops two times. index values are 1 and 0
>65535 for..next loops 65535 times. Index goes from 65534 to 0
>
>for..next was designed to check for the  zero count and not loop in case 
>the count is zero. This is very useful in all cases except if
>you want to loop the full 65536 times.
>
>BR Mike
>
>On 24.05.2015 13:06, om1zz wrote:
>> Hmm, while messing with an external memory I need to count over entire unsigned 16bit for-loop range (to work with a block of 65536 data).
>>
>> When doing
>>
>> 65535 for ... next
>>
>> I get 65535 counts ( 65534..0), but I miss 65535th :)
>>
>> I've tried
>>
>> 0 for ... next
>>
>> but that does not loop. I think with zero input it should count over $ffff down to zero to get the full 16bit scope..
>
>------------------------------------------------------------------------------
>One dashboard for servers and applications across Physical-Virtual-Cloud 
>Widest out-of-the-box monitoring support with 50+ applications
>Performance metrics, stats and reports that give you Actionable Insights
>Deep dive visibility with transaction tracing using APM Insight.
>http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>_______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
>https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>