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 3 of 3 — ← Prev page 1 2 [3]

#19760

In article <kfk5g0$r3l$1@speranza.aioe.org>, Ed <invalid@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.

The wording of this rebuttal shows that you have followed the
course `communication for software professionals' (like me).
The politeness doesn't make it less devastating.

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]

#19763

On Feb 15, 5:01 am, alb...@spenarnc.xs4all.nl (Albert van der Horst)
wrote:
> In article <kfk5g0$r3...@speranza.aioe.org>, 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.
>
> The wording of this rebuttal shows that you have followed the
> course `communication for software professionals' (like me).
> The politeness doesn't make it less devastating.

Does it include a section entitled "Moving the Goalposts"? But I
REPEAT myself.

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

#19715

On Tuesday, February 12, 2013 8:48:37 PM UTC-7, Ed wrote:
> AGAIN does not occur
> frequently and can't be justified in the same manner as the others you
> mention.

I use it all the time in loops that have multiple EXITs.

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

#19745

Brad Eckert wrote:
> On Tuesday, February 12, 2013 8:48:37 PM UTC-7, Ed wrote:
> > AGAIN does not occur
> > frequently and can't be justified in the same manner as the others you
> > mention.
>
> I use it all the time in loops that have multiple EXITs.

You haven't mentioned how frequently that is relative to the
rest of the code you write, and whether

: AGAIN postpone 0 postpone until ; immediate

would be just as effective?

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

#19755

On 2/14/13 4:11 PM, Ed wrote:
> Brad Eckert wrote:
>> On Tuesday, February 12, 2013 8:48:37 PM UTC-7, Ed wrote:
>>> AGAIN does not occur
>>> frequently and can't be justified in the same manner as the others you
>>> mention.
>>
>> I use it all the time in loops that have multiple EXITs.
>
> You haven't mentioned how frequently that is relative to the
> rest of the code you write, and whether
>
> : AGAIN postpone 0 postpone until ; immediate
>
> would be just as effective?

No. Neither in time nor in space.

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]

#19699

On Feb 13, 1:34 am, "Ed" <inva...@nospam.com> wrote:
>
> The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
> as I can determine, a wonderful delusion.- Hide quoted text -
>

Running on a 3mhz 1981 Texas Instruments TI-99/4A, with a 1976 TMS9900
processor, with CPU ram on an 8-bit (i.e multiplexed) bus. Timed with
a Casio ILLUMINATOR (oh yes!) wrist watch (water resistant, too). Hey,
it's not scientific unless you note your measurement instruments :-)

: test1 0 begin dup $. 1- again ; ( 167 seconds)
: test2 0 begin dup $. 1- dup 0= until ; ( 174 seconds)

Making test1 4% faster than test2.

UNTIL needs an argument to test, and that adds to the overhead. It's
not *just* that UNTIL does a conditional test, something has be on the
stack to test. That adds to the overhead.

So yes, I'd say AGAIN is measurably faster than 0= UNTIL; 4% faster in
fact.

The utility of AGAIN as apposed to 0= UNTIL is a matter of personal
taste, I guess. That it's faster is not open to debate, IMHO.

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

#19706

In article <ffc60550-d058-4779-8214-f2f7a6bfa2fb@hq4g2000vbb.googlegroups.com>, Mark Wills <forthfreak@gmail.com> wrote:
>On Feb 13, 1:34=A0am, "Ed" <inva...@nospam.com> wrote:
>>
>> The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
>> as I can determine, a wonderful delusion.- Hide quoted text -
>>
>
>Running on a 3mhz 1981 Texas Instruments TI-99/4A, with a 1976 TMS9900
>processor, with CPU ram on an 8-bit (i.e multiplexed) bus. Timed with
>a Casio ILLUMINATOR (oh yes!) wrist watch (water resistant, too). Hey,
>it's not scientific unless you note your measurement instruments :-)
>
>: test1 0 begin dup $. 1- again ; ( 167 seconds)
>: test2 0 begin dup $. 1- dup 0=3D until ; ( 174 seconds)
>
>Making test1 4% faster than test2.
>
>UNTIL needs an argument to test, and that adds to the overhead. It's
>not *just* that UNTIL does a conditional test, something has be on the
>stack to test. That adds to the overhead.
>
>So yes, I'd say AGAIN is measurably faster than 0=3D UNTIL; 4% faster in
>fact.
>
>The utility of AGAIN as apposed to 0=3D UNTIL is a matter of personal
>taste, I guess. That it's faster is not open to debate, IMHO.

