Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-08-31 10:10, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> In "cmove>", the symbol ">" is just a hint for "from higher addresses to
>>> lower addresses", but it's very *confused*. Since ">" can also mean the
>>> normal direction from left to right (and then, from lower to higher
>>> addresses).
>>
>> Note the pronounciation: "c-move-up". It means: cmove the memory
>> block from lower to higher addresses; i.e., the name describes the
>> usage (what), not the how.
>[...]
>
>It's unconvincing. It seems to me that "from lower to higher addresses"
>is about "how".

The "how" for CMOVE> is to process the character with the highest
address first, the one with the lowest addess last. So I would call
the "how" for CMOVE> "from high to low addresses".

>Also, there is a word "cmove" with pronunciation "c-move", without "up",
>that actually moves "from lower to higher addresses".

It processes the character with the lower address first. If you use
it for moving to an overlapping address range with a higher address,
you don't get a copy of the original.

>In anyway, the intention was that ">" is pronounced as "up" in this
>case. Perhaps, it means "move to upper addresses"?

That's what I was trying to express.

>https://www.complang.tuwien.ac.at/forth/fth79std/FORTH-79.TXT
....
>> The idea that I have read was that you would write the defining word
>> like:
>>
>> : const <builds , does> @ ;
>
>In Forth-79 the both ways already were available — via "<builds" (like
>above), and via "create":
>
> : const create , does> @ ;
>
>What was a different is unclear.

<BUILDS is an uncontrolled word in Forth-79, and it can do anything.
Note that DOES> only mentions usage with CREATE.

A system might implement <BUILDS as

: <BUILDS CREATE ;

or it might implement it in the old way (with an additional cell in
the defined word); how DOES> works in the latter case is an
interesting question.

Or the system might not implement <BUILDS at all.

>> So <BUILDS points to the name of the new defining word, while DOES>
>> points to the code executed when the defined word runs.
>
>
>I don't see how "<" in "<BUILDS" says that this word points to the name
>of the new definition.

In the example above < points to CONST.

>I would not encourage such usage of ">", and would suggest something
>more contrast like "==>" instead (if any).

These days, I suggest passing an xt instead of using return-address
manipulation, and use a quotation if you want the xt inline.

- 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 Tuesday, August 31, 2021 at 7:30:46 AM UTC-5, Ruvim wrote:
> I would not encourage such usage of ">", and would suggest something
> more contrast like "==>" instead (if any).

Punctuation in word names has little merit. I'm sure you have
noted that I use BUILD DOES as oppose to <BUILDS DOES> . The brackets
don't provide any _vital_ meaning and is problematic in providing a
consistent meaning as testified by this thread.

It also makes text descriptions difficult because punctuation in names
conflicts with how punctuation is used in text and it can be also be
devastating if the host OS or communications gets a hold of them.

Note that assembly code does not use punctuation in symbols for
good reason, all the above said problems.

Dropping unneeded punctuation from word names IMHO would be a step
in the right direction.

--
me

"In 2525 if programmers are still alive,
Forth has just one word and it's KOO"

