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

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

structure and interpretation of computer programs exercsie 1.3 in forth

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

Contents

  structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 04:22 -0800
    Re: structure and interpretation of computer programs exercsie 1.3 in forth Alex McDonald <blog@rivadpm.com> - 2013-01-11 05:47 -0800
      Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-11 06:12 -0800
        Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 06:18 -0800
          Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-11 06:20 -0800
        Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-11 06:19 -0800
          Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 06:38 -0800
            Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-11 06:51 -0800
              Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 07:10 -0800
              Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 07:58 -0800
                Re: structure and interpretation of computer programs exercsie 1.3 in forth rickman <gnuarm@gmail.com> - 2013-01-14 10:01 -0500
        Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 06:25 -0800
          Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 06:28 -0800
          Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-11 06:33 -0800
            Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 06:37 -0800
        Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-11 06:56 -0800
          Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 08:03 -0800
            Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 08:06 -0800
              Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-11 12:27 -0800
                Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-13 17:32 -0800
                  Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-13 23:21 -0800
                    Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-13 23:41 -0800
                      Re: structure and interpretation of computer programs exercsie 1.3 in forth Paul Rubin <no.email@nospam.invalid> - 2013-01-13 23:43 -0800
                        Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-14 00:02 -0800
                          Re: structure and interpretation of computer programs exercsie 1.3 in forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-14 22:43 +1300
                            Re: structure and interpretation of computer programs exercsie 1.3 in forth Paul Rubin <no.email@nospam.invalid> - 2013-01-14 02:41 -0800
                              Re: structure and interpretation of computer programs exercsie 1.3 in forth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-01-14 11:13 +0000
                              Re: structure and interpretation of computer programs exercsie 1.3 in forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-14 11:16 +0000
                                Re: structure and interpretation of computer programs exercsie 1.3 in forth mhx@iae.nl (Marcel Hendrix) - 2013-01-14 21:27 +0200
                            Re: structure and interpretation of computer programs exercsie 1.3 in forth Howerd <howerdo@yahoo.co.uk> - 2013-01-14 03:34 -0800
                            Re: structure and interpretation of computer programs exercsie 1.3  in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-14 12:53 +0000
                              Re: structure and interpretation of computer programs exercsie 1.3  in forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-17 17:31 +1300
                            Re: structure and interpretation of computer programs exercsie 1.3 in forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-21 19:35 -0800
                          Re: structure and interpretation of computer programs exercsie 1.3 in forth Paul Rubin <no.email@nospam.invalid> - 2013-01-14 02:55 -0800
                          Re: structure and interpretation of computer programs exercsie 1.3 in forth rickman <gnuarm@gmail.com> - 2013-01-14 10:14 -0500
                          Re: structure and interpretation of computer programs exercsie 1.3 in forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-14 20:04 +0100
                            Re: structure and interpretation of computer programs exercsie 1.3 in forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-21 19:57 -0800
                              Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-21 23:19 -0800
                                Re: structure and interpretation of computer programs exercsie 1.3 in forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 18:58 -0800
                                  Re: structure and interpretation of computer programs exercsie 1.3 in forth Alex McDonald <blog@rivadpm.com> - 2013-01-25 15:46 -0800
                                    Re: structure and interpretation of computer programs exercsie 1.3 in forth Pablo Hugo Reda <pabloreda@gmail.com> - 2013-01-25 19:09 -0800
                                      Re: structure and interpretation of computer programs exercsie 1.3 in forth Alex McDonald <blog@rivadpm.com> - 2013-01-26 01:12 -0800
                                  Re: structure and interpretation of computer programs exercsie 1.3 in forth mhx@iae.nl (Marcel Hendrix) - 2013-01-26 12:58 +0200
                                    Re: structure and interpretation of computer programs exercsie 1.3 in forth Alex McDonald <blog@rivadpm.com> - 2013-01-26 04:42 -0800
                                    Re: structure and interpretation of computer programs exercsie 1.3 in forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-26 14:35 +0000
                    Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-21 22:38 -0800
              Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-11 12:36 -0800
                Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-13 17:33 -0800
                  Re: structure and interpretation of computer programs exercsie 1.3 in forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-14 22:46 +1300
                    Re: structure and interpretation of computer programs exercsie 1.3 in forth rickman <gnuarm@gmail.com> - 2013-01-14 10:20 -0500
                      Re: structure and interpretation of computer programs exercsie 1.3 in forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-14 10:41 -0600
                        Re: structure and interpretation of computer programs exercsie 1.3 in forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-17 17:34 +1300
                        Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-21 22:48 -0800
                    Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-21 22:49 -0800
                      Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-21 23:55 -0800
                  Re: structure and interpretation of computer programs exercsie 1.3 in forth "Ed" <invalid@nospam.com> - 2013-01-18 12:50 +1100
                    Re: structure and interpretation of computer programs exercsie 1.3 in forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-18 23:31 +0100
                      Re: structure and interpretation of computer programs exercsie 1.3 in forth "Ed" <invalid@nospam.com> - 2013-01-20 12:42 +1100
                        Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-20 01:24 -0800
                          Re: structure and interpretation of computer programs exercsie 1.3 in forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-20 15:51 -0800
                          Re: structure and interpretation of computer programs exercsie 1.3 in forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-21 22:14 +1300
                            Re: structure and interpretation of computer programs exercsie 1.3 in forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-21 19:14 -0800
                        Re: structure and interpretation of computer programs exercsie 1.3 in forth "A. K." <akk@nospam.org> - 2013-01-20 11:13 +0100
                          Re: structure and interpretation of computer programs exercsie 1.3 in forth Paul Rubin <no.email@nospam.invalid> - 2013-01-20 02:45 -0800
                            Re: structure and interpretation of computer programs exercsie 1.3 in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-21 17:14 +0000
                              Re: structure and interpretation of computer programs exercsie 1.3 in forth Paul Rubin <no.email@nospam.invalid> - 2013-01-23 01:52 -0800
                                Re: structure and interpretation of computer programs exercsie 1.3 in forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 04:25 -0600
                                Re: structure and interpretation of computer programs exercsie 1.3 in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 15:20 +0000
                                  Re: structure and interpretation of computer programs exercsie 1.3 in forth Paul Rubin <no.email@nospam.invalid> - 2013-01-23 09:29 -0800
                                    Re: structure and interpretation of computer programs exercsie 1.3 in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 17:40 +0000
                                      Re: structure and interpretation of computer programs exercsie 1.3 in forth Paul Rubin <no.email@nospam.invalid> - 2013-01-23 22:03 -0800
                                        Re: structure and interpretation of computer programs exercsie 1.3 in forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-24 22:13 +1300
                                          Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-24 02:57 -0800
                                          Re: structure and interpretation of computer programs exercsie 1.3 in forth Paul Rubin <no.email@nospam.invalid> - 2013-01-26 13:49 -0800
                                            Re: structure and interpretation of computer programs exercsie 1.3 in forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-26 12:40 -1000
                                              Re: structure and interpretation of computer programs exercsie 1.3 in forth Paul Rubin <no.email@nospam.invalid> - 2013-01-26 23:20 -0800
                                                Re: structure and interpretation of computer programs exercsie 1.3 in forth mhx@iae.nl (Marcel Hendrix) - 2013-01-27 09:52 +0200
                                    Re: structure and interpretation of computer programs exercsie 1.3 in forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-01-23 23:05 +0000
                          Re: structure and interpretation of computer programs exercsie 1.3  in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-21 17:05 +0000
                            Re: structure and interpretation of computer programs exercsie 1.3  in forth "A. K." <akk@nospam.org> - 2013-01-21 19:28 +0100
                              Re: structure and interpretation of computer programs exercsie 1.3   in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-22 17:43 +0000
                              Re: structure and interpretation of computer programs exercsie 1.3 in forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-01-22 19:12 +0000
                        Re: structure and interpretation of computer programs exercsie 1.3 in forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-01-21 12:13 +0000
                        Re: structure and interpretation of computer programs exercsie 1.3 in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-21 17:28 +0000
                      Re: structure and interpretation of computer programs exercsie 1.3 in forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-22 18:06 +0000
                        Re: structure and interpretation of computer programs exercsie 1.3 in forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-22 19:30 +0100
                Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-21 23:06 -0800
                  Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-22 02:20 -0800
                    Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-22 03:36 -0800
                      Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-22 06:51 -0800
                  Re: structure and interpretation of computer programs exercsie 1.3 in forth marko <marko@marko.marko> - 2013-01-24 22:14 +1100
                    Re: structure and interpretation of computer programs exercsie 1.3 in forth the_gavino_himself <visphatesjava@gmail.com> - 2013-01-27 20:39 -0800
                      Re: structure and interpretation of computer programs exercsie 1.3 in forth marko <marko@marko.marko> - 2013-02-01 22:07 +1100
                      Re: structure and interpretation of computer programs exercsie 1.3 in forth marko <marko@marko.marko> - 2013-02-01 22:53 +1100
                        Re: structure and interpretation of computer programs exercsie 1.3 in forth the_gavino_himself <visphatesjava@gmail.com> - 2013-02-08 19:50 -0800
                          Re: structure and interpretation of computer programs exercsie 1.3 in forth Elizabeth D Rather <erather@forth.com> - 2013-02-08 19:22 -1000
        Re: structure and interpretation of computer programs exercsie 1.3 in forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-11 11:44 -0600
          Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-11 12:34 -0800
      Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-11 06:18 -0800
    Re:structure and interpretation of computer programs exercsie 1.3 in forth Hans Bezemer <the.beez.speaks@gmail.com> - 2013-01-14 00:13 +0100
      Re: structure and interpretation of computer programs exercsie 1.3 in forth Doug Hoffman <glidedog@gmail.com> - 2013-01-13 19:12 -0500
        Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-13 18:26 -0800
        Re: structure and interpretation of computer programs exercsie 1.3 in forth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-01-14 08:29 +0000
          Re: structure and interpretation of computer programs exercsie 1.3 in forth Hans Bezemer <the.beez.speaks@gmail.com> - 2013-01-14 23:52 +0100
      Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-13 18:31 -0800
      Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-13 23:19 -0800
        Re: structure and interpretation of computer programs exercsie 1.3 in forth gavino_himself <visploveslisp@gmail.com> - 2013-01-21 22:46 -0800
          Re: structure and interpretation of computer programs exercsie 1.3 in forth Mark Wills <forthfreak@gmail.com> - 2013-01-21 23:40 -0800

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#19160