How does test1 terminate? or did you timed until it printed 0?

alberto

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

#19707

On Feb 13, 2:27 pm, albe...@hal-pc.org wrote:
> In article <ffc60550-d058-4779-8214-f2f7a6bfa...@hq4g2000vbb.googlegroups.com>, Mark Wills <forthfr...@gmail.com> wrote:
>
>
>
>
>
> >On Feb 13, 1:34=A0am, "Ed" <inva...@nospam.com> wrote:
>
> >> The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
> >> as I can determine, a wonderful delusion.- Hide quoted text -
>
> >Running on a 3mhz 1981 Texas Instruments TI-99/4A, with a 1976 TMS9900
> >processor, with CPU ram on an 8-bit (i.e multiplexed) bus. Timed with
> >a Casio ILLUMINATOR (oh yes!) wrist watch (water resistant, too). Hey,
> >it's not scientific unless you note your measurement instruments :-)
>
> >: test1 0 begin dup $. 1- again ; ( 167 seconds)
> >: test2 0 begin dup $. 1- dup 0=3D until ; ( 174 seconds)
>
> >Making test1 4% faster than test2.
>
> >UNTIL needs an argument to test, and that adds to the overhead. It's
> >not *just* that UNTIL does a conditional test, something has be on the
> >stack to test. That adds to the overhead.
>
> >So yes, I'd say AGAIN is measurably faster than 0=3D UNTIL; 4% faster in
> >fact.
>
> >The utility of AGAIN as apposed to 0=3D UNTIL is a matter of personal
> >taste, I guess. That it's faster is not open to debate, IMHO.
>
> How does test1 terminate? or did you timed until it printed 0?
>
> alberto- Hide quoted text -
>
> - Show quoted text -

Just timed it by hand with a stop-watch! Nevertheless, even early in
the morning, and on only one cup of coffee, the 'operator error' would
be considerably less than the 4 second delta that I observed ;-)

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

#19709

> > - Show quoted text - Just timed it by hand with a stop-watch! 

Are you telling us that on your system EMIT and TYPE are comparable in speed to a BRANCH ( again )? It must be, because you execute one AGAIN for every TYPE (printing the index), and see a difference. I do not doubt your measurement, but maybe you should do it again a few times. The results would be preposterous for a desktop Forth (TYPE would completely swamp anything else done in the loop).

-marcel

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

#19711

On Wed, 13 Feb 2013 08:23:06 -0800 (PST), m.a.m.hendrix@tue.nl wrote:

>> > - Show quoted text - Just timed it by hand with a stop-watch!=20
>
>Are you telling us that on your system EMIT and TYPE are comparable in spee=
>d to a BRANCH ( again )? It must be, because you execute one AGAIN for ever=
>y TYPE (printing the index), and see a difference. I do not doubt your meas=
>urement, but maybe you should do it again a few times. The results would be=
> preposterous for a desktop Forth (TYPE would completely swamp anything els=
>e done in the loop).

It's the angels dancing on the head of a pin problem.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#19724

On Feb 13, 5:32 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Wed, 13 Feb 2013 08:23:06 -0800 (PST), m.a.m.hend...@tue.nl wrote:
> >> > - Show quoted text - Just timed it by hand with a stop-watch!=20
>
> >Are you telling us that on your system EMIT and TYPE are comparable in spee=
> >d to a BRANCH ( again )? It must be, because you execute one AGAIN for ever=
> >y TYPE (printing the index), and see a difference. I do not doubt your meas=
> >urement, but maybe you should do it again a few times. The results would be=
> > preposterous for a desktop Forth (TYPE would completely swamp anything els=
> >e done in the loop).
>
> It's the angels dancing on the head of a pin problem.
>
> Stephen
>
> --
> Stephen Pelc, stephen...@mpeforth.com
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web:http://www.mpeforth.com- free VFX Forth downloads

I had to resort to Wikipedia to decode this.

"In modern usage, this question also serves as a metaphor for wasting
time debating topics of no practical value."

Well, okay then.

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

#19726

