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

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

Loop structures

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

Contents

   Loop structures kenney@cix.compulink.co.uk - 2013-02-06 03:55 -0600
    Re: Loop structures Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-06 04:24 -0600
    Re: Loop structures Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-06 05:38 -0800
    Re: Loop structures Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-06 10:43 -0800
      Re: Loop structures "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-08 03:46 -0500
    Re: Loop structures awegel@arcor.de (Alex Wegel) - 2013-02-06 20:19 +0100
      Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-07 20:27 +1100
        Re: Loop structures Coos Haak <chforth@hccnet.nl> - 2013-02-07 17:03 +0100
          Re: Loop structures awegel@arcor.de (Alex Wegel) - 2013-02-08 00:43 +0100
            Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-09 20:52 +1100
              Re: Loop structures Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-09 18:05 -0600
                Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-10 11:48 +1100
              Re: Loop structures awegel@arcor.de (Alex Wegel) - 2013-02-11 01:41 +0100
                Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-11 12:56 +1100
                  Re: Loop structures "Elizabeth D. Rather" <erather@forth.com> - 2013-02-10 17:54 -1000
                    Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-12 15:11 +1100
                      Re: Loop structures Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-13 09:49 -0600
                  Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-11 23:32 -0800
                    Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-13 12:34 +1100
                      Re: Loop structures "Elizabeth D. Rather" <erather@forth.com> - 2013-02-12 15:49 -1000
                        Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-13 14:48 +1100
                          Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-12 23:02 -0800
                            Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-12 23:29 -0800
                            Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-13 13:35 +0000
                              Re: Loop structures Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-13 15:17 +0100
                              Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-13 09:01 -0800
                                Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-13 20:22 +0000
                                  Re: Loop structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-14 16:29 +0000
                                    Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-14 18:41 +0000
                                      Re: Loop structures Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-14 21:44 +0100
                                        Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-14 21:06 +0000
                                          Re: Loop structures Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-14 23:51 +0100
                                            Re: Loop structures mhx@iae.nl (Marcel Hendrix) - 2013-02-15 00:56 +0200
                                              Re: Loop structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-15 09:53 +0000
                                                Re: Loop structures m.a.m.hendrix@tue.nl - 2013-02-15 03:36 -0800
                                      Re: Loop structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-15 09:44 +0000
                                  Re: Loop structures Lars Brinkhoff <lars.spam@nocrew.org> - 2013-03-04 13:04 +0100
                                    Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 13:22 +0000
                            Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-15 13:09 +1100
                              Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-14 19:21 -0800
                              Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-15 13:01 +0000
                                Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-15 07:51 -0800
                          Re: Loop structures Brad Eckert <hwfwguy@gmail.com> - 2013-02-13 10:51 -0800
                            Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-15 13:11 +1100
                              Re: Loop structures "Elizabeth D. Rather" <erather@forth.com> - 2013-02-14 21:31 -1000
                      Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-13 00:18 -0800
                        Re: Loop structures alberto@hal-pc.org - 2013-02-13 14:27 +0000
                          Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-13 07:08 -0800
                            Re: Loop structures m.a.m.hendrix@tue.nl - 2013-02-13 08:23 -0800
                              Re: Loop structures stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-13 17:32 +0000
                                Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-13 23:17 -0800
                                  Re: Loop structures stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-14 10:53 +0000
                                    Re: Loop structures stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-14 13:42 +0000
                                    Re: Loop structures "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 21:25 -0800
                                  Re: Loop structures "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 21:18 -0800
                              Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-13 23:15 -0800
                        Re: Loop structures mhx@iae.nl (Marcel Hendrix) - 2013-02-14 22:08 +0200
                          Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-14 22:53 -0800
                  Re: Loop structures awegel@arcor.de (Alex Wegel) - 2013-02-12 16:00 +0100
    Re: Loop structures kenney@cix.compulink.co.uk - 2013-02-13 03:49 -0600

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

#19694

Elizabeth D. Rather wrote:
> On 2/12/13 3:34 PM, Ed wrote:
> > Mark Wills wrote:
> >> On Feb 11, 1:56 am, "Ed" <inva...@nospam.com> wrote:
> >>> Alex Wegel wrote:
> >>>> ...
> >>>> But you *do* agree that infinite loops exist (even in forth), and that
> >>>> they differ from the other constructs having been mentioned?
> >>> ...
> >>>> My original point wasn't so much about AGAIN, more about recognizing the
> >>>> infinite loop as a basic looping construct in general.
> >>>
> >>> None of the CS texts I've read mention infinite loops as a fundamental
> >>> construct. When they're discussed they're described in terms of the
> >>> classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
> >>> 1 WHILE...REPEAT.
> >>>
> >>> "Starting FORTH" (first ed.) talks about creating infinite loops with
> >>> BEGIN...0 UNTIL. AFAIK AGAIN is not referenced anywhere.
> >>>
> >>> When this topic came up before some folks pointed out other
> >>> languages would optimize the equivalent of 0 UNTIL into an AGAIN.
> >>> Having a specific construct for infinite loops in these languages
> >>> would thus be redundant.
> >>>
> >>> Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
> >>> but I can't think of a scenario where this would be true.
> >>
> >> It would be faster in my system ;-)
> >>
> >> My system doesn't compile a conditional branch. It compiles an
> >> unconditional branch.
> >>
> >> The definition of AGAIN in my system is:
> >>
> >> : AGAIN ( addr -- )
> >>      COMPILE BRANCH , ; IMMEDIATE
> >>
> >> Addresses in my system are absolute, not relative.
> >
> > So does mine.  But that wasn't the challenge.  Demonstrate - if you can -
> > that using BEGIN.. AGAIN in an application produces a speed improvement
> > over the equivalent BEGIN..0 UNTIL.
> >
> > My contention is that it won't and can't because the fastest scenario is
> > an empty infinite loop - which also happens to be the ultimate time waster.
> > The more useful things you do in the loop, the less time you waste, and
> > the less impact AGAIN or 0 UNTIL will have.
> >
> > The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
> > as I can determine, a wonderful delusion.
>
> Well, but you didn't stipulate a *significant* speed improvement. Mark
> indisputably demonstrated *a* speed improvement by removing an
> unnecessary test.

