Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #41372 > unrolled thread

CMOVE/CMOVE>

Back to article view | Back to comp.lang.forth

Contents

  CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-18 08:44 -0700
    Re: CMOVE/CMOVE> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 16:05 +0000
      Re: CMOVE/CMOVE> november.nihal@gmail.com - 2015-08-18 09:34 -0700
        Re: CMOVE/CMOVE> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 16:41 +0000
      Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-18 09:59 -0700
        Re: CMOVE/CMOVE> Michael Barry <barrym95838@yahoo.com> - 2015-08-18 10:10 -0700
          Re: CMOVE/CMOVE> hughaguilar96@gmail.com - 2015-08-18 10:41 -0700
            Re: CMOVE/CMOVE> "Alex McDonald" <blog@rivadpm.com> - 2015-08-18 23:55 +0100
              Re: CMOVE/CMOVE> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-19 08:40 +0000
                Re: CMOVE/CMOVE> "Alex McDonald" <blog@rivadpm.com> - 2015-08-19 12:15 +0100
          Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-18 11:35 -0700
            Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-18 11:36 -0700
              Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-20 04:39 +1000
            Re: CMOVE/CMOVE> "Elizabeth D. Rather" <erather@forth.com> - 2015-08-19 09:15 -1000
            Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-28 22:39 +1000
              Re: CMOVE/CMOVE> Coos Haak <chforth@hccnet.nl> - 2015-08-28 15:06 +0200
                Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-29 17:15 +1000
                  Re: CMOVE/CMOVE> Coos Haak <chforth@hccnet.nl> - 2015-08-29 13:24 +0200
                    Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-31 11:38 +1000
                  Re: CMOVE/CMOVE> "Elizabeth D. Rather" <erather@forth.com> - 2015-08-29 07:59 -1000
                    Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-30 13:00 +1000
              Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-28 07:33 -0700
              Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-28 07:36 -0700
                Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-29 02:23 +1000
              Re: CMOVE/CMOVE> mhx@iae.nl - 2015-08-28 11:41 -0700
                Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-29 17:30 +1000
          Re: CMOVE/CMOVE> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-19 08:04 +0000
        Re: CMOVE/CMOVE> "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-19 02:48 -0400
          Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-19 00:49 -0700
      Re: CMOVE/CMOVE> Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-19 02:58 +0200

Page 2 of 2 — ← Prev page 1 [2]

#41610

Elizabeth D. Rather wrote:
> On 8/28/15 9:15 PM, HAA wrote:
> > Coos Haak wrote:
> >>
> >> Why the FLUSH? BUFFER knows when to write an UPDATEd blockbuffer.
> >>
> >> groet Coos
> >
> > BUFFER won't FLUSH the last block.
>
> BUFFER should write the content of any block that has been marked
> UPDATEd before reusing that buffer. You really only need to FLUSH when
> you're about to shut down the computer.

Or when there is an unacceptable risk of losing data you can't afford to lose.

[toc] | [prev] | [next] | [standalone]

#41596

Sure. Feel free to publish. No problem at all. 

Mark

[toc] | [prev] | [next] | [standalone]

#41597

Interesting that the DTC version is twice as slow using locals. I wonder why? 

[toc] | [prev] | [next] | [standalone]

#41598

Mark Wills wrote:
> Interesting that the DTC version is twice as slow using locals. I wonder why?

My guess is that with removal of the indirection you're starting to see the
real difference between the locals and non-locals version.

[toc] | [prev] | [next] | [standalone]

#41600

On Friday, August 28, 2015 at 2:38:10 PM UTC+2, HAA wrote:
> Mark Wills wrote:
[..]
> Speed (I/O and CMOVE code replaced with 2DROP) 

If the stack-code is one instruction, and the local code
two, the difference using your test is a factor of two.

The result is what it is, but presented in this way
it is not insightful. What were the timings of the
full test? How large was cnt?

-marcel

[toc] | [prev] | [next] | [standalone]

#41603

mhx@iae.nl wrote:
> On Friday, August 28, 2015 at 2:38:10 PM UTC+2, HAA wrote:
> > Mark Wills wrote:
> [..]
> > Speed (I/O and CMOVE code replaced with 2DROP)
>
> If the stack-code is one instruction, and the local code
> two, the difference using your test is a factor of two.
>
> The result is what it is, but presented in this way
> it is not insightful. What were the timings of the
> full test? How large was cnt?
>
> -marcel

Don't know what you mean by 'full test'.  The test used to
produce the timings are given in T1 and T2 which set cnt to 5.

[toc] | [prev] | [next] | [standalone]

#41394

Michael Barry <barrym95838@yahoo.com> writes:
>On Tuesday, August 18, 2015 at 9:59:02 AM UTC-7, Mark Wills wrote:
>> 
>> > : move ( from to count -- )
>> >   >r 2dup u< if
>> >     r> cmove>
>> >   else
>> >     r> cmove
>> >   then ;
>> > 
>> > Better branch prediction accuracy:
>> > 
>> > : move ( from to count -- )
>> >   >r 2dup dup r@ + within if
>> >     r> cmove
>> >   else
>> >     r> cmove>
>> >   then ;
>> > 
>> > Both not tested.
>> > 
>> > - anton
>> > -- 
>> >
>>  
>> That's nice code, thank you. Mine also included WITHIN but your first 
>> example is neater IMO. I just tested it quickly and it seems to work fine.
>> 
>> Thanks.
>> 
>> Mark
>
>Isn't it true that the decision can be made based simply on whether source start is less than destination start, regardless of count?

Correct (assuming that neither source nor destination regions cross
the -1..0 boundary), that's what the U< version does.  The WITHIN
version always uses CMOVE> for the non-overlap case, and thus will
probably produce better branch prediction (if the CPU has a branch
predictor).

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#41391