On Wed, 13 Feb 2013 23:17:32 -0800 (PST), Mark Wills
<forthfreak@gmail.com> wrote:

>> It's the angels dancing on the head of a pin problem.
...
>"In modern usage, this question also serves as a metaphor for wasting
>time debating topics of no practical value."

In England, there's always the debate in council meetings about the
colour of the toilet walls.

A simple thought experiment tells you that a compiler can transform
  <lit> ?branch
into
  jmp
or
  <null>

Thus the question is really about whether it is worth doing.
Should we reward bad code with bad code?
VFX has switches +POLITE and -POLITE which control whether
warnings about literals in conditional branches are displayed.
One rarely has success in teaching people to read warning messages.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#19728

On Thu, 14 Feb 2013 10:53:42 GMT, stephenXXX@mpeforth.com (Stephen
Pelc) wrote:

>>> It's the angels dancing on the head of a pin problem.
>...
>>"In modern usage, this question also serves as a metaphor for wasting
>>time debating topics of no practical value."
>
>In England, there's always the debate in council meetings about the
>colour of the toilet walls.

The architect reminds me that this question is now subject to part M
of the building regulations. However, considerable useless debate is
still permitted. Sorry.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#19752

On Thursday, February 14, 2013 4:53:42 AM UTC-6, Stephen Pelc wrote:
> On Wed, 13 Feb 2013 23:17:32 -0800 (PST), Mark Wills
> 
> <forthfreak@gmail.com> wrote:
> 
> 
> 
> >> It's the angels dancing on the head of a pin problem.
> 
> ...
> 
> >"In modern usage, this question also serves as a metaphor for wasting
> 
> >time debating topics of no practical value."
> 
> 
> 
> In England, there's always the debate in council meetings about the
> 
> colour of the toilet walls.
> 
> 
> 
> A simple thought experiment tells you that a compiler can transform
> 
>   <lit> ?branch
> 
> into
> 
>   jmp
> 
> or
> 
>   <null>
> 
> 
> 
> Thus the question is really about whether it is worth doing.
> 
> Should we reward bad code with bad code?
> 
> VFX has switches +POLITE and -POLITE which control whether
> 
> warnings about literals in conditional branches are displayed.
> 
> One rarely has success in teaching people to read warning messages.

The switches are a fundamental evolution in the discussion of erros masg/ warnings / odd behavior reporting.

One day I hope to have a universal language interpreter/compiler option to define what I don't want reported. Some may want to specify expressions. Others will optimize this to use legacy args/flags/whatever.

It is gratifying to be elan vitale.

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

#19751

On Thursday, February 14, 2013 1:17:32 AM UTC-6, M.R.W Wills wrote:
> On Feb 13, 5:32 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> 
> > On Wed, 13 Feb 2013 08:23:06 -0800 (PST), m.a.m.hend...@tue.nl wrote:
> 
> > >> > - Show quoted text - Just timed it by hand with a stop-watch!=20
> 
> >
> 
> > >Are you telling us that on your system EMIT and TYPE are comparable in spee=
> 
> > >d to a BRANCH ( again )? It must be, because you execute one AGAIN for ever=
> 
> > >y TYPE (printing the index), and see a difference. I do not doubt your meas=
> 
> > >urement, but maybe you should do it again a few times. The results would be=
> 
> > > preposterous for a desktop Forth (TYPE would completely swamp anything els=
> 
> > >e done in the loop).
> 
> >
> 
> > It's the angels dancing on the head of a pin problem.
> 
> >
> 
> > Stephen
> 
> >
> 
> > --
> 
> > Stephen Pelc, stephen...@mpeforth.com
> 
> > MicroProcessor Engineering Ltd - More Real, Less Time
> 
> > 133 Hill Lane, Southampton SO15 5AF, England
> 
> > tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> 
> > web:http://www.mpeforth.com- free VFX Forth downloads
> 
> 
> 
> I had to resort to Wikipedia to decode this.
> 
> 
> 
> "In modern usage, this question also serves as a metaphor for wasting
> 
> time debating topics of no practical value."
> 
> 
> 
> Well, okay then.

I'd be clueless if it wasn't a line in Grateful Dead lyrics... ;?>

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

#19723