> 
> XCHG is a huge latency; the P4 takes in excess of 100 cycles. It
> 
> exceeds the cost of a jump by at least an order of magnitude.
> 


I remenber see the diferent speed in the first compiler in 2006 (a celeron machine perhaps, not remember) when change the definition of swap (with and without XCHG).

Last test in a i3 not see this diference anymore, and now I use xchg because not need a extra register to swap.

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

#19162

On Jan 26, 3:09 am, Pablo Hugo Reda <pablor...@gmail.com> wrote:
> > XCHG is a huge latency; the P4 takes in excess of 100 cycles. It
>
> > exceeds the cost of a jump by at least an order of magnitude.
>
> I remenber see the diferent speed in the first compiler in 2006 (a celeron machine perhaps, not remember) when change the definition of swap (with and without XCHG).
>
> Last test in a i3 not see this diference anymore, and now I use xchg because not need a extra register to swap.

XCHG where both operands are registers is much quicker. A memory
operand has an implied LOCK and huge latency, even on later processors.

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

#19163

Hugh Aguilar <hughaguilar96@yahoo.com> wrote Re: structure and interpretation of computer programs exercsie 1.3 in forth
[..]
> Here is a version of MINMAX in traditional assembly language:
>
> minmax:                 ; a b -- min max
>        mov edx, [ebp]
>        cmp edx, ebx
>        mov ecx, edx
>        cmovg edx, ebx
>        cmovg ebx, ecx
>        mov [ebp], edx
>        next
>
> This is only 6 instructions, rather than 7, and it has only 2 memory
> accesses, rather than 3 --- so it should be slightly more efficient
> than what VFX generated --- but VFX was still pretty impressive.
>
> I haven't tested this, because I haven't yet figured out how the
> assembler works in VFX. I just wrote this in traditional assembly
> format. I'm assuming that EBP is the parameter stack pointer and EBX
> is the top value of the stack --- afaik, that is how VFX is
> implemented.
>
> Your method would be written like this:
>
> minmax:                 ; a b -- min max
>        cmp [ebp], ebx
>        jg swap
>        next
>
> swap:                   ; a b -- b a
>        xchg [ebp], ebx
>        next
>
> It is shorter not longer on the x86. It is also slower not faster
> (because of the jump, which the branch-predictor will get wrong 50% of
> the time).