If the only way Mark can see that speed improvement is by spinning
in an empty loop doing nothing, where is his gain?

> Surely we can agree that AGAIN provides a very minor speed improvement
> on some systems, and a notational improvement, and leave it to folks to
> make individual value judgements about those things. This is far from
> the only such issue in Forth. There's 1+, 2* and 2/, a whole list of
> these little things. Some folks' aesthetics are offended by adding an
> unnecessary word to the system, others by executing an unnecessary
> instruction.

We're not discussing taste or offence, but need.  AGAIN does not occur
frequently and can't be justified in the same manner as the others you
mention.

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

#19696

On Feb 12, 7:48 pm, "Ed" <inva...@nospam.com> wrote:
> Elizabeth D. Rather wrote:
> > On 2/12/13 3:34 PM, Ed wrote:
> > > Mark Wills wrote:
> > >> On Feb 11, 1:56 am, "Ed" <inva...@nospam.com> wrote:
> > >>> Alex Wegel wrote:
> > >>>> ...
> > >>>> But you *do* agree that infinite loops exist (even in forth), and that
> > >>>> they differ from the other constructs having been mentioned?
> > >>> ...
> > >>>> My original point wasn't so much about AGAIN, more about recognizing the
> > >>>> infinite loop as a basic looping construct in general.
>
> > >>> None of the CS texts I've read mention infinite loops as a fundamental
> > >>> construct. When they're discussed they're described in terms of the
> > >>> classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
> > >>> 1 WHILE...REPEAT.
>
> > >>> "Starting FORTH" (first ed.) talks about creating infinite loops with
> > >>> BEGIN...0 UNTIL. AFAIK AGAIN is not referenced anywhere.
>
> > >>> When this topic came up before some folks pointed out other
> > >>> languages would optimize the equivalent of 0 UNTIL into an AGAIN.
> > >>> Having a specific construct for infinite loops in these languages
> > >>> would thus be redundant.
>
> > >>> Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
> > >>> but I can't think of a scenario where this would be true.
>
> > >> It would be faster in my system ;-)
>
> > >> My system doesn't compile a conditional branch. It compiles an
> > >> unconditional branch.
>
> > >> The definition of AGAIN in my system is:
>
> > >> : AGAIN ( addr -- )
> > >>      COMPILE BRANCH , ; IMMEDIATE
>
> > >> Addresses in my system are absolute, not relative.
>
> > > So does mine.  But that wasn't the challenge.  Demonstrate - if you can -
> > > that using BEGIN.. AGAIN in an application produces a speed improvement
> > > over the equivalent BEGIN..0 UNTIL.
>
> > > My contention is that it won't and can't because the fastest scenario is
> > > an empty infinite loop - which also happens to be the ultimate time waster.
> > > The more useful things you do in the loop, the less time you waste, and
> > > the less impact AGAIN or 0 UNTIL will have.
>
> > > The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
> > > as I can determine, a wonderful delusion.
>
> > Well, but you didn't stipulate a *significant* speed improvement. Mark
> > indisputably demonstrated *a* speed improvement by removing an
> > unnecessary test.
>
> If the only way Mark can see that speed improvement is by spinning
> in an empty loop doing nothing, where is his gain?

1. It's shorter, which creates a smaller executable. In an ITC, it's 3
cells (LIT, 0, ?BRANCH) as opposed to 1 (BRANCH). Optimizing compilers
may reduce this to an unconditional jump; many don't do so. An example
for an STC produce 7 instructions vs 1, at 23 and 5 bytes
respectively;

: x begin 0 until ;
see x
: x ( ? -- ? )
\ std call compiles; code=$41B65F len=23 type=1
\ defined in (console)
( $0 )    mov     dword { $-4 ebp } eax             \ 8945FC
( $3 )    and     eax $0                            \ 83E000
( $6 )    sub     ebp $4                            \ 83ED04
( $9 )    add     ebp $4                            \ 83C504
( $C )    test    eax eax                           \ 85C0
( $E )    mov     eax dword { $-4 ebp }             \ 8B45FC
( $11 )   je      ' x                               \ 0F84E9FFFFFF
( $17 )   ret                                       \ C3 ( end )

: y begin again ;
see y
: y ( ? -- ? )
\ std call compiles; code=$41B67B len=5 type=1
\ defined in (console)
( $0 )    jmp     ' x                               \ E9FBFFFFFF
( $5 )    ret                                       \ C3 ( end )


2. It's always consequently faster, regardless of what is inside the
loop. How much faster is the question. An ITC 0 UNTIL suffers 3
entries to the inner interpreter as opposed to 1, and a push/pop for
the literal, and a conditional jump. AGAIN is 1 entry, no stack
movement and an unconditional jump. You can see the overhead of an STC
above.

3. It's less typing.

>
> > Surely we can agree that AGAIN provides a very minor speed improvement
> > on some systems, and a notational improvement, and leave it to folks to
> > make individual value judgements about those things. This is far from
> > the only such issue in Forth. There's 1+, 2* and 2/, a whole list of
> > these little things. Some folks' aesthetics are offended by adding an
> > unnecessary word to the system, others by executing an unnecessary
> > instruction.
>
> We're not discussing taste or offence, but need.  AGAIN does not occur
> frequently and can't be justified in the same manner as the others you
> mention.