On Feb 13, 4:23 pm, m.a.m.hend...@tue.nl wrote:
> > > - Show quoted text - Just timed it by hand with a stop-watch!
>
> Are you telling us that on your system EMIT and TYPE are comparable in speed to a BRANCH ( again )?

No.

>It must be, because you execute one AGAIN for every TYPE (printing the index), and see a difference.

There's a difference because the code path is longer.

>I do not doubt your measurement, but maybe you should do it again a few times.
>The results would be preposterous for a desktop Forth (TYPE would completely swamp anything else done in the loop).

I think I'm misunderstanding your question/statement. TYPE *does*
swamp everything else in the loop. On my system, AGAIN compiles an
absolute branch (BRANCH). Branch is a primitive. The instructions
executed for BRANCH (on my system) is:

    mov *ip,ip
    b *next

UNTIL compiles an absolute 0BRANCH. The code for 0BRANCH is:

    mov *stack+,r0  ; test and pop flag
    jne zbq         ; jump if flag <>0
    mov *ip,ip      ; stack was zero. move address to instruction
pointer
    b *next
zbq inct ip         ; move past in-line address
    b *next

Note:
  B is the 9900 op-code for branch
  NEXT is an alias for R12
  The address of NEXT is held in R12, hence the indirect branch (using
the *)
  INCT=increment by 2
  ip is also a register (R3)

So, you can see that 0BRANCH (UNTIL) is 3 times longer than BRANCH
(AGAIN).

Not only that, but look at the *Forth* code: test1 and test2... test2
is more complex because UNTIL needs an argument on the stack, so a DUP
is required. That *also* adds to the overhead of test2.

I sure all the above is obvious to you, so my apologies. I'm afraid I
don't understand the rest of your question, or Stephen's subsequent
comment.

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

#19736

Mark Wills <forthfreak@gmail.com> writes Re: Loop structures

> On Feb 13, 4:23 pm, m.a.m.hend...@tue.nl wrote:
>> > > - Show quoted text - Just timed it by hand with a stop-watch!
>>
>> Are you telling us that on your system EMIT and TYPE are comparable in speed to a BRANCH ( again )?
>
> No.

I assume that TYPE is one of the slowest high-level routines in your Forth, yes?
On the other hand, the difference between AGAIN and 0 UNTIL is as short as one can 
have it (in high-level). 

Your : test2 0 begin dup $. 1- dup 0= until ; takes 174 seconds.

With my Forth

: test local #times ?ms #times 0 ?do ." 12345" loop cr ?ms swap - #1000 #times */ . ." us" ;
#1000 test \ prints 191 us. 

The following
: doagain ( ix -- ms ) ?ms swap begin  dup 0= if   drop ?ms swap - exit  endif  1-    again ;
: dountil ( ix -- ms ) ?ms swap begin  dup 0= if   drop ?ms swap - exit  endif  1-  0 until ;
: diff  dup >R doagain  R@ dountil - ( ms) #1000000000 ( ps) R> */ . ." [ps/iter]" ;

#1000000000 diff many -232 [ps/iter] -199 [ps/iter] -239 [ps/iter] -263 [ps/iter] ok

.. says that AGAIN is about 200ps faster than 0 UNTIL.

So your test2 is trying to detect a 200ps difference in a routine that takes 191us 
overall, or a 100 * 200ps/191us ~ 1e-4 % delta. However, you report a 5% difference 
in time. This means that your Forth's TYPE is 50,000 times faster than mine? That is
a mind-boggling number.

[..]
> I sure all the above is obvious to you, so my apologies. I'm afraid I
> don't understand the rest of your question, or Stephen's subsequent
> comment.

No, your numbers are far from obvious to me and my (idle) curiosity is genuine.

-marcel

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

#19753

On Feb 14, 8:08 pm, m...@iae.nl (Marcel Hendrix) wrote:
>
> I assume that TYPE is one of the slowest high-level routines in your Forth, yes?

Actually, no. TYPE is in machine code on my system, for performance
reasons (when your underlying system is as slow as mine, you need all
the help you can get!)