This problem is a lot more interesting than I initially thought.

My impression was that Intel continuously benchmarks generated code 
and tweaks their CPU's so that simple stupid practices always win, 
no matter what hardware needs to be added. My hypothesis was 
that the branching code might be faster than the conditional moves.

Apparently, it doesn't work like that.

A rough benchmark of the two snippets seems to back up my initial 
hypothesis:

FORTH> bench 
branchless minmax : 0.271 seconds elapsed.
branching minmax2 : 0.123 seconds elapsed.
branching minmax3 : 0.123 seconds elapsed.

However, this is when the looped minmax2/3 always see the same two values
to compare and can perfectly predict which branch will be taken.

For the second benchmark I used a random generator to provide the
values to be compared, en the results are radically different:

FORTH> bench2
overhead          : 0.719 seconds elapsed.
branchless minmax : 0.731 seconds elapsed.
branching minmax2 : 1.265 seconds elapsed.
branching minmax3 : 1.182 seconds elapsed.

The overhead of all three versions is 719 ms. Now the branchless 
minmax needs almost zero time (12 ms) compared to minmax2 and minmax3 
(546 ms). The branchless minmax is slightly larger, but with respect 
to runtime there is no comparison -- it is 45 times faster at least. 

There is another weird thing here: the exchange instruction does
not matter in bench, but leads to slighter slower code in bench2.

It is probably more important to notice that even in the case 
where one operand is memory based, xchg is not slow at all.

-marcel

--
NEEDS -assemble

ANEW -minmax

CODE minmax  \ a b -- min max
	[rsp]        -> rax mov,
	[rsp cell +] -> rdx mov,
	rax -> rdx cmp,
	rdx -> rcx mov,
	rax -> rdx cmovg,
	rcx -> rax cmovg,
	rdx -> [rsp cell +] mov,
	rax -> [rsp]        mov,
	rbx jmp,