AGAIN is used 4 times in the kernel of my compiler, and is a factor in
REPEAT. REPEAT is used 16 times. UNTIL is used twice. Across all the
source, AGAIN appears 58 times in 26 files. REPEAT appears 323 times
in 90 files. UNTIL appears 74 times in 36 files. A little
unscientific, but AGAIN and REPEAT are around 5 times the frequency of
UNTIL in my sources.

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

#19697

On Feb 12, 11:02 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Feb 12, 7:48 pm, "Ed" <inva...@nospam.com> wrote:
>
>
>
>
>
>
>
>
>
> > Elizabeth D. Rather wrote:
> > > On 2/12/13 3:34 PM, Ed wrote:
> > > > Mark Wills wrote:
> > > >> On Feb 11, 1:56 am, "Ed" <inva...@nospam.com> wrote:
> > > >>> Alex Wegel wrote:
> > > >>>> ...
> > > >>>> But you *do* agree that infinite loops exist (even in forth), and that
> > > >>>> they differ from the other constructs having been mentioned?
> > > >>> ...
> > > >>>> My original point wasn't so much about AGAIN, more about recognizing the
> > > >>>> infinite loop as a basic looping construct in general.
>
> > > >>> None of the CS texts I've read mention infinite loops as a fundamental
> > > >>> construct. When they're discussed they're described in terms of the
> > > >>> classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
> > > >>> 1 WHILE...REPEAT.
>
> > > >>> "Starting FORTH" (first ed.) talks about creating infinite loops with
> > > >>> BEGIN...0 UNTIL. AFAIK AGAIN is not referenced anywhere.
>
> > > >>> When this topic came up before some folks pointed out other
> > > >>> languages would optimize the equivalent of 0 UNTIL into an AGAIN.
> > > >>> Having a specific construct for infinite loops in these languages
> > > >>> would thus be redundant.
>
> > > >>> Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
> > > >>> but I can't think of a scenario where this would be true.
>
> > > >> It would be faster in my system ;-)
>
> > > >> My system doesn't compile a conditional branch. It compiles an
> > > >> unconditional branch.
>
> > > >> The definition of AGAIN in my system is:
>
> > > >> : AGAIN ( addr -- )
> > > >>      COMPILE BRANCH , ; IMMEDIATE
>
> > > >> Addresses in my system are absolute, not relative.
>
> > > > So does mine.  But that wasn't the challenge.  Demonstrate - if you can -
> > > > that using BEGIN.. AGAIN in an application produces a speed improvement
> > > > over the equivalent BEGIN..0 UNTIL.
>
> > > > My contention is that it won't and can't because the fastest scenario is
> > > > an empty infinite loop - which also happens to be the ultimate time waster.
> > > > The more useful things you do in the loop, the less time you waste, and
> > > > the less impact AGAIN or 0 UNTIL will have.
>
> > > > The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
> > > > as I can determine, a wonderful delusion.
>
> > > Well, but you didn't stipulate a *significant* speed improvement. Mark
> > > indisputably demonstrated *a* speed improvement by removing an
> > > unnecessary test.
>
> > If the only way Mark can see that speed improvement is by spinning
> > in an empty loop doing nothing, where is his gain?
>
> 1. It's shorter, which creates a smaller executable. In an ITC, it's 3
> cells (LIT, 0, ?BRANCH) as opposed to 1 (BRANCH). Optimizing compilers
> may reduce this to an unconditional jump; many don't do so. An example
> for an STC produce 7 instructions vs 1, at 23 and 5 bytes
> respectively;
>
> : x begin 0 until ;
> see x
> : x ( ? -- ? )
> \ std call compiles; code=$41B65F len=23 type=1
> \ defined in (console)
> ( $0 )    mov     dword { $-4 ebp } eax             \ 8945FC
> ( $3 )    and     eax $0                            \ 83E000
> ( $6 )    sub     ebp $4                            \ 83ED04
> ( $9 )    add     ebp $4                            \ 83C504
> ( $C )    test    eax eax                           \ 85C0
> ( $E )    mov     eax dword { $-4 ebp }             \ 8B45FC
> ( $11 )   je      ' x                               \ 0F84E9FFFFFF
> ( $17 )   ret                                       \ C3 ( end )
>
> : y begin again ;
> see y
> : y ( ? -- ? )
> \ std call compiles; code=$41B67B len=5 type=1
> \ defined in (console)
> ( $0 )    jmp     ' x                               \ E9FBFFFFFF
> ( $5 )    ret                                       \ C3 ( end )
>
> 2. It's always consequently faster, regardless of what is inside the
> loop. How much faster is the question. An ITC 0 UNTIL suffers 3
> entries to the inner interpreter as opposed to 1, and a push/pop for
> the literal, and a conditional jump. AGAIN is 1 entry, no stack
> movement and an unconditional jump. You can see the overhead of an STC
> above.
>
> 3. It's less typing.
>
>
>
> > > Surely we can agree that AGAIN provides a very minor speed improvement
> > > on some systems, and a notational improvement, and leave it to folks to
> > > make individual value judgements about those things. This is far from
> > > the only such issue in Forth. There's 1+, 2* and 2/, a whole list of
> > > these little things. Some folks' aesthetics are offended by adding an
> > > unnecessary word to the system, others by executing an unnecessary
> > > instruction.
>
> > We're not discussing taste or offence, but need.  AGAIN does not occur
> > frequently and can't be justified in the same manner as the others you
> > mention.
>
> AGAIN is used 4 times in the kernel of my compiler, and is a factor in
> REPEAT. REPEAT is used 16 times. UNTIL is used twice. Across all the
> source, AGAIN appears 58 times in 26 files. REPEAT appears 323 times
> in 90 files. UNTIL appears 74 times in 36 files. A little
> unscientific, but AGAIN and REPEAT are around 5 times the frequency of
> UNTIL in my sources.