;[ TYPE         addr +n --                    M,79
; +n characters are displayed from memory beginning with the character
at addr and
; continuing through consecutive addresses.  Nothing is displayed if
+n is zero.
; See: "9.5.4 TYPE"
typeh   data goxyh,4
        text 'TYPE'
type    data $+2
type1   mov *stack+,r13             ; pop length in r13
        mov *stack+,r10             ; address in r10
        mov r13,r13                 ; check length
        jeq typout                  ; if 0 then exit
        jlt typout                  ; if negative then exit
typlp   movb *r10+,r7               ; get byte from string in r7 MSB
        swpb r7                     ; rotate MSB into LSB
        dect stack                  ; create space on stack
        mov r7,*stack               ; place on stack
        bl @emit_                   ; call emit
        dec r13                     ; have we finished?
        jne typlp                   ; if not, repeat
typout  b *next
;]

> On the other hand, the difference between AGAIN and 0 UNTIL is as short as one can
> have it (in high-level).
>
Yes. As posted previously. Both AGAIN and UNTIL compile assembly
language primitives.

> Your : test2 0 begin dup $. 1- dup 0= until ; takes 174 seconds.

Yes. My system has a 3mHz clock, but the data bus is multiplexed, and
there are wait-states on the RAM, so effective speed is probably in
the order of 1.5mHz. Opcodes are measured in uS and take a minimum of
12 clock cycles. It's slow.

>
> With my Forth
>
> : test local #times ?ms #times 0 ?do ." 12345" loop cr ?ms swap - #1000 #times */ . ." us" ;
> #1000 test \ prints 191 us.
>
> The following
> : doagain ( ix -- ms ) ?ms swap begin  dup 0= if   drop ?ms swap - exit  endif  1-    again ;
> : dountil ( ix -- ms ) ?ms swap begin  dup 0= if   drop ?ms swap - exit  endif  1-  0 until ;
> : diff  dup >R doagain  R@ dountil - ( ms) #1000000000 ( ps) R> */ . ." [ps/iter]" ;
>
> #1000000000 diff many -232 [ps/iter] -199 [ps/iter] -239 [ps/iter] -263 [ps/iter] ok
>
> .. says that AGAIN is about 200ps faster than 0 UNTIL.
>
> So your test2 is trying to detect a 200ps difference in a routine that takes 191us
> overall, or a 100 * 200ps/191us ~ 1e-4 % delta. However, you report a 5% difference
> in time. This means that your Forth's TYPE is 50,000 times faster than mine? That is
> a mind-boggling number.
>
Does it? Or is it simply that your (PC?) processor is much more
efficient than mine? Is your code running in a cache?

Hmmm... I just had a thought... Screen scrolling was disabled in my
tests, as scrolling the screen at the end of each line would be a far
greater overhead. Though I would still expect a ~4% difference between
the two. On your system I imagine you are scrolling the screen at the
end of every line (or, rather, EMIT is, called on a character-by-
character basis by TYPE). That adds a huge overhead. Could be that?

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

#19676

Ed <invalid@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.

If you think that "classic" structures found in CS texts matter, then
you must count out forths BEGIN..WHILE..REPEAT structure too.

Forths BEGIN..WHILE..REPEAT is *not* a loop structure checking the
condition at the start of the loop body. It allows checking it at *any*
point in the body, thus it's yet another case not mentioned in the OP
(or, apparently, in your CS literature) !!

Think of that:
: UNTIL postpone 0= postpone while postpone repeat ; immediate

It's not possible, or at least not straightforward to emulate
BEGIN..WHILE..REPEAT by using the classic while.., or ..until loops.
It's easily constructed though, when using an AGAIN loop as the basis,
because AGAIN forms the most fundamental building block, and you can
build any of the classic/non-classic loops on top of it:

: WHILE postpone if 1 cs-roll ; immediate
: REPEAT postpone AGAIN postpone then ; immediate

So: Only AGAIN is needed ;-)

Anyway, CS is rarely concerned with exhaustive research of loop
structure variants, mostly it just uses loops as a means for expressing
algorithms. Therefore what CS books use is not neccessarily relevant
when someone asks for structures he couldn't think of, as in this
thread.

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

#19701

In article <lridnZcasu89tY_MnZ2dnUVZ8lqdnZ2d@giganews.com>, 
kenney@cix.compulink.co.uk () wrote:

> As far as I can tell any other structures are variants of the above 
> with the possibility of multiple exits is this correct?

 Thanks to all who responded the replies were informative and useful.

 Ken Young

[toc] | [prev] | [standalone]

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

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

csiph-web