END-CODE        

CODE minmax2 \ a b -- min max
        rax pop,
	rax -> [rsp] cmp,
 >, IF, rax -> [rsp] xchg, 
 ENDIF, rax push, 
        rbx jmp,
END-CODE

CODE minmax3 \ a b -- min max
        rax pop,
	rcx pop,
	rax -> rcx cmp,
 >, IF, rax -> rcx xchg, 
 ENDIF, rcx push,
 	rax push, 
        rbx jmp,
END-CODE

#100000000 VALUE #times
1 2 DVALUE vals
: bench TIMER-RESET #times 0 ?DO LOOP MS? LOCAL preset
	CR ." branchless minmax : " preset TIMER-PRESET vals #times 0 ?DO  minmax  LOOP 2drop .ELAPSED 
	CR ." branching minmax2 : " preset TIMER-PRESET vals #times 0 ?DO  minmax2 LOOP 2drop .ELAPSED 
	CR ." branching minmax3 : " preset TIMER-PRESET vals #times 0 ?DO  minmax3 LOOP 2drop .ELAPSED ;

: bench2 
	CR ." overhead          : " TIMER-RESET  #times 0 ?DO  random random         2drop LOOP  .ELAPSED
	CR ." branchless minmax : " TIMER-RESET  #times 0 ?DO  random random minmax  2drop LOOP  .ELAPSED 
	CR ." branching minmax2 : " TIMER-RESET  #times 0 ?DO  random random minmax2 2drop LOOP  .ELAPSED 
	CR ." branching minmax3 : " TIMER-RESET  #times 0 ?DO  random random minmax3 2drop LOOP  .ELAPSED ;

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

#19165

On Jan 26, 10:58 am, m...@iae.nl (Marcel Hendrix) wrote:

>
> It is probably more important to notice that even in the case
> where one operand is memory based, xchg is not slow at all.

Which processor? I will re-run some micro-benchmarks later today (or
possibly next week) & post up the results on my i7. XCHG was
*seriously* slow the last time I did this test.

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

#19166

In article <95779109028434@frunobulax.edu>, Marcel Hendrix <mhx@iae.nl> wrote:
<SNIP>
>
>The overhead of all three versions is 719 ms. Now the branchless
>minmax needs almost zero time (12 ms) compared to minmax2 and minmax3
>(546 ms). The branchless minmax is slightly larger, but with respect
>to runtime there is no comparison -- it is 45 times faster at least.
>
>There is another weird thing here: the exchange instruction does
>not matter in bench, but leads to slighter slower code in bench2.

I know that Intel has nowadays a register renaming mechanism
such that it has actually more registers to play with then the
traditional 8. In that situation XCHG may take no time, just
leads to a different interpretation and different data paths.
In a loop it may be that registers return after some exchanges
to their "proper" place, or they may not. That would make a
difference.

Compare my (c) gcd algorithm:

gcd(int a, int b)
{
    while ( (a%=b) && (b%=a) ) {}
    return a+b;
}

Variables are never swapped, like it would in a naive algorithm.

>
>It is probably more important to notice that even in the case
>where one operand is memory based, xchg is not slow at all.
>
>-marcel
>
<SNIP>
Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#18980