Benchmark 1: AGAIN is an unconditional branch.

-------------------------
Test time including overhead               ms     times     ns (each)
Eratosthenes sieve 1899 Primes            108     8190000      13
Fibonacci recursion ( 35 -> 9227465 )      58     9227430       6
Hoare's quick sort (reverse order)        108     2000000      54
Generate random numbers (1024 kb array)    81     262144      308
LZ77 Comp. (400 kb Random Data Mem>Mem)   121     1
Dhrystone (integer)                        71     500000      142
7042253 Dhrystones/sec
Total:                                    553     1
APP mem: 113,865, CODE mem: 15,253, SYS mem: 5,488 Total: 134,606
-------------------------

Benchmark 2: AGAIN is 0 UNTIL.

-------------------------
Test time including overhead               ms     times     ns (each)
Eratosthenes sieve 1899 Primes            130     8190000      15
Fibonacci recursion ( 35 -> 9227465 )      57     9227430       6
Hoare's quick sort (reverse order)        127     2000000      63
Generate random numbers (1024 kb array)    82     262144      312
LZ77 Comp. (400 kb Random Data Mem>Mem)   123     1
Dhrystone (integer)                        72     500000      144
6944444 Dhrystones/sec
Total:                                    600     1
APP mem: 113,865, CODE mem: 15,397, SYS mem: 5,488 Total: 134,750
-------------------------

The benchmark doesn't make much use of AGAIN or REPEAT as can be seen
from the 144 extra bytes of code generated; AGAIN is unused, REPEAT
appears 8 times. The difference in run time is 47 ms. Given the small
variance between repeated runs of the same benchmark, let's round it
down and call it 5% slower. I'd say it justifies using AGAIN in place
of 0 UNTIL in this compiler.

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

#19704

In article <3a568256-97d5-4a08-a167-65cccac76b38@z9g2000vbx.googlegroups.com>,
Alex McDonald  <blog@rivadpm.com> wrote:
>On Feb 12, 7:48 pm, "Ed" <inva...@nospam.com> wrote:
>> Elizabeth D. Rather wrote:
>> > On 2/12/13 3:34 PM, Ed wrote:
>> > > Mark Wills wrote:
>> > >> On Feb 11, 1:56 am, "Ed" <inva...@nospam.com> wrote:
>> > >>> Alex Wegel wrote:
>> > >>>> ...
>> > >>>> But you *do* agree that infinite loops exist (even in forth), and that
>> > >>>> they differ from the other constructs having been mentioned?
>> > >>> ...
>> > >>>> My original point wasn't so much about AGAIN, more about
>recognizing the
>> > >>>> infinite loop as a basic looping construct in general.
>>
>> > >>> None of the CS texts I've read mention infinite loops as a fundamental
>> > >>> construct. When they're discussed they're described in terms of the
>> > >>> classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
>> > >>> 1 WHILE...REPEAT.
>>
>> > >>> "Starting FORTH" (first ed.) talks about creating infinite loops with
>> > >>> BEGIN...0 UNTIL. AFAIK AGAIN is not referenced anywhere.
>>
>> > >>> When this topic came up before some folks pointed out other
>> > >>> languages would optimize the equivalent of 0 UNTIL into an AGAIN.
>> > >>> Having a specific construct for infinite loops in these languages
>> > >>> would thus be redundant.
>>
>> > >>> Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
>> > >>> but I can't think of a scenario where this would be true.
>>
>> > >> It would be faster in my system ;-)
>>
>> > >> My system doesn't compile a conditional branch. It compiles an
>> > >> unconditional branch.
>>
>> > >> The definition of AGAIN in my system is:
>>
>> > >> : AGAIN ( addr -- )
>> > >>      COMPILE BRANCH , ; IMMEDIATE
>>
>> > >> Addresses in my system are absolute, not relative.
>>
>> > > So does mine.  But that wasn't the challenge.  Demonstrate - if you can -
>> > > that using BEGIN.. AGAIN in an application produces a speed improvement
>> > > over the equivalent BEGIN..0 UNTIL.
>>
>> > > My contention is that it won't and can't because the fastest scenario is
>> > > an empty infinite loop - which also happens to be the ultimate
>time waster.
>> > > The more useful things you do in the loop, the less time you waste, and
>> > > the less impact AGAIN or 0 UNTIL will have.
>>
>> > > The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
>> > > as I can determine, a wonderful delusion.
>>
>> > Well, but you didn't stipulate a *significant* speed improvement. Mark
>> > indisputably demonstrated *a* speed improvement by removing an
>> > unnecessary test.
>>
>> If the only way Mark can see that speed improvement is by spinning
>> in an empty loop doing nothing, where is his gain?
>
>1. It's shorter, which creates a smaller executable. In an ITC, it's 3
>cells (LIT, 0, ?BRANCH) as opposed to 1 (BRANCH). Optimizing compilers
>may reduce this to an unconditional jump; many don't do so. An example
>for an STC produce 7 instructions vs 1, at 23 and 5 bytes
>respectively;
>
>: x begin 0 until ;
>see x
>: x ( ? -- ? )
>\ std call compiles; code=$41B65F len=23 type=1
>\ defined in (console)
>( $0 )    mov     dword { $-4 ebp } eax             \ 8945FC
>( $3 )    and     eax $0                            \ 83E000
>( $6 )    sub     ebp $4                            \ 83ED04
>( $9 )    add     ebp $4                            \ 83C504
>( $C )    test    eax eax                           \ 85C0
>( $E )    mov     eax dword { $-4 ebp }             \ 8B45FC
>( $11 )   je      ' x                               \ 0F84E9FFFFFF
>( $17 )   ret                                       \ C3 ( end )
>
>: y begin again ;
>see y
>: y ( ? -- ? )
>\ std call compiles; code=$41B67B len=5 type=1
>\ defined in (console)
>( $0 )    jmp     ' x                               \ E9FBFFFFFF
>( $5 )    ret                                       \ C3 ( end )
>
>
>2. It's always consequently faster, regardless of what is inside the
>loop. How much faster is the question. An ITC 0 UNTIL suffers 3
>entries to the inner interpreter as opposed to 1, and a push/pop for
>the literal, and a conditional jump. AGAIN is 1 entry, no stack
>movement and an unconditional jump. You can see the overhead of an STC
>above.
>
>3. It's less typing.
>
>>
>> > Surely we can agree that AGAIN provides a very minor speed improvement
>> > on some systems, and a notational improvement, and leave it to folks to
>> > make individual value judgements about those things. This is far from
>> > the only such issue in Forth. There's 1+, 2* and 2/, a whole list of
>> > these little things. Some folks' aesthetics are offended by adding an
>> > unnecessary word to the system, others by executing an unnecessary
>> > instruction.
>>
>> We're not discussing taste or offence, but need.  AGAIN does not occur
>> frequently and can't be justified in the same manner as the others you
>> mention.
>
>AGAIN is used 4 times in the kernel of my compiler, and is a factor in
>REPEAT. REPEAT is used 16 times. UNTIL is used twice. Across all the
>source, AGAIN appears 58 times in 26 files. REPEAT appears 323 times
>in 90 files. UNTIL appears 74 times in 36 files. A little
>unscientific, but AGAIN and REPEAT are around 5 times the frequency of
>UNTIL in my sources.