Bernd Linsel <bl1-removethis@gmx.com> writes:
>On 31.08.2021 09:10, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>
>> Note the pronounciation: "c-move-up". It means: cmove the memory
>> block from lower to higher addresses; i.e., the name describes the
>> usage (what), not the how. The how is overspecified for the
>> application, though. Fortunately, we have MOVE now, making both CMOVE
>> and CMOVE> unnecessary.
>>
>
>And, unfortunately, introducing a run-time decision for the rare case
>that source and destination memory areas overlap.
>
>One strength of Forth (and one "10x" of C. Moore's "1000x") is the
>ability to do at editing time what can be done at editing time, i.e. if
>you know that source and destination do not overlap (or if dest overlaps
>the lower source), you use the simpler CMOVE, if dest overlaps upper
>part of source, use the equally simple (but cache-unfriendly) CMOVE>.

CMOVE> is not significantly less cache-friendly than CMOVE. The
problem with both is that for the problem you are suggesting them for,
they are overspecified, and, if you don't introduce a run-time
decision for the overlap case, they are slow. If you introduce a
run-time decision for the overlap case, there is no advantage over
MOVE.

Let's get numbers for this, using the following benchmark:

50 constant bufsize
create a bufsize allot
create b bufsize allot
a bufsize 'a' fill
: bench-move 100000000 0 do a b bufsize move loop ;
: bench-cmove 100000000 0 do a b bufsize cmove loop ;
: bench-cmove> 100000000 0 do a b bufsize cmove> loop ;

Cycles per iteration on a Skylake (Core i5-6600K)
sf vfx gf lxf
95 34 36 32 bench-move
100 32 87 32 bench-cmove
83 33 90 219 bench-cmove>

sf (SwiftForth 3.11) has a pretty straightforward implementation: MOVE
either calls CMOVE or CMOVE>, and CMOVE and CMOVE> contain a simple
loop that copies a byte at a time.

For vfx (VFX Forth for Linux IA32 Version: 4.72), the implemenations
of the three words are much longer:

bytes
124 move
96 cmove
118 cmove>

MOVE does not call CMOVE or CMOVE>, so the editing-time advice costs
quite a bit of memory and buys hardly any speed on VFX.

In gf (Gforth 0.7.9_20210826), MOVE calls memmove() (from glibc 2.19
in this case), while CMOVE and CMOVE> are byte-by-byte copies, like on
SwiftForth, resulting in simular performance.

In lxf, I don't see how MOVE is implemented. CMOVE uses REP MOVSB
(which seems to be doing ok in this case, somewhat to my surprise);
CMOVE> also uses REP MOVSB (with a different setup) , which performs
worse than even I would have expected.

Bottom line: MOVE can be fast. And if you want CMOVE and CMOVE> to be
fast, you need to make them so complicated that their combination is
more complicated than MOVE.

>Still better, alignment would have to be taken into account, in order to
>move word-sized (or SIMD-packet-sized) quantities if appropriate.
>Admittedly, this would lead to an explosion of similar words, each for
>itself with very limited use.

And very limited benefit. See
<2017Sep23.174313@mips.complang.tuwien.ac.at>

>Still, in C the programmer is
>bound to provide information, whether he/she intends to avoid trashing
>of the source area (by either calling memcpy or memmove).

No, th difference (as interpreted by the current implementors of C) is
that memcpy guarantees that there is no overlap. Just use memmove,
and forget memcpy.

- 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 31.08.2021 18:43, Anton Ertl wrote:
> Bernd Linsel <bl1-removethis@gmx.com> writes:
>
> CMOVE> is not significantly less cache-friendly than CMOVE. The
> problem with both is that for the problem you are suggesting them for,
> they are overspecified, and, if you don't introduce a run-time
> decision for the overlap case, they are slow. If you introduce a
> run-time decision for the overlap case, there is no advantage over
> MOVE.
>
> Let's get numbers for this, using the following benchmark:
>
> 50 constant bufsize
> create a bufsize allot
> create b bufsize allot
> a bufsize 'a' fill
> : bench-move 100000000 0 do a b bufsize move loop ;
> : bench-cmove 100000000 0 do a b bufsize cmove loop ;
> : bench-cmove> 100000000 0 do a b bufsize cmove> loop ;
>
> Cycles per iteration on a Skylake (Core i5-6600K)
> sf vfx gf lxf
> 95 34 36 32 bench-move
> 100 32 87 32 bench-cmove
> 83 33 90 219 bench-cmove>
>
> sf (SwiftForth 3.11) has a pretty straightforward implementation: MOVE
> either calls CMOVE or CMOVE>, and CMOVE and CMOVE> contain a simple
> loop that copies a byte at a time.
>
> For vfx (VFX Forth for Linux IA32 Version: 4.72), the implemenations
> of the three words are much longer:
>
> bytes
> 124 move
> 96 cmove
> 118 cmove>
>
> MOVE does not call CMOVE or CMOVE>, so the editing-time advice costs
> quite a bit of memory and buys hardly any speed on VFX.
>
> In gf (Gforth 0.7.9_20210826), MOVE calls memmove() (from glibc 2.19
> in this case), while CMOVE and CMOVE> are byte-by-byte copies, like on
> SwiftForth, resulting in simular performance.
>
> In lxf, I don't see how MOVE is implemented. CMOVE uses REP MOVSB
> (which seems to be doing ok in this case, somewhat to my surprise);
> CMOVE> also uses REP MOVSB (with a different setup) , which performs
> worse than even I would have expected.

REP MOVSB with CLD is optimized by today's processors so that it even
moves whole cache lines in ideal cases, so nowadays it's okay to use it
(again -- after nearly two decades of deprecation).

It is documented that Core-i up to and including Broadwell and all AMD
cores preceding Zen2 do not bundle REP MOVSx when the direction flag is set.
I'm sorry, but I don't have the appropriate information available for
newer architectures. Obviously, it seems to be valid for your Core i5 as
well.

>
> Bottom line: MOVE can be fast. And if you want CMOVE and CMOVE> to be
> fast, you need to make them so complicated that their combination is
> more complicated than MOVE.
>
>
> And very limited benefit. See
> <2017Sep23.174313@mips.complang.tuwien.ac.at>
>
>
> No, th difference (as interpreted by the current implementors of C) is
> that memcpy guarantees that there is no overlap. Just use memmove,
> and forget memcpy.

This results just from using memcpy on overlapped regions being UB while
for memmove it is perfectly defined.
If you force clang or gcc into using library code (-fno-builtin-memcpy,
-fno-builtin-memmove) you can see that memmove, in contrast to memcpy,
starts with a check if dest-start is within the bounds [src-start,
src-start + length) and branches to a backwards copy if yes.

However, the C standards folks .oO(#&$!) have their problems with
memcpy/memmove and the like, because they can be used to achieve things
that were UB, when implemented straightforward...

>
> - anton
>

On 2021-08-31 10:10, Anton Ertl wrote:
[...]
> Stepen Pelc found the following code in the wild
> <4ffffe5e.117344919@192.168.0.50> (AFAIK Bernd Paysan used to use such
> words):
>
> \ VFX-specific
> : list> ( thread -- element )
> BEGIN @ dup WHILE dup r@ execute
> REPEAT drop r> drop ;
>
> which is used like
>
> : foo bar list> bla blub ;
>
> A list is passed to LIST>, which then executes the "bla blub" part
> repeatedly, once for every list element.
> A more modern (and more flexible and soon-standard)
> approach is to put "bla blub" inside a quotation
> and call that with EXECUTE for each list element.

Yes, it's more flexible but sometime it's less convenient.

I thought about this problem before. Why not throw out our conventional
control flow structures for choices and loops and just use the
quotation-based approach? Factor and some other languages go by this way.

A source code can look like the following:

[: foo bar ;] 10 times

flag [: 1 . ;] [: 0 . ;] ifelse

[: buz flag ;] while

Among other advantages, the quotation-bases control flow can be used
interpretively.

So why not go with this way only? A problem with this way is that it
produces worse readability. Have a look.

Let's take the example of BacFORTH-based nested iteration over two lists
(from my previous message):

: foo bar list=> bluh buz list=> blub ;

Using the quotation-based approach this word "foo" will look as:

: foo [: bluh [: blub ;] buz list:forearch ;] bar list:forearch ;

\ where
\ list:forearch ( i*x xt list -- j*x ) \ xt ( i*x item -- j*x )

It's obvious what the variant is better readable, I think.

A similar picture we will have with nested loops, choices, etc. The more
complex structures, the less readable a quotation-based solution will be.

Yes, when an xt is passed to us, it's more convenient to just apply an
iterator to this xt. And when we have an iterator that accepts an xt,
it's usually more convenient to pass a quotation to it, than create a
separate definition.

But if we have both - an iterator that accepts an xt, and a
corresponding structure that wraps a code, it's easier to use this
structure with our regular code, than the iterator with our code in a
quotation.

Both a quotation and a special structure wraps a fragment of source
code. But the quotation doesn't provide any specific information for the
reader, while the special structure provide some additional information,
and therefore it produces better readability.

There is such a conception as dichotomy of form and content, or markup
and content, in our case of source codes. So we can conditionally
attribute a word to markup or to content.

[: ... ;] -- is a markup.
begin ... while ... repeat -- is a markup too.

The latter markup brings more semantics information for the reader, and
therefore it can be read easier.

Going back to the BacFORTH-based example:

: foo bar list=> bluh buz list=> blub ;

A problem with this markup is that the end of structure is not marked
explicitly.

A better markup can look as following:

: foo bar list:each{ bluh buz list:each{ blub } } ;

Even better to have optional explicit endings:

: foo bar list:each{ bluh buz list:each{ blub }list:each }list:each ;

that make sense on nesting different structures.

(Concerning curly brackets - we can use other symbols instead, it
doesn't matter)

One more step deeper.
An iterator and a structure can be defined one via another.

Take a look, the word "list:each" via the "list:each{ ... }" structure
can be defined as:

: list:each ( xt list -- )
list:each{ ( i*x item xt -- j*x xt )
dup >r execute r>
} drop
;

And vise versa:

: list:each{ \ run-time: ( i*x list -- j*x )
\ wrapped-code ( i*x item -- j*x )
postpone [: end{ postpone list:each }
; immediate

This variant cannot be used interpretively, but this problem is
solvable. Actually, I prefer an implementations with active parsing for
such structures, but I need a recognizers API for that (for nesting the
Forth text interpreter).

Well, we can go even deeper.
We can provide a word "list:each" to the system, and the corresponding
structure will be available for us *automatically*, via a general
recognizer for such cases (e.g., for curly brackets).

Bottom line: we haven't to choose one from these approaches, we can use
them all - iterators and structures. For the conventional control flow
structures the corresponding higher order functions are very useful
sometimes too.

--
Ruvim

On Tuesday, August 31, 2021 at 12:47:22 AM UTC-7, Anton Ertl wrote:
> Still, people have used > to end other return-address-using words;
> e.g., Stepen Pelc found the following code in the wild
> <4ffffe5e....@192.168.0.50> (AFAIK Bernd Paysan used to use such
> words):
>
> \ VFX-specific
> : list> ( thread -- element )
> BEGIN @ dup WHILE dup r@ execute
> REPEAT drop r> drop ;
>
> which is used like
>
> : foo bar list> bla blub ;
>
> A list is passed to LIST>, which then executes the "bla blub" part
> repeatedly, once for every list element. A more modern (and more
> flexible and soon-standard) approach is to put "bla blub" inside a
> quotation and call that with EXECUTE for each list element.
>
> So > at the end of the word has become a general indication that the
> rest of the word is treated as separate definition.

This is crap code.
1.) The first node in the list never gets processed because the @ of the next-node
is done in the front.
2.) The pointer to the next-node after the node being processed is not obtained
prior to processing the node. So, if the node's link field gets modified (for example,
zero'd out if the node is moved to a new list), The @ will not get the next-node.
3.) The pointer to the node being processed is on the data-stack during the processing
of the node, so the processing code can't access the data on the data-stack that it
needs to access to communicate with the parent function.

I think Stephen Pelc was impressed by the trickiness of the function, that it
executes the "bla blub" code --- Stephen Pelc had no intention of ever actually
using his tricky little bug-ridden function, so he didn't notice the bugs.

I don't think that Stephen Pelc understands the concept of general-purpose
data-structures --- Peter Knaggs doesn't either, and Stephen Pelc described
Peter Knaggs as MPE's tool-builder --- it is pathetic that the Forth-200x
committee continue to fail to implement a linked-list --- a linked-list is pretty easy.
https://groups.google.com/g/comp.lang.forth/c/cMa8wV3OiY0/m/INBDVBh0BgAJ

Here is code that works:
-------------------------------------------------------------
\ ******
\ ****** some rquotation code
\ ******

VFX? SwiftForth? or [if] \ these don't work with HumptyDumpty's code because these HOFs have locals of their own.

\ These are for use with REX and rquotations. The | prefix is the naming convention for anything that uses quotations.
\ I am getting rid of that "toucher" term and replacing it with "quotation."

\ In VFX it is okay to use REX on an xt or use EXECUTE on an rq --- so these can be used for everything --- but this doesn't work on SwiftForth.
\ On SwiftForth you can only use REX on an rq and EXECUTE on an xt --- so you have to use both kinds of HOF as appropriate.

: |each ( i*x head rq -- j*x ) \ quotation: i*x node -- j*x
{ rq | next -- }
begin ?dup while \ -- node
dup .fore @ to next
rq rex
next repeat ;

: |find-node ( i*x head rq -- j*x node|false ) \ quotation: i*x node -- j*x flag
{ node rq | next -- node|false }
begin node while
node .fore @ to next
node rq rex if node exit then
next to node repeat
false ;

: |find-prior ( i*x head rq -- j*x -1|node|false ) \ quotation: i*x node -- j*x flag
-1 { node rq prior | next -- prior|false } \ prior is -1, meaning found node was the head
begin node while
node .fore @ to next
node rq rex if prior exit then
node to prior next to node repeat
false ;

[then]
-------------------------------------------------------------

On 1/09/2021 02:43, Anton Ertl wrote:
> Bernd Linsel <bl1-removethis@gmx.com> writes:
>> ...
>>And, unfortunately, introducing a run-time decision for the rare case
>>that source and destination memory areas overlap.
> ...
> MOVE does not call CMOVE or CMOVE>, so the editing-time advice costs
> quite a bit of memory and buys hardly any speed on VFX.
> ...
> Bottom line: MOVE can be fast. And if you want CMOVE and CMOVE> to be
> fast, you need to make them so complicated that their combination is
> more complicated than MOVE.

MOVE may be faster since unlike CMOVE CMOVE> it's not required to propagate.
Anyone that cares about speed is likely to implement the former in asm
anyway assuming no optimizer.

The only purpose of the propagation rule seems to have been this from
Fig-Forth:

1 : FILL ( FILL MEMORY BEGIN-3, QUAN-2, BYTE-1 *)
2 SWAP >R OVER C! DUP 1+ R> 1 - CMOVE ;

Nor did every Fig-Forth bother e.g. 8080 Fig did it in asm.

VFX CMOVE has been moving cells contrary to ANS for many years apparently
without issue. I went the same route for my 8086 forth and never looked
back. On that system all moves down are done in cells; only CMOVE> moves
bytes. Consequently I preference CMOVE. That said, moving a few bytes is
never going to be efficient.

On Tuesday, 31 August 2021 at 19:53:57 UTC+2, Anton Ertl wrote:
> Bernd Linsel <bl1-rem...@gmx.com> writes:
> >On 31.08.2021 09:10, Anton Ertl wrote:
> >> Ruvim <ruvim...@gmail.com> writes:
> >>
> >> Note the pronounciation: "c-move-up". It means: cmove the memory
> >> block from lower to higher addresses; i.e., the name describes the
> >> usage (what), not the how. The how is overspecified for the
> >> application, though. Fortunately, we have MOVE now, making both CMOVE
> >> and CMOVE> unnecessary.
> >>
> >
> >And, unfortunately, introducing a run-time decision for the rare case
> >that source and destination memory areas overlap.
> >
> >One strength of Forth (and one "10x" of C. Moore's "1000x") is the
> >ability to do at editing time what can be done at editing time, i.e. if
> >you know that source and destination do not overlap (or if dest overlaps
> >the lower source), you use the simpler CMOVE, if dest overlaps upper
> >part of source, use the equally simple (but cache-unfriendly) CMOVE>.
> CMOVE> is not significantly less cache-friendly than CMOVE. The
> problem with both is that for the problem you are suggesting them for,
> they are overspecified, and, if you don't introduce a run-time
> decision for the overlap case, they are slow. If you introduce a
> run-time decision for the overlap case, there is no advantage over
> MOVE.
>
> Let's get numbers for this, using the following benchmark:
>
> 50 constant bufsize
> create a bufsize allot
> create b bufsize allot
> a bufsize 'a' fill
> : bench-move 100000000 0 do a b bufsize move loop ;
> : bench-cmove 100000000 0 do a b bufsize cmove loop ;
> : bench-cmove> 100000000 0 do a b bufsize cmove> loop ;
>
> Cycles per iteration on a Skylake (Core i5-6600K)
> sf vfx gf lxf
> 95 34 36 32 bench-move
> 100 32 87 32 bench-cmove
> 83 33 90 219 bench-cmove>
>
> sf (SwiftForth 3.11) has a pretty straightforward implementation: MOVE
> either calls CMOVE or CMOVE>, and CMOVE and CMOVE> contain a simple
> loop that copies a byte at a time.
>
> For vfx (VFX Forth for Linux IA32 Version: 4.72), the implemenations
> of the three words are much longer:
>
> bytes
> 124 move
> 96 cmove
> 118 cmove>
>
> MOVE does not call CMOVE or CMOVE>, so the editing-time advice costs
> quite a bit of memory and buys hardly any speed on VFX.
>
> In gf (Gforth 0.7.9_20210826), MOVE calls memmove() (from glibc 2.19
> in this case), while CMOVE and CMOVE> are byte-by-byte copies, like on
> SwiftForth, resulting in simular performance.
>
> In lxf, I don't see how MOVE is implemented. CMOVE uses REP MOVSB
> (which seems to be doing ok in this case, somewhat to my surprise);
> CMOVE> also uses REP MOVSB (with a different setup) , which performs
> worse than even I would have expected.

In lxf if all parameters are known at compile tile, like in this case, MOVE
tests and chooses the appropriate of cmove and cmove> that are compiled
inline. in this case your bench-move and bench-cmove produces the same code.
If the parameters are not known at compile time a move that does the test
at runtime is compiled.

cmove> also uses the reps movsb but needs to setup the start addresses and direction
flag. Lokking at the results it is clear that Intel forget to improve the down direction
when they improved rep movsb

Peter

> Bottom line: MOVE can be fast. And if you want CMOVE and CMOVE> to be
> fast, you need to make them so complicated that their combination is
> more complicated than MOVE.
> >Still better, alignment would have to be taken into account, in order to
> >move word-sized (or SIMD-packet-sized) quantities if appropriate.
> >Admittedly, this would lead to an explosion of similar words, each for
> >itself with very limited use.
> And very limited benefit. See
> <2017Sep2...@mips.complang.tuwien.ac.at>
> >Still, in C the programmer is
> >bound to provide information, whether he/she intends to avoid trashing
> >of the source area (by either calling memcpy or memmove).
> No, th difference (as interpreted by the current implementors of C) is
> that memcpy guarantees that there is no overlap. Just use memmove,
> and forget memcpy.
> - 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

dxforth <dxforth@gmail.com> writes:
>VFX CMOVE has been moving cells contrary to ANS for many years apparently
>without issue.

As far as I can tell, VFX sticks to the standard requirements for
CMOVE. E.g.,

: myfill SWAP >R OVER C! DUP 1+ R> 1 - CMOVE ;
pad 16 'b' fill
pad 16 dump \ output:
08BB:6480 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 bbbbbbbbbbbbbbbb

Looking at the output of SEE CMOVE, I see a loop that moves cells, and
two loops that move bytes. I have not analyzed the control flow
between the loops completely, but it looks like VFX CMOVE is using two
comparisons and conditional branches to check whether the to address
is in the from range, and if it is, select the second byte loop.

- 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

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>dxforth <dxforth@gmail.com> writes:
>>VFX CMOVE has been moving cells contrary to ANS for many years apparently
>>without issue.
>
>As far as I can tell, VFX sticks to the standard requirements for
>CMOVE. E.g.,
>
>: myfill SWAP >R OVER C! DUP 1+ R> 1 - CMOVE ;
>pad 16 'b' fill
>pad 16 dump \ output:
>08BB:6480 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 bbbbbbbbbbbbbbbb

This does not prove anything. Here's the proper test:

pad 16 'b' myfill
pad 16 dump \ output:
08BB:6480 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 bbbbbbbbbbbbbbbb

(and yes, I filled pad with something else in between).

- 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 1/09/2021 17:44, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>VFX CMOVE has been moving cells contrary to ANS for many years apparently
>>without issue.
>
> As far as I can tell, VFX sticks to the standard requirements for
> CMOVE. E.g.,
>
> : myfill SWAP >R OVER C! DUP 1+ R> 1 - CMOVE ;
> pad 16 'b' fill
> pad 16 dump \ output:
> 08BB:6480 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 62 bbbbbbbbbbbbbbbb
>
> Looking at the output of SEE CMOVE, I see a loop that moves cells, and
> two loops that move bytes. I have not analyzed the control flow
> between the loops completely, but it looks like VFX CMOVE is using two
> comparisons and conditional branches to check whether the to address
> is in the from range, and if it is, select the second byte loop.

Spotted this in the change notes:

20131212 SFP011 Added overlap checks to CMOVE and CMOVE>.
On overlap, always use a byte by byte copy.

On 31 Aug 2021 at 18:43:41 CEST, "Anton Ertl" <Anton Ertl> wrote:
>
> For vfx (VFX Forth for Linux IA32 Version: 4.72), the implemenations
> of the three words are much longer:
>
> bytes
> 124 move
> 96 cmove
> 118 cmove>

That's an artefact of x86 32 bit coding. Writing the fastest possible CMOVE
is laborious. For x86_64/x64 the situation is different as most CPUs have
heavily optimised implementations of REP MOVSB. See Agner Fog et al.

For ARM32, a fast CMOVE has to account for the alignment of the
source and destination addresses as well as the length. By measurement,
the "vast but fast" implementation takes 950 bytes, but is 5 times faster
on average than a simplistic CMOVE. I have not tested ARM64 yet.

Stephen

Stephen Pelc <stephen@vfxforth.com> writes:
>On 31 Aug 2021 at 18:43:41 CEST, "Anton Ertl" <Anton Ertl> wrote:
>>
>> For vfx (VFX Forth for Linux IA32 Version: 4.72), the implemenations
>> of the three words are much longer:
>>
>> bytes
>> 124 move
>> 96 cmove
>> 118 cmove>
>
>That's an artefact of x86 32 bit coding. Writing the fastest possible CMOVE
>is laborious. For x86_64/x64 the situation is different as most CPUs have
>heavily optimised implementations of REP MOVSB. See Agner Fog et al.

For some interpretation of "most CPUs". Here's a Xeon X3460 (Nehalem,
from around 2009) I use every day, and a Ryzen 5800X (Zen 3, from
2021):

cycles/iteration
Nehalem Zen 3
vfx64 vfx32 vfx64 vfx32
212 53 232 24 bench-move
120 48 27 21 bench-cmove
201 45 224 21 bench-cmove>

So, REP MOVSB as used in CMOVE is indeed doing ok on the Zen 3, but it
seems that MOVE goes for CMOVE> in the benchmarked case, and REP MOVSB
as used in CMOVE> is slow on both of these CPUs. It's better to only
go for CMOVE> if the to address is in the from range; you can check
for this efficiently with

to from - u u< if from to u cmove> else from to u cmove then

An additional advantage is that the IF is very predictable (overlap is
very rare), whereas the above-or-below test is less predictable.

The code size has benefitted quite a bit from switching to REP MOVSB:

bytes
80 move
36 cmove
48 cmove>

- 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 2021-08-31 19:12, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-08-31 10:10, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>> In "cmove>", the symbol ">" is just a hint for "from higher addresses to
>>>> lower addresses", but it's very *confused*. Since ">" can also mean the
>>>> normal direction from left to right (and then, from lower to higher
>>>> addresses).
>>>
>>> Note the pronounciation: "c-move-up". It means: cmove the memory
>>> block from lower to higher addresses; i.e., the name describes the
>>> usage (what), not the how.
>> The how is overspecified for the application, though.
>> [...]
>>
>> It's unconvincing. It seems to me that "from lower to higher addresses"
>> is about "how".
>
> The "how" for CMOVE> is to process the character with the highest
> address first, the one with the lowest addess last. So I would call
> the "how" for CMOVE> "from high to low addresses".
>
>> Also, there is a word "cmove" with pronunciation "c-move", without "up",
>> that actually moves "from lower to higher addresses".
>
> It processes the character with the lower address first. If you use
> it for moving to an overlapping address range with a higher address,
> you don't get a copy of the original.
>
>> In anyway, the intention was that ">" is pronounced as "up" in this
>> case. Perhaps, it means "move to upper addresses"?
>
> That's what I was trying to express.

Oh, I see.

The wording "from lower to higher addresses" is almost the same as in
the specification of how "cmove" works: "proceeding
character-by-character from lower addresses to higher addresses"

A problem with this etymology for "cmove>" is that it *can* be actually
used to copy a memory region to a lower address range as well as to a
higher address range.

The only subtle moment when "up" plays any role, and "cmove>" can
produce the different (but expected) result than usual, is the case when
the target range is lower than the source range ("moving down") but
still has an intersection with the source range.

Ditto for "cmove", but for the "moving up" case.

Concerning overspecifying, — I think some applications rely on this
specific behavior to fill a memory region by a pattern.

Some examples of filling by a pattern are following.

s" *******A-B-" 2dup 4 /string 3 pick swap cmove> type

output: -B-A-B-A-B-

s" A-B-*******" 2dup 4 /string 3 pick -rot cmove type

output: A-B-A-B-A-B

Obviously, such effect cannot be achieved via "MOVE":

s" A-B-*******" 2dup 4 /string 3 pick -rot move type

output: A-B-A-B-***
NB: this string shows a part of the source memory region in front of
the complete target memory region.
The target region content is "A-B-***" that is the same as the source
region content before coping.

Probably, for big regions such memory propagation is more efficient than
call "MOVE" for a pattern in a loop.

In any case, this behavior cannot be changed due to backward
compatibility. Though I haven't yet face such application of "CMOVE" or
"CMOVE>".

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-08-31 10:10, Anton Ertl wrote:
>> : foo bar list> bla blub ;
>>
>> A list is passed to LIST>, which then executes the "bla blub" part
>> repeatedly, once for every list element.
>> A more modern (and more flexible and soon-standard)
>> approach is to put "bla blub" inside a quotation
>> and call that with EXECUTE for each list element.
>
>Yes, it's more flexible but sometime it's less convenient.
>
>I thought about this problem before. Why not throw out our conventional
>control flow structures for choices and loops and just use the
>quotation-based approach? Factor and some other languages go by this way.

In particular, Postscript.

Why not in Forth? One reason is that you cannot use the return stack
or locals to pass data into or out of quotations. Hugh Aguilar's
version of rquotations would at least allow locals; not sure about
humptydumpty's version.

>Let's take the example of BacFORTH-based nested iteration over two lists
>(from my previous message):
>
> : foo bar list=> bluh buz list=> blub ;
>
>Using the quotation-based approach this word "foo" will look as:
>
> : foo [: bluh [: blub ;] buz list:forearch ;] bar list:forearch ;
>
> \ where
> \ list:forearch ( i*x xt list -- j*x ) \ xt ( i*x item -- j*x )

Maybe the lack of readability comes from the name. The stack effect
is also a bad idea; you seem to be assuming that BAR and BUZ have the
stack effects ( -- x ), and in that case the stack effect does not
show its problems, except maybe in readability. Anyway, here we use a
shorter name and a better stack effect:

\ forlist ( ... list xt -- ... ), xt ( ... element -- ... )
: foo bar [: bluh buz ['] blub forlist ;] forlist ;

Readable enough for my taste. Now consider:

: foo2 bar [: bluh buz ['] blub forlist flip ;] forlist flop ;

How would you code that with LIST=> ?

There is a reason why we do not have IF=>, IFELSE=> (how would that
even work?), DO=> etc.

Instead we have words that start and end a control structure, and
sometimes words in the middle (ELSE, WHILE).

Andrew Haley suggested that over xt-taking words, so for the list case
this might be:

\ using the same approach of starting with @, adjust as necessary
: <list ]] begin @ dup while dup >r [[ ; immediate
: list> ]] r> repeat drop [[ ; immediate

And our examples become:

: foo bar <list bluh buz <list blub list> list> ;
: foo2 bar <list bluh buz <list blub list> flip list> flop ;

OTOH, I have added TRY ... ENDTRY (with some variants) as an
alternative to CATCH in Gforth, but find that I more often use CATCH,
despite TRY having additional functionality.

- 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 2021-08-31 20:41, S Jack wrote:
> On Tuesday, August 31, 2021 at 7:30:46 AM UTC-5, Ruvim wrote:
>> I would not encourage such usage of ">", and would suggest something
>> more contrast like "==>" instead (if any).
>
> Punctuation in word names has little merit. I'm sure you have
> noted that I use BUILD DOES as oppose to <BUILDS DOES> .

Don't sure. Where can your code be viewed?

> The brackets don't provide any _vital_ meaning
> and is problematic in providing a
> consistent meaning as testified by this thread.

I disagree, at least partially.

In case of DOES a telling meaning can be achieved using the following
markup variants:

: foo ... create ... does{ ... } ... ;

: foo ... create ... [: ... ;] does ... ;

> It also makes text descriptions difficult because punctuation in names
> conflicts with how punctuation is used in text

I use quoting to avoid such conflicts. I write "compile,", or 's"', or
"move" to distinct a Forth word in the surrounding text and avoid ambiguity.

> and it can be also be devastating
> if the host OS or communications gets a hold of them.

I can agree concerning OS API or similar things.

> Note that assembly code does not use punctuation in symbols for
> good reason, all the above said problems.
>
> Dropping unneeded punctuation from word names IMHO would be a step
> in the right direction.

Historically, many names in Forth already contain punctuation symbols.
And some of them have quite stable meaning. For example, "," comma
always means that something is appended into data and/or code space.
Such words cannot be easy throw out or replaced.

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-08-31 19:12, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2021-08-31 10:10, Anton Ertl wrote:
>>>> Note the pronounciation: "c-move-up". It means: cmove the memory
>>>> block from lower to higher addresses; i.e., the name describes the
>>>> usage (what), not the how.
....
>The wording "from lower to higher addresses" is almost the same as in
>the specification of how "cmove" works: "proceeding
>character-by-character from lower addresses to higher addresses"

Yes, the difference is between "proceeding" and "move".

>A problem with this etymology for "cmove>" is that it *can* be actually
>used to copy a memory region to a lower address range as well as to a
>higher address range.

The name and its pronounciation reflects the intended use, not all
possible uses.

>The only subtle moment when "up" plays any role, and "cmove>" can
>produce the different (but expected) result than usual, is the case when
>the target range is lower than the source range ("moving down") but
>still has an intersection with the source range.

Yes.

>Concerning overspecifying, — I think some applications rely on this
>specific behavior to fill a memory region by a pattern.

It's an overspecification for the MOVE-like use. Of course, once you
have an overspecification, it can allow other uses.

OTOH, an underspecification like memcpy() in the C standard is even
worse than an overspecification and has led to breakage and long
discussions <https://bugzilla.redhat.com/show_bug.cgi?id=638477>
<https://sourceware.org/bugzilla/show_bug.cgi?id=12518>. The way to
go is a complete specification that can be implemented efficiently.
Forth provides this with MOVE, and C with memmove(), making CMOVE,
CMOVE> only useful for legacy code and the (not-recommended, see
below) pattern case, and memcpy() useful only for legacy code.

>Some examples of filling by a pattern are following.
>
> s" *******A-B-" 2dup 4 /string 3 pick swap cmove> type
>
>output: -B-A-B-A-B-
>
>
> s" A-B-*******" 2dup 4 /string 3 pick -rot cmove type
>
>output: A-B-A-B-A-B
....
>Probably, for big regions such memory propagation is more efficient than
>call "MOVE" for a pattern in a loop.

That's doubtful. This usage produces dependencies from the store of
the second A to the load of it (5-6 cycles on modern CPUs), while
using MOVE multiple times does not. If you want to reduce the loop
and MOVE initialization overhead, first generate a longer pattern, and
then call MOVE with longer patterns. Or use a doubling-at-each step
strategy (or maybe quadrupling at each step); the latency described
above will play a role in the first few iterations, for later
iterations the throughput is the limit.

- 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 2/09/2021 01:04, Ruvim wrote:
> ...
> Concerning overspecifying, — I think some applications rely on this
> specific behavior to fill a memory region by a pattern.
>
> Some examples of filling by a pattern are following.
>
> s" *******A-B-" 2dup 4 /string 3 pick swap cmove> type
>
> output: -B-A-B-A-B-
>
>
> s" A-B-*******" 2dup 4 /string 3 pick -rot cmove type
>
> output: A-B-A-B-A-B

ANS delivers novelty patterns. Speed one must find elsewhere :)

On 2021-09-01 17:45, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-08-31 10:10, Anton Ertl wrote:
>>> : foo bar list> bla blub ;
>>>
>>> A list is passed to LIST>, which then executes the "bla blub" part
>>> repeatedly, once for every list element.
>>> A more modern (and more flexible and soon-standard)
>>> approach is to put "bla blub" inside a quotation
>>> and call that with EXECUTE for each list element.
>>
>> Yes, it's more flexible but sometime it's less convenient.
>>
>> I thought about this problem before. Why not throw out our conventional
>> control flow structures for choices and loops and just use the
>> quotation-based approach? Factor and some other languages go by this way.
>
> In particular, Postscript.
>
> Why not in Forth? One reason is that you cannot use the return stack
> or locals to pass data into or out of quotations.

Do you want to say that the data stack is not sufficient to pass data
to/from quotations? Why not introduce another stack then?

Anyway, the problem I'm trying to describe doesn't depend on these
features. This problem can have place even if closures are available.

> Hugh Aguilar's
> version of rquotations would at least allow locals;

But they cannot be used beyond the run-time of the definition where they
were defined (and so they might not be returned), isn't? Also, they
cannot have own locals. It's a cost of easy implementation of accessing
the parent's locals.

So, these rquotations are neither closures, nor quotations, but some
third independent type of a reference to a code fragment.

> not sure about humptydumpty's version.
>

>> Let's take the example of BacFORTH-based nested iteration over two lists
>> (from my previous message):
>>
>> : foo bar list=> bluh buz list=> blub ;
>>
>> Using the quotation-based approach this word "foo" will look as:
>>
>> : foo [: bluh [: blub ;] buz list:forearch ;] bar list:forearch ;
>>
>> \ where
>> \ list:forearch ( i*x xt list -- j*x ) \ xt ( i*x item -- j*x )
>
> Maybe the lack of readability comes from the name. The stack effect
> is also a bad idea; you seem to be assuming that BAR and BUZ have the
> stack effects ( -- x ), and in that case the stack effect does not
> show its problems, except maybe in readability. Anyway, here we use a
> shorter name and a better stack effect:
>
> \ forlist ( ... list xt -- ... ), xt ( ... element -- ... )
> : foo bar [: bluh buz ['] blub forlist ;] forlist ;

I intentionally write "[: blub ;]" instead of "['] blub", since I imply
that several words can be used in the "blub" placeholder.

> Readable enough for my taste. Now consider:
>
> : foo2 bar [: bluh buz ['] blub forlist flip ;] forlist flop ;
>
> How would you code that with LIST=> ?

I didn't advocate for the "X=>" markup, I just showed its better
readability, and noted its disadvantage that it only ends with ";" of
the containing word (similar to "does>").

So, in a better markup (that I also showed) I would code it as:

: foo2 bar list:each{ bluh buz 'blub list:each flip } flop ;
or
: foo3 bar list:each{ bluh buz list:each{ blub } flip } flop ;

where
list:each ( ... list xt -- ... )
list:each{ Run-time: ( ... list -- ... )
list:each{ content Run-time: ( ... element -- ... )

Probably, naming (and namespaces) can be better. But my point is that
the stack effect (whether xt or list is on the top) doesn't matter for
readability in this case. I talk about the different problem.

Compare the following code fragments:

bar [: bluh ...

and

bar list:each{ bluh ...

From the latter fragment of code we can assume (with some confidence)
that "bar" returns a list on the top of the stack, and from the curly
bracket the fragment of code starts that treats each element of the
list, and "bluh" accepts an element from the top of the stack.

What we can assume from the former code fragment? Actually nothing,
except it uses a quotation. Since we don't yet see how this quotation is
used.

So readability of a quotation-based code is less than a code with
structured iterators. This problem could even recall the "callback hell"
problem.

> There is a reason why we do not have IF=>, IFELSE=> (how would that
> even work?), DO=> etc.
>
> Instead we have words that start and end a control structure, and
> sometimes words in the middle (ELSE, WHILE).

It seems I was misunderstood.

"LIST=> ... ;" is a construct as well as "IF ... ELSE ... THEN".

In a quotation-based approach we use a higher order function instead of
all these constructs.

I don't consider moving into "X=>"-like construct (or markup), but
moving from the conventional control flow constructs to the
corresponding higher order functions.

I.e., instead of
if foo else bar then

we can write
'foo 'bar' ifelse

Or use quotations as
[: foo buz ;] [: bar qud ;] ifelse

Sometimes such functions (like "ifelse) are very useful, but usually
they lead to less readable code.

Compare above with the following:

if foo buz else bar qud then

or with a curly-based variant:
if{ foo buz }else{ bar qud }

The variant based on "ifelse" and a quotation has worse readability.

>
> Andrew Haley suggested that over xt-taking words, so for the list case
> this might be:

Is everything all right with Andrew? I haven't seen him here for a long
time.

>
> \ using the same approach of starting with @, adjust as necessary
> : <list ]] begin @ dup while dup >r [[ ; immediate
> : list> ]] r> repeat drop [[ ; immediate
>
> And our examples become:
>
> : foo bar <list bluh buz <list blub list> list> ;
> : foo2 bar <list bluh buz <list blub list> flip list> flop ;

Yes, it's what I consider, regardless of the implementation.
This naming choice is not so good, but even this variant is easier to
read than the quotation-based variant:

: foo2 bar [: bluh buz [: blub ;] forlist flip ;] forlist flop ;

> OTOH, I have added TRY ... ENDTRY (with some variants) as an
> alternative to CATCH in Gforth, but find that I more often use CATCH,
> despite TRY having additional functionality.

Do you compare quotation+CATCH against TRY+ENDTRY ?
Since only this comparison makes sense in this discussion context.

Bottom line.
I try to show that it's not a good idea to *replace* the conventional
control flow structures and structured iterators by higher order
functions. Rationale: the code that is only based on higher order
functions and quotations has less readability. Although, HOFs and
quotations are very useful sometimes.

--
Ruvim

I suggested that using a single CMOVE for filling a memory region with
a pattern is inefficient and that we could use an approach that
doubles the filled buffer size at each step (and without overlaps in
copying, so one could use either CMOVE, MOVE, or CMOVE>, as
convenient). So I wanted to test this.

As it turns out, the resulting word also satisfies the requirements
for CMOVE, so I call it CMOVE, too:

: cmove {: afrom ato u | u1 -- :}
ato afrom - u u< if \ overlapping case
ato afrom - u over + to u1 begin
afrom afrom 2 pick + 2 pick u1 over - min cmove
2* dup u u>= until
drop
else \ non-overlapping case
ato afrom u cmove
then ;

This CMOVE calls the simple CMOVE, because that is the fastest variant
for VFX and lxf.

Eliminating the locals is left as an exercise to the puristic readers.

I benchmarked this with:

: bench {: usize ulength -- :}
usize ulength + allocate throw
ulength 0 ?do 'a' i + over i + c! loop
10000000 0 ?do dup dup ulength + usize cmove loop ;

usize is the size of the yet-unfilled buffer, ulength is the length of
the pattern. I used usize=1000 and ulength from 1..5.

Here are the results in cycles/iteration on Zen 3 (Ryzen 5800X):

VFX64 lxf VFX32
orig new orig new orig new ulength
7474 1125 7624 1095 7807 423 1
3360 965 3140 933 4273 420 2
2367 957 2380 922 3018 411 3
2068 790 2147 761 2418 400 4
1645 779 1766 754 2083 426 5

As can be seen, the new CMOVE is substantially faster than the REP
MOVSB based one for this use case. Of course, the question remains
how relevant this use case is; but then, this is the only use case
where CMOVE behaves differently from MOVE, so it may be a
justification for keeping CMOVE.

We see that, the larger ulength is, the faster does the REP MOVSB
perform, because it can copy more bytes during the latency of the
store-load-store chain that determines performance. For the new
CMOVE, we also see a slight improvement with increasing ulength,
because there are then fewer iterations of the loop in the new CMOVE;
the cost of such an iteration at ~160 cycles is surprisingly high;
this may have to do with the cache behaviour of REP MOVSB.

VFX32 uses a simple byte-copying loop rather than REP MOVSB for the
overlapping case (orig), and performs similar to the REP MOVSB
implemenation. VFX32 uses a cell-copying loop in the non-overlapping
case (new), resulting in even faster performance; also, we see that
the number of iterations within the new CMOVE does not have as big an
influence as for VFX64 and lxf.

- 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 2/09/2021 07:34, Anton Ertl wrote:
> I suggested that using a single CMOVE for filling a memory region with
> a pattern is inefficient and that we could use an approach that
> doubles the filled buffer size at each step (and without overlaps in
> copying, so one could use either CMOVE, MOVE, or CMOVE>, as
> convenient). So I wanted to test this.
>
> As it turns out, the resulting word also satisfies the requirements
> for CMOVE, so I call it CMOVE, too:
>
> : cmove {: afrom ato u | u1 -- :}
> ato afrom - u u< if \ overlapping case
> ato afrom - u over + to u1 begin
> afrom afrom 2 pick + 2 pick u1 over - min cmove
> 2* dup u u>= until
> drop
> else \ non-overlapping case
> ato afrom u cmove
> then ;

F-PC in the mid 80's saw no requirement. Any need for propagation in
CMOVE falling away when Forth-79 introduced FILL and made it a core word.

On Thursday, September 2, 2021 at 12:20:20 AM UTC+2, Anton Ertl wrote:
> I suggested that using a single CMOVE for filling a memory region with
> a pattern is inefficient and that we could use an approach that
> doubles the filled buffer size at each step (and without overlaps in
> copying, so one could use either CMOVE, MOVE, or CMOVE>, as
> convenient). So I wanted to test this.
>
> As it turns out, the resulting word also satisfies the requirements
> for CMOVE, so I call it CMOVE, too:

Here I got a bit confused what you meant exactly (I didn't want to
read the whole thread again, sorry). I assume that the new cmove
can do the same as the old cmove, move and cmove> and therefore
triplicated the code with "cmove" replaced by either of the 3 old
words.
[..]
> This CMOVE calls the simple CMOVE, because that is the fastest variant
> for VFX and lxf.
[..]
> : bench {: usize ulength -- :}
> usize ulength + allocate throw
> ulength 0 ?do 'a' i + over i + c! loop
> 10000000 0 ?do dup dup ulength + usize cmove loop ;

this leaves the address of allocated area on the stack.

[..]
> Here are the results in cycles/iteration on Zen 3 (Ryzen 5800X):
>
> VFX64 lxf VFX32
> orig new orig new orig new ulength
> 7474 1125 7624 1095 7807 423 1
> 3360 965 3140 933 4273 420 2
> 2367 957 2380 922 3018 411 3
> 2068 790 2147 761 2418 400 4
> 1645 779 1766 754 2083 426 5
Below are the results for iForth64. The last three columns are for
the new cmove using either cmove, move, or cmove>.
The results are in ms.

FORTH> TEST
\ size len cm mv cm>
\ 1000 1 701 623 687
\ 1000 2 665 578 648
\ 1000 3 659 596 642
\ 1000 4 559 462 541
\ 1000 5 656 577 637

It appears length 4 is optimal, and "move" is fastest but
I am not at all sure that this tests the same thing you do.

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>On Thursday, September 2, 2021 at 12:20:20 AM UTC+2, Anton Ertl wrote:
>> I suggested that using a single CMOVE for filling a memory region with
>> a pattern is inefficient and that we could use an approach that
>> doubles the filled buffer size at each step (and without overlaps in
>> copying, so one could use either CMOVE, MOVE, or CMOVE>, as
>> convenient). So I wanted to test this.
>>
>> As it turns out, the resulting word also satisfies the requirements
>> for CMOVE, so I call it CMOVE, too:
>
>Here I got a bit confused what you meant exactly (I didn't want to
>read the whole thread again, sorry).

The point here is about implementing the pattern-replicating
functionality of CMOVE efficiently. I.e., if you have "ABC" at the
start of BUF, you can fill BUF with "ABCABCABC..." with

buf buf buflen 3 /string cmove

>I assume that the new cmove
>can do the same as the old cmove, move and cmove> and therefore
>triplicated the code with "cmove" replaced by either of the 3 old
>words.

The new CMOVE behaves as CMOVE is required to do (not MOVE, not
CMOVE>). The orig CMOVE it calls in the overlapping case can be
replaced by either MOVE or CMOVE>, because these calls only pass
non-overlapping parameters. Rethinking, for the "non-overlapping"
case you can use CMOVE or MOVE, but not CMOVE>, because this case is
not really non-overlapping, it's just that ato is not in the afrom
range; there is still the possibility of afrom being in the ato range,
and CMOVE> would not work for that. So here's a version with valid
alternative lines in comments:

: cmove {: afrom ato u | u1 -- :}
ato afrom - u u< if \ overlapping case
ato afrom - u over + to u1 begin
afrom afrom 2 pick + 2 pick u1 over - min cmove
\ afrom afrom 2 pick + 2 pick u1 over - min move
\ afrom afrom 2 pick + 2 pick u1 over - min cmove>
2* dup u u>= until
drop
else \ the usual non-pattern case
ato afrom u cmove
\ ato afrom u move
then ;

The non-pattern case is not benchmarked.

>Below are the results for iForth64. The last three columns are for
>the new cmove using either cmove, move, or cmove>.
>The results are in ms.
>
>FORTH> TEST
>\ size len cm mv cm>
>\ 1000 1 701 623 687
>\ 1000 2 665 578 648
>\ 1000 3 659 596 642
>\ 1000 4 559 462 541
>\ 1000 5 656 577 637
>
>It appears length 4 is optimal, and "move" is fastest but
>I am not at all sure that this tests the same thing you do.

It probably does. The different lengths are different use cases
(different pattern lengths), so they are not replacements for each
other, and it does not make sense to

Your results look similar to the VFX32 "new" results, so I guess you
are not using REP MOVSB for implementing CMOVE, CMOVE>, and MOVE.

The reason that longer patterns tend to be a little faster ist that
they reduce the number of iterations in the new CMOVE. I guess that
the reason that pattern length 4 is faster than pattern length 5 for
VFX32 is due to VFX32 using cell (4-byte) loads and stores for much of
the memory block, and byte loads and stores for the rest. With
pattern length 5 the first few iterations perform unaligned cell loads
and stores, and perform some byte loads and stores. Maybe something
along these lines happens for iForth, too.

- 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 2/09/2021 17:10, Anton Ertl wrote:
> Marcel Hendrix <mhx@iae.nl> writes:
>>On Thursday, September 2, 2021 at 12:20:20 AM UTC+2, Anton Ertl wrote:
>>> I suggested that using a single CMOVE for filling a memory region with
>>> a pattern is inefficient and that we could use an approach that
>>> doubles the filled buffer size at each step (and without overlaps in
>>> copying, so one could use either CMOVE, MOVE, or CMOVE>, as
>>> convenient). So I wanted to test this.
>>>
>>> As it turns out, the resulting word also satisfies the requirements
>>> for CMOVE, so I call it CMOVE, too:
>>
>>Here I got a bit confused what you meant exactly (I didn't want to
>>read the whole thread again, sorry).
>
> The point here is about implementing the pattern-replicating
> functionality of CMOVE efficiently. I.e., if you have "ABC" at the
> start of BUF, you can fill BUF with "ABCABCABC..." with
>
> buf buf buflen 3 /string cmove
>
>>I assume that the new cmove
>>can do the same as the old cmove, move and cmove> and therefore
>>triplicated the code with "cmove" replaced by either of the 3 old
>>words.
>
> The new CMOVE behaves as CMOVE is required to do (not MOVE, not
> CMOVE>). The orig CMOVE it calls in the overlapping case can be
> replaced by either MOVE or CMOVE>, because these calls only pass
> non-overlapping parameters. Rethinking, for the "non-overlapping"
> case you can use CMOVE or MOVE, but not CMOVE>, because this case is
> not really non-overlapping, it's just that ato is not in the afrom
> range; there is still the possibility of afrom being in the ato range,
> and CMOVE> would not work for that. So here's a version with valid
> alternative lines in comments:
>
> : cmove {: afrom ato u | u1 -- :}
> ato afrom - u u< if \ overlapping case
> ato afrom - u over + to u1 begin
> afrom afrom 2 pick + 2 pick u1 over - min cmove
> \ afrom afrom 2 pick + 2 pick u1 over - min move
> \ afrom afrom 2 pick + 2 pick u1 over - min cmove>
> 2* dup u u>= until
> drop
> else \ the usual non-pattern case
> ato afrom u cmove
> \ ato afrom u move
> then ;
>

Are you saying MOVE will do? Elizabeth's position was the /only/ reason
to include CMOVE CMOVE> in ANS was for reasons of propagation. She went
on to say CMOVE> was rarely used for this purpose and could probably be
scrapped. If MOVE will do then both can be scrapped.

dxforth <dxforth@gmail.com> writes:
>Are you saying MOVE will do? Elizabeth's position was the /only/ reason
>to include CMOVE CMOVE> in ANS was for reasons of propagation. She went
>on to say CMOVE> was rarely used for this purpose and could probably be
>scrapped. If MOVE will do then both can be scrapped.

Yes, you can provide MOVE, and for those who use CMOVE for pattern
propagation, provide a file that contains

: cmove {: afrom ato u | u1 -- :}
ato afrom - u u< if \ overlapping case
ato afrom - u over + to u1 begin
afrom afrom 2 pick + 2 pick u1 over - min move
2* dup u u>= until
drop
else \ the usual non-pattern case
ato afrom u move
then ;

Benchmarking that in addition to the orig-CMOVE-based version (again,
on the Ryzen 5800X):

cycles/iteration
VFX64 lxf VFX32
orig new move orig new move orig new move ulength
7474 1125 2903 7624 1095 2240 7807 423 380 1
3360 965 2722 3140 933 2059 4273 420 373 2
2367 957 2724 2380 922 2313 3018 411 389 3
2068 790 2537 2147 761 1871 2418 400 375 4
1645 779 2544 1766 754 2002 2083 426 370 5

So it depends on the MOVE implementation whether this is a good idea.

For VFX32 the resulting CMOVE is even faster than the orig-CMOVE-based
one.

OTOH, VFX64's and lxf's MOVE use the slow case of REP MOVSB in this
usage, and the result is not so great. It is still better than the
original CMOVE for length<=2 (VFX64) or length<=4 (lxf), but I expect
that in the non-pattern case the new CMOVE will never be faster and
occasionally much slower than the original CMOVE on these systems.

- 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