On Sunday, January 13, 2013 11:21:39 PM UTC-8, M.R.W Wills wrote:
> On Jan 14, 1:32 am, gavino_himself <visplovesl...@gmail.com> wrote:
> 
> > On Friday, January 11, 2013 12:27:34 PM UTC-8, M.R.W Wills wrote:
> 
> > > On Jan 11, 4:06 pm, gavino_himself <visplovesl...@gmail.com> wrote:
> 
> >
> 
> > > > On Friday, January 11, 2013 8:03:13 AM UTC-8, gavino_himself wrote:
> 
> >
> 
> > > > > On Friday, January 11, 2013 6:56:35 AM UTC-8, M.R.W Wills wrote:
> 
> >
> 
> > > > > > On Jan 11, 2:12 pm, Mark Wills <forthfr...@gmail.com> wrote:
> 
> >
> 
> > > > > > > On Jan 11, 1:47 pm, Alex McDonald <b...@rivadpm.com> wrote:
> 
> >
> 
> > > > > > > > On Jan 11, 12:22 pm, gavino_himself <visplovesl...@gmail.com> wrote:
> 
> >
> 
> > > > > > > > > Exercise 1.3.  Define a procedure that takes three numbers as arguments and returns the sum of the squares of the two larger numbers.
> 
> >
> 
> > > > > > > > > Please post a forth solution.
> 
> >
> 
> > > > > > > > First you should post how you might go about doing it by hand.
> 
> >
> 
> > > > > > > > Describe how you might take 3 numbers and work out the sum of the
> 
> >
> 
> > > > > > > > squares of the two larger numbers.
> 
> >
> 
> > > > > > > Alex,
> 
> >
> 
> > > > > > > I hear you, but there's no chance of Gavino being able to concentrate
> 
> >
> 
> > > > > > > on *anything* for that long. I'd be surprised if he can piss while
> 
> >
> 
> > > > > > > standing up!
> 
> >
> 
> > > > > > > Nicely factored:
> 
> >
> 
> > > > > > > : swap? ( n1 n2 -- n1 n2 | n2 n1)
> 
> >
> 
> > > > > > >         2dup < if swap then ;
> 
> >
> 
> > > > > > > : gavino ( n1 n2 n3 - n)
> 
> >
> 
> > > > > > >         swap? rot swap? drop   dup * swap dup * + ;
> 
> >
> 
> > > > > > Actually, this is possibly "better" in the sense that it's smaller and
> 
> >
> 
> > > > > > more efficient:
> 
> >
> 
> > > > > > : gavino ( n1 n2 n3 - n)
> 
> >
> 
> > > > > >         2dup < if swap then rot max   dup *  swap dup *  + ;
> 
> >
> 
> > > > > say you have 1 2 3
> 
> >
> 
> > > > > can you describe what this does?
> 
> >
> 
> > > > > I am having trouble because < must be compiled following what happens.
> 
> >
> 
> > > > >    2dup < if swap then ;
> 
> >
> 
> > > > I guess it goes 1 2 3
> 
> >
> 
> > > > then has 1 2 3 2 3
> 
> >
> 
> > > > then < sees that 2 is less than 3 in the top 2, consuming them in the process, and executes swap, to produce
> 
> >
> 
> > > > 1 3 2
> 
> >
> 
> > > > ok wow
> 
> >
> 
> > > > this takes a little getting used to
> 
> >
> 
> > > > I was confusing myself thinking that < too 3 off the top and made 3 < 2
> 
> >
> 
> > > That's exactly right. You got it.
> 
> >
> 
> > > If you execute the following in Forth:
> 
> >
> 
> > > 5 9 <
> 
> >
> 
> > > What you are asking is "is 5 less than 9?". The answer is yes, so a
> 
> >
> 
> > > TRUE flag will be left on the stack. Note also that < "consumes" its
> 
> >
> 
> > > arguments (5 and 9 in this example) which is why you need a 2dup.
> 
> >
> 
> > Mr Willis you have taught me some forth!!!
> 
> > I salute you.
> 
> > AWESOME
> 
> > I have not failed to notice how the forth solution is in fewer lines than the lisp solution!!
> 
> > I am now motivated to finish starting forth and read thinking forth.
> 
> > You have single handedly ressurected my motivation to explore forth!- Hide quoted text -
> 
> >
> 
> > - Show quoted text -
> 
> 
> 
> Why thank you, sir. And it's Wills, not Willis ;-)
> 
> 
> 
> (If I had a pound...!)

Sorry about that..

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

#18679

On Jan 11, 4:06 pm, gavino_himself <visplovesl...@gmail.com> wrote:
>
> this takes a little getting used to
>

When you are used to other languages the "confusing" thing in Forth is
understanding its total simplicity. It takes a while sink in just how
*simple* it all is!

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

#18729

On Friday, January 11, 2013 12:36:52 PM UTC-8, M.R.W Wills wrote:
> On Jan 11, 4:06 pm, gavino_himself <visplovesl...@gmail.com> wrote:
> 
> >
> 
> > this takes a little getting used to
> 
> >
> 
> 
> 
> When you are used to other languages the "confusing" thing in Forth is
> 
> understanding its total simplicity. It takes a while sink in just how
> 
> *simple* it all is!

I vow to read both starting and thinking forth.  I remember Jeff Fox's writing bringing up the simplicity a lot. 

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

#18751

On 1/14/13 2:33 PM, gavino_himself wrote:
> On Friday, January 11, 2013 12:36:52 PM UTC-8, M.R.W Wills wrote:
>> On Jan 11, 4:06 pm, gavino_himself <visplovesl...@gmail.com> wrote:
>>
>>>
>>
>>> this takes a little getting used to
>>
>>>
>>
>>
>>
>> When you are used to other languages the "confusing" thing in Forth is
>>
>> understanding its total simplicity. It takes a while sink in just how
>>
>> *simple* it all is!
>
> I vow to read both starting and thinking forth.  I remember Jeff Fox's writing bringing up the simplicity a lot.
>

Starting Forth, in particular, represents an obsolete version of Forth. 
It will only confuse you. You said at one point you had Forth 
Application Techniques... if you read that and work all the problems 
you'll be on track.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#18767