With respect: In my ITC system supplying AGAIN costs 9 CELLS (72 bytes)
for the header alone. Earning that back is not easy. AGAIN occurs
only once in my library and not at all in my Forth kernel, of course.
(Because it is a compiling word, and I've no compiling words that
are factors of other compiler words, which is a matter of cleanliness
others may not choose to adhere to. If you want good diagnostics or
nice decompilation you may be forced to, though.)
Come to think of it: AGAIN is a candidate for becoming a loadable
extension like WORD FIND already are.

So your analysis is quite skewed to a particular point of view.

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]

#19705

Albert van der Horst wrote:
> With respect: In my ITC system supplying AGAIN costs 9 CELLS (72 bytes)
> for the header alone. Earning that back is not easy. AGAIN occurs
> only once in my library and not at all in my Forth kernel, of course.

AGAIN usually is a factor of REPEAT, which essentially is

: repeat postpone again postpone then ;

I.e. the cost of having AGAIN is the header (link+align(count+5 bytes)+cfa) 
plus the cell in REPEAT, which postpones AGAIN instead of inlining AGAIN.

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

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

#19710

On Feb 13, 5:35 am, alb...@spenarnc.xs4all.nl (Albert van der Horst)
wrote:
> In article <3a568256-97d5-4a08-a167-65cccac76...@z9g2000vbx.googlegroups.com>,
> Alex McDonald  <b...@rivadpm.com> wrote:
>
>
>
>
>
>
>
>
>
> >On Feb 12, 7:48 pm, "Ed" <inva...@nospam.com> wrote:
> >> Elizabeth D. Rather wrote:
> >> > On 2/12/13 3:34 PM, Ed wrote:
> >> > > Mark Wills wrote:
> >> > >> On Feb 11, 1:56 am, "Ed" <inva...@nospam.com> wrote:
> >> > >>> Alex Wegel wrote:
> >> > >>>> ...
> >> > >>>> But you *do* agree that infinite loops exist (even in forth), and that
> >> > >>>> they differ from the other constructs having been mentioned?
> >> > >>> ...
> >> > >>>> My original point wasn't so much about AGAIN, more about
> >recognizing the
> >> > >>>> infinite loop as a basic looping construct in general.
>
> >> > >>> None of the CS texts I've read mention infinite loops as a fundamental
> >> > >>> construct. When they're discussed they're described in terms of the
> >> > >>> classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
> >> > >>> 1 WHILE...REPEAT.
>
> >> > >>> "Starting FORTH" (first ed.) talks about creating infinite loops with
> >> > >>> BEGIN...0 UNTIL. AFAIK AGAIN is not referenced anywhere.
>
> >> > >>> When this topic came up before some folks pointed out other
> >> > >>> languages would optimize the equivalent of 0 UNTIL into an AGAIN.
> >> > >>> Having a specific construct for infinite loops in these languages
> >> > >>> would thus be redundant.
>
> >> > >>> Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
> >> > >>> but I can't think of a scenario where this would be true.
>
> >> > >> It would be faster in my system ;-)
>
> >> > >> My system doesn't compile a conditional branch. It compiles an
> >> > >> unconditional branch.
>
> >> > >> The definition of AGAIN in my system is:
>
> >> > >> : AGAIN ( addr -- )
> >> > >> COMPILE BRANCH , ; IMMEDIATE
>
> >> > >> Addresses in my system are absolute, not relative.
>
> >> > > So does mine. But that wasn't the challenge. Demonstrate - if you can -
> >> > > that using BEGIN.. AGAIN in an application produces a speed improvement
> >> > > over the equivalent BEGIN..0 UNTIL.
>
> >> > > My contention is that it won't and can't because the fastest scenario is
> >> > > an empty infinite loop - which also happens to be the ultimate
> >time waster.
> >> > > The more useful things you do in the loop, the less time you waste, and
> >> > > the less impact AGAIN or 0 UNTIL will have.
>
> >> > > The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
> >> > > as I can determine, a wonderful delusion.
>
> >> > Well, but you didn't stipulate a *significant* speed improvement. Mark
> >> > indisputably demonstrated *a* speed improvement by removing an
> >> > unnecessary test.
>
> >> If the only way Mark can see that speed improvement is by spinning
> >> in an empty loop doing nothing, where is his gain?
>
> >1. It's shorter, which creates a smaller executable. In an ITC, it's 3
> >cells (LIT, 0, ?BRANCH) as opposed to 1 (BRANCH). Optimizing compilers
> >may reduce this to an unconditional jump; many don't do so. An example
> >for an STC produce 7 instructions vs 1, at 23 and 5 bytes
> >respectively;
>
> >: x begin 0 until ;
> >see x
> >: x ( ? -- ? )
> >\ std call compiles; code=$41B65F len=23 type=1
> >\ defined in (console)
> >( $0 )    mov     dword { $-4 ebp } eax             \ 8945FC
> >( $3 )    and     eax $0                            \ 83E000
> >( $6 )    sub     ebp $4                            \ 83ED04
> >( $9 )    add     ebp $4                            \ 83C504
> >( $C )    test    eax eax                           \ 85C0
> >( $E )    mov     eax dword { $-4 ebp }             \ 8B45FC
> >( $11 )   je      ' x                               \ 0F84E9FFFFFF
> >( $17 )   ret                                       \ C3 ( end )
>
> >: y begin again ;
> >see y
> >: y ( ? -- ? )
> >\ std call compiles; code=$41B67B len=5 type=1
> >\ defined in (console)
> >( $0 )    jmp     ' x                               \ E9FBFFFFFF
> >( $5 )    ret                                       \ C3 ( end )
>
> >2. It's always consequently faster, regardless of what is inside the
> >loop. How much faster is the question. An ITC 0 UNTIL suffers 3
> >entries to the inner interpreter as opposed to 1, and a push/pop for
> >the literal, and a conditional jump. AGAIN is 1 entry, no stack
> >movement and an unconditional jump. You can see the overhead of an STC
> >above.
>
> >3. It's less typing.
>
> >> > Surely we can agree that AGAIN provides a very minor speed improvement
> >> > on some systems, and a notational improvement, and leave it to folks to
> >> > make individual value judgements about those things. This is far from
> >> > the only such issue in Forth. There's 1+, 2* and 2/, a whole list of
> >> > these little things. Some folks' aesthetics are offended by adding an
> >> > unnecessary word to the system, others by executing an unnecessary
> >> > instruction.
>
> >> We're not discussing taste or offence, but need. AGAIN does not occur
> >> frequently and can't be justified in the same manner as the others you
> >> mention.
>
> >AGAIN is used 4 times in the kernel of my compiler, and is a factor in
> >REPEAT. REPEAT is used 16 times. UNTIL is used twice. Across all the
> >source, AGAIN appears 58 times in 26 files. REPEAT appears 323 times
> >in 90 files. UNTIL appears 74 times in 36 files. A little
> >unscientific, but AGAIN and REPEAT are around 5 times the frequency of
> >UNTIL in my sources.
>
> With respect: In my ITC system supplying AGAIN costs 9 CELLS (72 bytes)
> for the header alone. Earning that back is not easy. AGAIN occurs
> only once in my library and not at all in my Forth kernel, of course.
> (Because it is a compiling word, and I've no compiling words that
> are factors of other compiler words, which is a matter of cleanliness
> others may not choose to adhere to. If you want good diagnostics or
> nice decompilation you may be forced to, though.)
> Come to think of it: AGAIN is a candidate for becoming a loadable
> extension like WORD FIND already are.