On Tue, 18 Aug 2015 12:59:01 -0400, Mark Wills <markwills1970@gmail.com> wrote:

> On Tuesday, 18 August 2015 17:16:28 UTC+1, Anton Ertl  wrote:
>> Mark Wills <markwills1970@gmail.com> writes:

>> >I'm aware of the word MOVE which will choose to perform either a CMOVE
>> >or CMOVE> depending on overlap and direction. My system doesn't have
>> >MOVE though I'd like to implement it.
>> >
>> >Does anyone have any nice concise logic for checking the parameters and
>> >calling either CMOVE or CMOVE> accordingly?
>>
>> : move ( from to count -- )
>>   >r 2dup u< if
>>     r> cmove>
>>   else
>>     r> cmove
>>   then ;
>>
>> Better branch prediction accuracy:
>>
>> [...]
>
> That's nice code, thank you. Mine also included WITHIN but your first
> example is neater IMO. I just tested it quickly and it seems to work fine.


There is lots of useful information to be found in Google Groups
archive of comp.lang.forth.


BruceMcF Dec 2010
https://groups.google.com/d/msg/comp.lang.forth/zFEW7-NWJXM/rI8nbNsw9z0J

His '>' should probably be 'U>'.  His IF sections are reversed too.


Michael L Gassanenko's  CMOVE CMOVE> MOVE   Mar 2002
https://groups.google.com/d/msg/comp.lang.forth/hYokH0zY9RY/xSFFFb2CSJ0J

He has a slight variation for MOVE.  He moves the duplicate R> outside
the conditional.


I have the same as Anton's, except the IF sections are reversed from
Anton's, like BruceMcF did too, i.e., U> instead of U< .  Both CMOVE
and CMOVE> should perform the copy of the region if 'from' = 'to'.
So, this shouldn't matter, unless there is an implementation issue
with CMOVE or CMOVE> .  I.e., it's possibly worth checking to make
sure it actually works when 'from' = 'to'.  If 'from' and 'to' are
actually equal - unlikely, but possible - you might want to kick out
of the definition, i.e., to not waste time doing a useless copy.


Rod Pemberton

-- 
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...

[toc] | [prev] | [next] | [standalone]

#41393

On Wednesday, 19 August 2015 07:48:27 UTC+1, Rod Pemberton  wrote:
> On Tue, 18 Aug 2015 12:59:01 -0400, Mark Wills <markwills1970@gmail.com> wrote:
> 
> > On Tuesday, 18 August 2015 17:16:28 UTC+1, Anton Ertl  wrote:
> >> Mark Wills <markwills1970@gmail.com> writes:
> 
> >> >I'm aware of the word MOVE which will choose to perform either a CMOVE
> >> >or CMOVE> depending on overlap and direction. My system doesn't have
> >> >MOVE though I'd like to implement it.
> >> >
> >> >Does anyone have any nice concise logic for checking the parameters and
> >> >calling either CMOVE or CMOVE> accordingly?
> >>
> >> : move ( from to count -- )
> >>   >r 2dup u< if
> >>     r> cmove>
> >>   else
> >>     r> cmove
> >>   then ;
> >>
> >> Better branch prediction accuracy:
> >>
> >> [...]
> >
> > That's nice code, thank you. Mine also included WITHIN but your first
> > example is neater IMO. I just tested it quickly and it seems to work fine.
> 
> 
> There is lots of useful information to be found in Google Groups
> archive of comp.lang.forth.
> 
> 
> BruceMcF Dec 2010
> https://groups.google.com/d/msg/comp.lang.forth/zFEW7-NWJXM/rI8nbNsw9z0J
> 
> His '>' should probably be 'U>'.  His IF sections are reversed too.
> 
> 
> Michael L Gassanenko's  CMOVE CMOVE> MOVE   Mar 2002
> https://groups.google.com/d/msg/comp.lang.forth/hYokH0zY9RY/xSFFFb2CSJ0J
> 
> He has a slight variation for MOVE.  He moves the duplicate R> outside
> the conditional.
> 
> 
> I have the same as Anton's, except the IF sections are reversed from
> Anton's, like BruceMcF did too, i.e., U> instead of U< .  Both CMOVE
> and CMOVE> should perform the copy of the region if 'from' = 'to'.
> So, this shouldn't matter, unless there is an implementation issue
> with CMOVE or CMOVE> .  I.e., it's possibly worth checking to make
> sure it actually works when 'from' = 'to'.  If 'from' and 'to' are
> actually equal - unlikely, but possible - you might want to kick out
> of the definition, i.e., to not waste time doing a useless copy.
> 
> 
> Rod Pemberton
> 
> -- 
> Scientists now say we'll experience a mini-ice in 2030.
> So, I guess we need more global warming today ...

Great stuff. Thanks for the links, Rod.

[toc] | [prev] | [next] | [standalone]

#41389

Anton Ertl wrote:

> Mark Wills <markwills1970@gmail.com> writes:
>>I'm aware of the word MOVE which will choose to perform either a CMOVE or
>>CMOVE> depending on overlap and direction. My system doesn't have MOVE
>>though I'd like to implement it.
>>
>>Does anyone have any nice concise logic for checking the parameters and
>>calling either CMOVE or CMOVE> accordingly?
> 
> : move ( from to count -- )
>   >r 2dup u< if
>     r> cmove>
>   else
>     r> cmove
>   then ;
> 
> Better branch prediction accuracy:
> 
> : move ( from to count -- )
>   >r 2dup dup r@ + within if
>     r> cmove
>   else
>     r> cmove>
>   then ;
> 
> Both not tested.

The first one is tested, we use it in Gforth EC.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web