On 1/14/2013 4:46 AM, Elizabeth D. Rather wrote:
> On 1/14/13 2:33 PM, gavino_himself wrote:
>> On Friday, January 11, 2013 12:36:52 PM UTC-8, M.R.W Wills wrote:
>>> On Jan 11, 4:06 pm, gavino_himself <visplovesl...@gmail.com> wrote:
>>>
>>>>
>>>
>>>> this takes a little getting used to
>>>
>>>>
>>>
>>>
>>>
>>> When you are used to other languages the "confusing" thing in Forth is
>>>
>>> understanding its total simplicity. It takes a while sink in just how
>>>
>>> *simple* it all is!
>>
>> I vow to read both starting and thinking forth. I remember Jeff Fox's
>> writing bringing up the simplicity a lot.
>>
>
> Starting Forth, in particular, represents an obsolete version of Forth.
> It will only confuse you. You said at one point you had Forth
> Application Techniques... if you read that and work all the problems
> you'll be on track.
>
> Cheers,
> Elizabeth
>

I thought Starting Forth had been updated so that it could be used on a 
modern Forth including all the examples?  Isn't this on the web somewhere?

Rick

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

#18768

rickman <gnuarm@gmail.com> wrote:
> I thought Starting Forth had been updated so that it could be used on a 
> modern Forth including all the examples?  Isn't this on the web somewhere?

Not exactly.  The Starting Forth update is a bit of a disaster.  It
was updated from the first edition, which was pre-FORTH-83, rather
than the second edition.  It was then patched up to be ANS, but some
of the wordage is still pre-ANS even though the illustrations are from
the second edition.

Andrew.

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

#18870

On 1/15/13 5:41 AM, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
>> I thought Starting Forth had been updated so that it could be used on a
>> modern Forth including all the examples?  Isn't this on the web somewhere?
>
> Not exactly.  The Starting Forth update is a bit of a disaster.  It
> was updated from the first edition, which was pre-FORTH-83, rather
> than the second edition.  It was then patched up to be ANS, but some
> of the wordage is still pre-ANS even though the illustrations are from
> the second edition.

Not to mention that some chapters are completely irrelevant (blocks, 
block editor, etc.) for today's Forths, and the fact that it assumes ITC 
structure which many modern Forths don't use.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#18982

On Monday, January 14, 2013 8:41:45 AM UTC-8, Andrew Haley wrote:
> rickman <gnuarm@gmail.com> wrote:
> 
> > I thought Starting Forth had been updated so that it could be used on a 
> 
> > modern Forth including all the examples?  Isn't this on the web somewhere?
> 
> 
> 
> Not exactly.  The Starting Forth update is a bit of a disaster.  It
> 
> was updated from the first edition, which was pre-FORTH-83, rather
> 
> than the second edition.  It was then patched up to be ANS, but some
> 
> of the wordage is still pre-ANS even though the illustrations are from
> 
> the second edition.
> 
> 
> 
> Andrew.

Any chance of a forth wikibook like haskell's wikibook appearing?

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

#18983

On Monday, January 14, 2013 1:46:43 AM UTC-8, Elizabeth D. Rather wrote:
> On 1/14/13 2:33 PM, gavino_himself wrote:
> 
> > On Friday, January 11, 2013 12:36:52 PM UTC-8, M.R.W Wills wrote:
> 
> >> On Jan 11, 4:06 pm, gavino_himself <visplovesl...@gmail.com> wrote:
> 
> >>
> 
> >>>
> 
> >>
> 
> >>> this takes a little getting used to
> 
> >>
> 
> >>>
> 
> >>
> 
> >>
> 
> >>
> 
> >> When you are used to other languages the "confusing" thing in Forth is
> 
> >>
> 
> >> understanding its total simplicity. It takes a while sink in just how
> 
> >>
> 
> >> *simple* it all is!
> 
> >
> 
> > I vow to read both starting and thinking forth.  I remember Jeff Fox's writing bringing up the simplicity a lot.
> 
> >
> 
> 
> 
> Starting Forth, in particular, represents an obsolete version of Forth. 
> 
> It will only confuse you. You said at one point you had Forth 
> 
> Application Techniques... if you read that and work all the problems 
> 
> you'll be on track.
> 
> 
> 
> Cheers,
> 
> Elizabeth
> 
> 
> 
> -- 
> 
> ==================================================
> 
> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> 
> FORTH Inc.                         +1 310.999.6784
> 
> 5959 West Century Blvd. Suite 700
> 
> Los Angeles, CA 90045
> 
> http://www.forth.com
> 
> 
> 
> "Forth-based products and Services for real-time
> 
> applications since 1973."
> 
> ==================================================

ok cool
I REALLY need to start at the beginning because even knowing howto do a what was it bubble sort as mentioned above is not part of my databank yet.

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

#18988