How do you implement REPEAT?

>
> So your analysis is quite skewed to a particular point of view.

Of course it is; I clearly didn't claim otherwise.

>
> Groetjes Albert
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=nhttp://home.hccnet.nl/a.w.m.van.der.horst

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

#19717

In article <4fd62c8b-0366-4aa9-b940-cc76eae38d3b@z4g2000vbz.googlegroups.com>,
Alex McDonald  <blog@rivadpm.com> wrote:
>On Feb 13, 5:35 am, alb...@spenarnc.xs4all.nl (Albert van der Horst)
>wrote:
>>
>> With respect: In my ITC system supplying AGAIN costs 9 CELLS (72 bytes)
>> for the header alone. Earning that back is not easy. AGAIN occurs
>> only once in my library and not at all in my Forth kernel, of course.
>> (Because it is a compiling word, and I've no compiling words that
>> are factors of other compiler words, which is a matter of cleanliness
>> others may not choose to adhere to. If you want good diagnostics or
>> nice decompilation you may be forced to, though.)
>> Come to think of it: AGAIN is a candidate for becoming a loadable
>> extension like WORD FIND already are.
>
>How do you implement REPEAT?

: REPEAT 'BRANCH , BACK) FORWARD) ; IMMEDIATE
and e.g.
: IF '0BRANCH , (FORWARD ; IMMEDIATE
which happens to be the same as WHILE, but no longer if you
add security.

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

#19731

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>: IF '0BRANCH , (FORWARD ; IMMEDIATE
>which happens to be the same as WHILE, but no longer if you
>add security.

Nor if you want your Forth to be ANS Forth compliant.

- 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 2013: http://www.euroforth.org/ef13/

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

#19732

In article <2013Feb14.172958@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>: IF '0BRANCH , (FORWARD ; IMMEDIATE
>>which happens to be the same as WHILE, but no longer if you
>>add security.
>
>Nor if you want your Forth to be ANS Forth compliant.

It is well known that security is not ANS Forth compliant.


Systems that supply security, mostly have a means to defeat it.

E.g.
NO-SECURITY
: test  BEGIN .. WHILE .. WHILE .. REPEAT .. THEN .. ;
DO-SECURITY

>
>- anton

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]

#19734

Albert van der Horst wrote:
> It is well known that security is not ANS Forth compliant.

The thing below has nothing to do with security.

> Systems that supply security, mostly have a means to defeat it.
> 
> E.g.
> NO-SECURITY
> : test  BEGIN .. WHILE .. WHILE .. REPEAT .. THEN .. ;
> DO-SECURITY

And what?  That is specified to be a correct ANS Forth control structure, 
and it can be made securey by checkin the prerequisites.

: while ( dest-sys -- source-sys dest-sys )
  dup dest?  postpone if   1 cs-roll ;

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

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

#19735

In article <kfjibh$jvj$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Albert van der Horst wrote:
>> It is well known that security is not ANS Forth compliant.
>
>The thing below has nothing to do with security.
>
>> Systems that supply security, mostly have a means to defeat it.
>>
>> E.g.
>> NO-SECURITY
>> : test  BEGIN .. WHILE .. WHILE .. REPEAT .. THEN .. ;
>> DO-SECURITY
>
>And what?  That is specified to be a correct ANS Forth control structure,
>and it can be made securey by checkin the prerequisites.
>
>: while ( dest-sys -- source-sys dest-sys )
>  dup dest?  postpone if   1 cs-roll ;

That would defeat the purpose of this security feature.
It is intended for people like me. If I write two whiles
between BEGIN and REPEAT, I want a warning because I'm
making a mistake.

>
>--
>Bernd Paysan

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]

#19739

Albert van der Horst wrote:
> That would defeat the purpose of this security feature.
> It is intended for people like me. If I write two whiles
> between BEGIN and REPEAT, I want a warning because I'm
> making a mistake.

You don't make a mistake if you close the second WHILE with a THEN (by 
definition of how that structure is supposed to work).  If you don't, you 
will generate an error, e.g. in Gforth:

: test begin while while repeat ; 
:4: unstructured 
: test begin while while repeat >>>;<<<
Backtrace:
$7F6DCDB7E008 throw 
$7F6DCDB91000 c(abort") 
$7F6DCDBA05D8 def? 
$7F6DCDB88D98 ;-hook 

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

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

#19741

Bernd Paysan <bernd.paysan@gmx.de> writes Re: Loop structures

> Albert van der Horst wrote:
>> That would defeat the purpose of this security feature.
>> It is intended for people like me. If I write two whiles
>> between BEGIN and REPEAT, I want a warning because I'm
>> making a mistake.
>
> You don't make a mistake if you close the second WHILE with a THEN (by 
> definition of how that structure is supposed to work).  If you don't, you 
> will generate an error, e.g. in Gforth:

> : test begin while while repeat ; 
> :4: unstructured 
> : test begin while while repeat >>>;<<<

OK, but what's wrong with this?

: test begin repeat ;
:1: expected orig
: test begin >>>repeat<<< ;
Backtrace:
$7EBA2B0C throw
$7EBAB874 c(abort")
$7EBABEE4 orig?
$7EBAC0F0 THEN

In iForth:

FORTH> : test begin repeat ;   ok
FORTH> ' test idis
$01402640  : [trashed]
$0140264A  pop           rbx
$0140264B  lea           rax, [rax 0 +] qword
$01402650  jmp           $01402650 offset SHORT
$01402652  push          rbx
$01402653  ;
FORTH>

Perfect reasonable: REPEAT is the same as AGAIN.

-marcel

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

#19757

mhx@iae.nl (Marcel Hendrix) writes:
>Perfect reasonable: REPEAT is the same as AGAIN.

Not in ANS Forth.  Already the stack effects are different:

6.2.0700 AGAIN  Compilation: ( C: dest -- )
6.1.2140 REPEAT Compilation: ( C: orig dest -- )

E.g., this is a compliant program:

: foo if begin repeat ;

A compliant system should understand it, but iForth 2.1 says:

FORTH> : foo if begin repeat ; 
Error -22 
[;] : Structure not balanced ? 

- 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 2013: http://www.euroforth.org/ef13/

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

#19759

On Friday, February 15, 2013 10:53:31 AM UTC+1, Anton Ertl wrote:
[..]
> E.g., this is a compliant program: 
>  : foo if begin repeat ; 
> A compliant system should understand it, but iForth 2.1 says: 
> FORTH> : foo if begin repeat ; 
> Error -22 [;] : Structure not balanced ? 

You have a twisted sense of humor. 

-marcel

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

#19756

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2013Feb14.172958@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>: IF '0BRANCH , (FORWARD ; IMMEDIATE
>>>which happens to be the same as WHILE, but no longer if you
>>>add security.
>>
>>Nor if you want your Forth to be ANS Forth compliant.
>
>It is well known that security is not ANS Forth compliant.

WHILE as an alias for IF is not ANS compliant without security, either.

Concerning security, it is certainly compliant to check the type of
CS-Items and whether the CS is balanced:

: foo if again ; 
:3: expected dest 
: foo if >>>again<<< ;
...
: bar begin ; 
:4: unstructured 
: bar begin >>>;<<<
...

- 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 2013: http://www.euroforth.org/ef13/

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

#20241

Albert van der Horst wrote:
> >How do you implement REPEAT?
>
> : REPEAT 'BRANCH , BACK) FORWARD) ; IMMEDIATE
> and e.g.
> : IF '0BRANCH , (FORWARD ; IMMEDIATE

Silly question, but I'm curious:

Are these (BACK BACK) (FORWARD FORWARD) words a common alternative to
the Forth83 <MARK <RESOLVE >MARK >RESOLVE words?

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

#20245

In article <85sj4bid5l.fsf@junk.nocrew.org>,
Lars Brinkhoff  <lars.spam@nocrew.org> wrote:
>Albert van der Horst wrote:
>> >How do you implement REPEAT?
>>
>> : REPEAT 'BRANCH , BACK) FORWARD) ; IMMEDIATE
>> and e.g.
>> : IF '0BRANCH , (FORWARD ; IMMEDIATE
>
>Silly question, but I'm curious:
>
>Are these (BACK BACK) (FORWARD FORWARD) words a common alternative to
>the Forth83 <MARK <RESOLVE >MARK >RESOLVE words?

You tell me! I don't have Forth83, but the source of ciforth is for
your perusal. My impression is that I reinvented a rather
obvious technique.

: (FORWARD HERE   _   , ;
: FORWARD) HERE OVER CELL+ - SWAP ! ;

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]