On Jan 22, 6:49 am, gavino_himself <visplovesl...@gmail.com> wrote:
> On Monday, January 14, 2013 1:46:43 AM UTC-8, Elizabeth D. Rather wrote:
> > On 1/14/13 2:33 PM, gavino_himself wrote:
>
> > > On Friday, January 11, 2013 12:36:52 PM UTC-8, M.R.W Wills wrote:
>
> > >> On Jan 11, 4:06 pm, gavino_himself <visplovesl...@gmail.com> wrote:
>
> > >>> this takes a little getting used to
>
> > >> When you are used to other languages the "confusing" thing in Forth is
>
> > >> understanding its total simplicity. It takes a while sink in just how
>
> > >> *simple* it all is!
>
> > > I vow to read both starting and thinking forth.  I remember Jeff Fox's writing bringing up the simplicity a lot.
>
> > Starting Forth, in particular, represents an obsolete version of Forth.
>
> > It will only confuse you. You said at one point you had Forth
>
> > Application Techniques... if you read that and work all the problems
>
> > you'll be on track.
>
> > Cheers,
>
> > Elizabeth
>
> > --
>
> > ==================================================
>
> > Elizabeth D. Rather   (US & Canada)   800-55-FORTH
>
> > FORTH Inc.                         +1 310.999.6784
>
> > 5959 West Century Blvd. Suite 700
>
> > Los Angeles, CA 90045
>
> >http://www.forth.com
>
> > "Forth-based products and Services for real-time
>
> > applications since 1973."
>
> > ==================================================
>
> ok cool
> I REALLY need to start at the beginning because even knowing howto do a what was it bubble sort as mentioned above is not part of my databank yet.- Hide quoted text -
>
> - Show quoted text -

Yes I would agree. Get the free version of SwiftForth and sit down
with Elizabeth's book, and work through it. There's some nice stuff in
there. I remember the avalanche algorithm from Elizabeth's book, it
was a penny drop moment for me back when I was taking my first steps
in Forth.

Elizabeth's book is available on Amazon. It's a cheap investment if
you are serious about learning Forth.

Regarding bubble sort, wikipedia is your friend: http://en.wikipedia.org/wiki/Bubble_sort

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

#18879

gavino_himself wrote:
> On Friday, January 11, 2013 12:36:52 PM UTC-8, M.R.W Wills wrote:
> > On Jan 11, 4:06 pm, gavino_himself <visplovesl...@gmail.com> wrote:
> >
> > >
> >
> > > this takes a little getting used to
> >
> > >
> >
> >
> >
> > When you are used to other languages the "confusing" thing in Forth is
> >
> > understanding its total simplicity. It takes a while sink in just how
> >
> > *simple* it all is!
>
> I vow to read both starting and thinking forth.  I remember Jeff Fox's writing bringing up
> the simplicity a lot.

Mostly as a reaction to the ANS way of doing things - just load in an
ANS portable library and everything will be fine.  Jeff observed the
results were usually anything but simple.

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

#18884

Ed wrote:
> Mostly as a reaction to the ANS way of doing things - just load in an
> ANS portable library and everything will be fine.  Jeff observed the
> results were usually anything but simple.

Yes, but that's not just the fault of ANS: Make a CPU with many odd 
things, like 20 bit word-addressed memory, and then compile something 
that is designed for 32 bit byte addressed systems.  And then watch it 
fail.  It wasn't just the 32 bit thing, Chuck made it horribly difficult 
to implement ANS Forth on his CPU, apparently on purpose.

IMHO trying to build a web browser means that you first have to get the 
CPU byte addressed 32 or 64 bit, and then see about the rest.  That's a 
deeply rooted assumption, not just in the code the programmers wrote, 
but also in the file formats.

That's how we got those 100x storries.  Yes, it is possible to write a 
program that is 100x faster in machine Forth than in ANS Forth on one of 
Chuck's processors.  Because the CPU actually emulates ANS Forth in a 
very inefficient way.  Now you think, a Forth CPU should be the ideal 
target of ANS Forth?  Yes, it should.  But as Chuck calls all his 
languages Forth, and means "minimalistic stack based language".  It 
might be the worst target for ANS Forth you can imagine, and yes, it is.

The storries were about subcontracters who had been given assigments 
like "write a jpeg decompresser in Forth", not mentioning any particular 
target.  The man wrote a jpeg decompressor for Win32Forth.  And it 
didn't run on i21.  Yeah.  You would have guessed it.  This is a 
management problem.  If you don't know what to do, you can't assign 
tasks.  So people will fail.  And then, as you are an abysmally bad 
manager, you don't take the blame yourself (as manager, it's *all* your 
fault, that's the responsibility of the task), but blame them.  Yes, 
that's how you get a company into the ground.  iTV did, for sure.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#18911

Bernd Paysan wrote:
> Ed wrote:
> > Mostly as a reaction to the ANS way of doing things - just load in an
> > ANS portable library and everything will be fine.  Jeff observed the
> > results were usually anything but simple.
>
> Yes, but that's not just the fault of ANS: Make a CPU with many odd
> things, like 20 bit word-addressed memory, and then compile something
> that is designed for 32 bit byte addressed systems.  And then watch it
> fail.  It wasn't just the 32 bit thing, Chuck made it horribly difficult
> to implement ANS Forth on his CPU, apparently on purpose.
>
> IMHO trying to build a web browser means that you first have to get the
> CPU byte addressed 32 or 64 bit, and then see about the rest.  That's a
> deeply rooted assumption, not just in the code the programmers wrote,
> but also in the file formats.
>
> That's how we got those 100x storries.  Yes, it is possible to write a
> program that is 100x faster in machine Forth than in ANS Forth on one of
> Chuck's processors.  Because the CPU actually emulates ANS Forth in a
> very inefficient way.  Now you think, a Forth CPU should be the ideal
> target of ANS Forth?  Yes, it should.  But as Chuck calls all his
> languages Forth, and means "minimalistic stack based language".  It
> might be the worst target for ANS Forth you can imagine, and yes, it is.
> ...

I don't accept every criticism Jeff made about ANS in his public writings
(and indeed some of it was far too personal) nevertheless I find myself
agreeing that the Forth in Standard Forth is increasingly hard to find.

Take locals - allegedly "optional" in ANS.  Should a Forth Standard expect
Forth CPU's to have the resources to efficiently implement foreign notions
such as locals because the Standard libraries that you load could well be
full of them?

In his "C-Style Structures in ANS Forth" Jeff bemoans the ease with which
ANS programmers can write inefficient code:

    "We always seemed to come back to the issue that the ANS Forth
    Standard had been designed to facilitate the use of portable libraries
    like this, and that they were considered good style by many ANS Forth
    programmers..."

ANS may not be responsible for poorly written code but they provided the tools
and the justification to use them.  I've seen 40-line definitions that would have
been impossible to write, were it not for the 12 locals scattered throughout.
Had that many regular variables been used, it would almost certainly be
regarded as unrepresentative of what Forth could/should be.  But because
ANS condones locals, you've now got to have a CPU that will handle them
and the libraries which use them, and who can say what is good Forth style.
The only sure thing is that ANS Forth is not simple.

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

#18919

On Jan 20, 1:42 am, "Ed" <inva...@nospam.com> wrote:
>
> I don't accept every criticism Jeff made about ANS in his public writings
> (and indeed some of it was far too personal) nevertheless I find myself
> agreeing that the Forth in Standard Forth is increasingly hard to find.
>

Well, in fairness to Jeff, they were just essays on his *personal*
website, reflecting his personal views (some of them controversial,
and some of them a little hard to back up with material evidence IMHO)
so why not?

> Take locals - allegedly "optional" in ANS.

Why "allegedly" option. There's no allegedly about it. They're
optional.

> Should a Forth Standard expect
> Forth CPU's to have the resources to efficiently implement foreign notions
> such as locals because the Standard libraries that you load could well be
> full of them?
>
Of course not. Locals are optional. If the implementer, during the
implementation of his Forth system wants to implement them, he will
implement them in code; that the underlying processor may be a Forth
processor is irrelevant.

> In his "C-Style Structures in ANS Forth" Jeff bemoans the ease with which
> ANS programmers can write inefficient code:
>
>     "We always seemed to come back to the issue that the ANS Forth
>     Standard had been designed to facilitate the use of portable libraries
>     like this, and that they were considered good style by many ANS Forth
>     programmers..."
>
> ANS may not be responsible for poorly written code but they provided the tools
> and the justification to use them.  I've seen 40-line definitions that would have
> been impossible to write, were it not for the 12 locals scattered throughout.
> Had that many regular variables been used, it would almost certainly be
> regarded as unrepresentative of what Forth could/should be.  But because
> ANS condones locals, you've now got to have a CPU that will handle them
> and the libraries which use them, and who can say what is good Forth style.
> The only sure thing is that ANS Forth is not simple.

I don't see any reference to poorly written code in the paragraph from
Jeff that you cite. Regardless, I'm struggling to see the logical leap
that you have taken in assuming that a Forth processor should support
local variables at the machine code/assembly code level; because
that's what we're talking about: assembly code. If your processor is a
Forth processor then you are coding in assembler. In other words, you
are coding at a low level. Why should it support locals?

Extrapolating your argument further (and apologies if I've got the
wrong end of the stick) would you argue that complex words such as
PARSE, EVALUATE, PARSE-WORD etc. should all be supported by the Forth
processor? I mean, they're all standard words too. What about
ENVIRONMENT?

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

#18948

On Jan 20, 2:24 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> ... I'm struggling to see the logical leap
> that you have taken in assuming that a Forth processor should support
> local variables at the machine code/assembly code level; because
> that's what we're talking about: assembly code. If your processor is a
> Forth processor then you are coding in assembler. In other words, you
> are coding at a low level. Why should it support locals?

The MiniForth supported local variables at a hardwarish level (there
were machine instructions specifically for supporting locals, and a
set of pseudo-registers provided for that purpose).

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

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

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

csiph-web