#19744

Alex McDonald wrote:
> On Feb 12, 7:48 pm, "Ed" <inva...@nospam.com> wrote:
> > ...
> > If the only way Mark can see that speed improvement is by spinning
> > in an empty loop doing nothing, where is his gain?
>
> 1. It's shorter, which creates a smaller executable.

Good to see you promoting the virtues of small executables!

Given the number of times AGAIN or 0 UNTIL is used in applications,
I'd say the saving is insignificant.

> In an ITC, it's 3
> cells (LIT, 0, ?BRANCH) as opposed to 1 (BRANCH). Optimizing compilers
> may reduce this to an unconditional jump; many don't do so. An example
> for an STC produce 7 instructions vs 1, at 23 and 5 bytes
> respectively;
>
> : x begin 0 until ;
> ...
>
> : y begin again ;
> ...

    "Efficiency = (output/input) * 100%"

In both examples no useful work is done and the efficiency is 0.
Where is your gain?

> 3. It's less typing.

Pales into insignificance compared with DUP SWAP OVER etc.

> AGAIN is used 4 times in the kernel of my compiler, and is a factor in
> REPEAT. REPEAT is used 16 times. UNTIL is used twice. Across all the
> source, AGAIN appears 58 times in 26 files. REPEAT appears 323 times
> in 90 files. UNTIL appears 74 times in 36 files. A little
> unscientific, but AGAIN and REPEAT are around 5 times the frequency of
> UNTIL in my sources.

That you chose to provide AGAIN and use it in REPEAT is irrelevent.
ANS does not require it.

Excluding REPEAT, replace all instances of AGAIN with 0 UNTIL and
report whether there is any practical difference.

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

#19746

On Feb 14, 6:09 pm, "Ed" <inva...@nospam.com> wrote:
> Alex McDonald wrote:
> > On Feb 12, 7:48 pm, "Ed" <inva...@nospam.com> wrote:
> > > ...
> > > If the only way Mark can see that speed improvement is by spinning
> > > in an empty loop doing nothing, where is his gain?
>
> > 1. It's shorter, which creates a smaller executable.
>
> Good to see you promoting the virtues of small executables!
>
> Given the number of times AGAIN or 0 UNTIL is used in applications,
> I'd say the saving is insignificant.

Until you factor in REPEAT.

>
> > In an ITC, it's 3
> > cells (LIT, 0, ?BRANCH) as opposed to 1 (BRANCH). Optimizing compilers
> > may reduce this to an unconditional jump; many don't do so. An example
> > for an STC produce 7 instructions vs 1, at 23 and 5 bytes
> > respectively;
>
> > : x begin 0 until ;
> > ...
>
> > : y begin again ;
> > ...
>
>     "Efficiency = (output/input) * 100%"
>
> In both examples no useful work is done and the efficiency is 0.
> Where is your gain?
>

You snipped the point of this; which was to show the code generated.
It is much longer in terms of bytes and CPU resources. Since AGAIN and
REPEAT are looping constructs, every execution consumes CPU, branch
predictor and cache resources for those chips that have such things.
Over many m(b)illions it becomes significant, as I showed in the micro
benchmarks.

> > 3. It's less typing.
>
> Pales into insignificance compared with DUP SWAP OVER etc.
>
> > AGAIN is used 4 times in the kernel of my compiler, and is a factor in
> > REPEAT. REPEAT is used 16 times. UNTIL is used twice. Across all the
> > source, AGAIN appears 58 times in 26 files. REPEAT appears 323 times
> > in 90 files. UNTIL appears 74 times in 36 files. A little
> > unscientific, but AGAIN and REPEAT are around 5 times the frequency of
> > UNTIL in my sources.
>
> That you chose to provide AGAIN and use it in REPEAT is irrelevent.
> ANS does not require it.
>
> Excluding REPEAT, replace all instances of AGAIN with 0 UNTIL and
> report whether there is any practical difference.

No.

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

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

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

csiph-web