Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #39232 > unrolled thread
| Started by | chitselb <chitselb@gmail.com> |
|---|---|
| First post | 2015-05-23 19:27 -0700 |
| Last post | 2015-05-24 14:06 +0000 |
| Articles | 20 on this page of 151 — 19 participants |
Back to article view | Back to comp.lang.forth
unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-23 19:27 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-23 20:27 -0700
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-24 13:44 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:36 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-24 23:16 +0200
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 15:57 -0700
Re: unexpected +LOOP behavior Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-25 02:21 +0200
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-24 15:21 -1000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 19:49 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 18:22 -0700
Re: unexpected +LOOP behavior "WJ" <w_a_x_man@yahoo.com> - 2015-05-26 17:20 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 14:15 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 08:37 -1000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 15:09 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 09:19 -1000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 17:08 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 15:42 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 19:30 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 17:45 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 21:33 -0400
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 14:08 +0200
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 06:32 -0700
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 16:15 +0200
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 14:32 -1000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 08:30 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 17:15 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-29 21:05 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 01:41 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-24 23:26 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:33 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 10:56 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-25 11:28 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 14:33 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 12:57 -0700
Re: unexpected +LOOP behavior humptydumpty <ouatubi@gmail.com> - 2015-05-25 23:01 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:21 +0000
Re: unexpected +LOOP behavior albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-26 23:59 +0000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 09:15 +0000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 10:06 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 12:03 -0400
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 16:23 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 12:39 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-27 22:14 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 17:13 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-27 23:36 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 18:06 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 10:35 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:16 +0100
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 09:42 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 16:16 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 15:24 +0100
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:32 -0400
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 23:59 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 19:31 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-27 23:11 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-28 12:21 +0100
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-28 12:24 +0100
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 10:53 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:19 +0100
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 13:51 +0000
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 17:48 +0200
Re: unexpected +LOOP behavior Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-29 02:08 +0200
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 08:25 +0000
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:40 +0100
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 13:16 +0000
Re: unexpected +LOOP behavior albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-29 18:43 +0000
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 20:08 +0100
x86 tricks Lars Brinkhoff <lars.spam@nocrew.org> - 2015-06-05 09:42 +0200
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-05 09:32 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 09:40 +0000
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-05 11:17 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 15:49 +0000
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 17:45 +0100
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 16:53 +0000
Re: x86 tricks rickman <gnuarm@gmail.com> - 2015-06-07 13:20 -0400
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-08 07:18 +0000
Re: x86 tricks Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-08 17:18 +0200
Re: x86 tricks Tessa Bonting <tessa.bonting@gmail.com> - 2015-06-08 08:42 -0700
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-06 09:47 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-07 15:05 +0000
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-07 17:49 +0100
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 13:19 +0100
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:38 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-23 21:33 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-23 22:10 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-23 22:20 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 21:13 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:34 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 22:04 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-28 01:27 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-28 03:20 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-28 04:13 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-29 04:23 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 11:28 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-29 18:32 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 18:53 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-23 22:26 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-23 21:37 -1000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 10:24 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-24 20:40 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-25 14:08 +0200
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-25 17:27 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:47 -1000
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:33 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 12:53 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 13:05 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:49 -1000
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 18:03 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 16:44 -1000
Re: unexpected +LOOP behavior humptydumpty <ouatubi@gmail.com> - 2015-05-25 22:56 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-26 08:05 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:43 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-24 08:29 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-24 15:44 +0000
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-27 00:57 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-06-05 13:11 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-06-05 12:24 -1000
Re: unexpected +LOOP behavior JennyB <jennybrien@googlemail.com> - 2015-06-06 13:29 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-07 14:56 +0000
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-06-07 10:38 -1000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-08 08:08 +0000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 10:01 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:40 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 11:29 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-25 09:51 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 10:44 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-25 12:34 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 12:59 -0700
unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-24 01:39 -0700
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-24 14:46 +0200
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:17 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-24 20:48 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 18:15 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 12:35 +0000
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-25 17:27 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 18:16 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 16:17 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 17:16 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 17:50 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 18:47 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 20:01 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 20:29 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 20:32 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-26 08:03 +0000
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-26 01:10 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 22:31 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 20:07 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 20:20 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 22:00 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 02:41 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-24 14:06 +0000
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-05-25 14:08 +0200 |
| Message-ID | <556310d8$0$2873$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #39253 |
hughaguilar96@gmail.com wrote: > Of course, this is totally baffling to the user who would intuitively > expect 2>R to be the same as >R >R. A lot of people have tried to learn > ANS-Forth, but have become confused by the weird and pointless > "optimizations" such as this, and so they just gave up and went back to C > programming. Agreed. It's more efficient as well: : 2>r >r >r ; : 2r@ r> r@ over >r ; : 2r> r> r> ; Again: if you're treating something as a unit (2 cells), don't start using it as half a unit halfway. If you abide by this rule, it doesn't really matter if you use these definitions or the "SWAPped" ones. It's these quirks that make Forth a "write only" language. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <fork@lllljunkqwer.cpm> |
|---|---|
| Date | 2015-05-25 17:27 -0400 |
| Message-ID | <op.xy7m7ztnwhxjl4@localhost> |
| In reply to | #39283 |
On Mon, 25 May 2015 08:08:59 -0400, Hans Bezemer <the.beez.speaks@gmail.com> wrote: > hughaguilar96@gmail.com wrote: >> Of course, this is totally baffling to the user who would intuitively >> expect 2>R to be the same as >R >R. A lot of people have tried to learn >> ANS-Forth, but have become confused by the weird and pointless >> "optimizations" such as this, and so they just gave up and went back to >> C programming. > > Agreed. It's more efficient as well: > > : 2>r >r >r ; > : 2r@ r> r@ over >r ; > : 2r> r> r> ; > > Again: if you're treating something as a unit (2 cells), don't start > using it as half a unit halfway. If you abide by this rule, it doesn't > really matter if you use these definitions or the "SWAPped" ones. > > It's these quirks that make Forth a "write only" language. If 2R> is a primitive, what's to prevent someone from doing this: : SWAP >R >R 2R> ; Rod Pemberton -- If fewer guns reduced murders, how does one explain Moscow, Chicago, New York, and South Africa?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-05-25 14:47 -1000 |
| Message-ID | <idKdnTVKcsUPX_7InZ2dnUU7-f-dnZ2d@supernews.com> |
| In reply to | #39305 |
On 5/25/15 11:27 AM, Rod Pemberton wrote: > On Mon, 25 May 2015 08:08:59 -0400, Hans Bezemer > <the.beez.speaks@gmail.com> wrote: >> hughaguilar96@gmail.com wrote: > >>> Of course, this is totally baffling to the user who would intuitively >>> expect 2>R to be the same as >R >R. A lot of people have tried to learn >>> ANS-Forth, but have become confused by the weird and pointless >>> "optimizations" such as this, and so they just gave up and went back to >>> C programming. >> >> Agreed. It's more efficient as well: >> >> : 2>r >r >r ; >> : 2r@ r> r@ over >r ; >> : 2r> r> r> ; >> >> Again: if you're treating something as a unit (2 cells), don't start >> using it as half a unit halfway. If you abide by this rule, it doesn't >> really matter if you use these definitions or the "SWAPped" ones. >> >> It's these quirks that make Forth a "write only" language. > > If 2R> is a primitive, what's to prevent someone from doing this: > > : SWAP >R >R 2R> ; Nothing, except the fact that SWAP (which is also a primitive in most systems) will then be slower. 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]
| From | "Rod Pemberton" <fork@lllljunkqwer.cpm> |
|---|---|
| Date | 2015-05-27 17:33 -0400 |
| Message-ID | <op.xzbcuvcvwhxjl4@localhost> |
| In reply to | #39310 |
On Mon, 25 May 2015 20:47:13 -0400, Elizabeth D. Rather <erather@forth.com> wrote: > On 5/25/15 11:27 AM, Rod Pemberton wrote: >> On Mon, 25 May 2015 08:08:59 -0400, Hans Bezemer >> <the.beez.speaks@gmail.com> wrote: >>> hughaguilar96@gmail.com wrote: >>>> Of course, this is totally baffling to the user who would intuitively >>>> expect 2>R to be the same as >R >R. A lot of people have tried to >>>> learn >>>> ANS-Forth, but have become confused by the weird and pointless >>>> "optimizations" such as this, and so they just gave up and went back >>>> to >>>> C programming. >>> >>> Agreed. It's more efficient as well: >>> >>> : 2>r >r >r ; >>> : 2r@ r> r@ over >r ; >>> : 2r> r> r> ; >>> >>> Again: if you're treating something as a unit (2 cells), don't start >>> using it as half a unit halfway. If you abide by this rule, it doesn't >>> really matter if you use these definitions or the "SWAPped" ones. >>> >>> It's these quirks that make Forth a "write only" language. >> >> If 2R> is a primitive, what's to prevent someone from doing this: >> >> : SWAP >R >R 2R> ; > > Nothing, except the fact that SWAP (which is also a primitive in most > systems) will then be slower. What? ... Ms. Rather, you seemed to have dropped usage of "low-level word" for "primitives." Well, it might be good for bootstrapping a system, i.e., because it's more factored and has less redundancy of functionality. If you need fewer words, this could save a word or two. However, this was really just an off-beat comment on "quirks" and "write only". Rod Pemberton -- If fewer guns reduced murders, how does one explain Moscow, Chicago, New York, and South Africa?
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2015-05-25 12:53 -0700 |
| Message-ID | <a293346f-df27-4871-b903-1b5c0ccf17d3@googlegroups.com> |
| In reply to | #39253 |
On Sunday, May 24, 2015 at 10:24:58 AM UTC-7, hughag...@gmail.com wrote: > ... > For example, we have these: > > 2>R ( a b -- ) \ return stack: -- a b \ effectively: SWAP >R >R > 2R> ( -- a b ) \ return stack: a b -- \ effectively: R> R> SWAP > 2R@ ( -- a b ) \ return stack: a b -- a b \ effectively: R> R> 2DUP > R >R SWAP > > ... Maybe it would have been more intuitive to name those D>R DR> DR@ to match D+ and friends? I dunno, I'm just a n00b, and it's much too late to change it now ... Mike
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-25 13:05 -0700 |
| Message-ID | <1767836b-d7f1-4dce-a0c4-48db428a50d0@googlegroups.com> |
| In reply to | #39301 |
On Monday, May 25, 2015 at 12:53:06 PM UTC-7, Michael Barry wrote: > On Sunday, May 24, 2015 at 10:24:58 AM UTC-7, hughag...@gmail.com wrote: > > ... > > For example, we have these: > > > > 2>R ( a b -- ) \ return stack: -- a b \ effectively: SWAP >R >R > > 2R> ( -- a b ) \ return stack: a b -- \ effectively: R> R> SWAP > > 2R@ ( -- a b ) \ return stack: a b -- a b \ effectively: R> R> 2DUP > > R >R SWAP > > > > ... > > Maybe it would have been more intuitive to name those D>R DR> DR@ > to match D+ and friends? > I dunno, I'm just a n00b, and it's much too late to change it now ... > > Mike I have always thought so too --- I find it confusing to have a number (2) in the middle of my source-code that isn't a literal value. Maybe in my language I will do this --- it is somewhat of a gratuitous name change that may confuse ANS-Forth programmers --- but there aren't very many ANS-Forth programmers in the world anymore, and most of them are perpetually confused anyway, so it may not increase the level of confusion in the world at all.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-05-25 14:49 -1000 |
| Message-ID | <idKdnTRKcsWyXv7InZ2dnUU7-f-dnZ2d@supernews.com> |
| In reply to | #39301 |
On 5/25/15 9:53 AM, Michael Barry wrote: > On Sunday, May 24, 2015 at 10:24:58 AM UTC-7, hughag...@gmail.com wrote: >> ... >> For example, we have these: >> >> 2>R ( a b -- ) \ return stack: -- a b \ effectively: SWAP >R >R >> 2R> ( -- a b ) \ return stack: a b -- \ effectively: R> R> SWAP >> 2R@ ( -- a b ) \ return stack: a b -- a b \ effectively: R> R> 2DUP >> R >R SWAP >> >> ... > > Maybe it would have been more intuitive to name those D>R DR> DR@ > to match D+ and friends? > I dunno, I'm just a n00b, and it's much too late to change it now ... The D prefix is intended to convey that the word is intended to work with double-length integers. 2>R and 2R> don't have any such expectation. 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]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2015-05-25 18:03 -0700 |
| Message-ID | <d0fd7f59-bb06-4e59-a02d-93dcc2888567@googlegroups.com> |
| In reply to | #39311 |
On Monday, May 25, 2015 at 5:49:52 PM UTC-7, Elizabeth D. Rather wrote: > ... > The D prefix is intended to convey that the word is intended to work > with double-length integers. 2>R and 2R> don't have any such expectation. > > ... For what other common-use purposes would the cell order be preserved? In other words, why isn't 2>R ( x1 x2 -- ) ( R: -- x2 x1 ) ? The way it is, it looks like ( d -- ) ( R: -- d ) , right? Mike
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-05-25 16:44 -1000 |
| Message-ID | <t7Cdnd0kk5y3Q_7InZ2dnUU7-X2dnZ2d@supernews.com> |
| In reply to | #39314 |
On 5/25/15 3:03 PM, Michael Barry wrote: > On Monday, May 25, 2015 at 5:49:52 PM UTC-7, Elizabeth D. Rather wrote: >> ... >> The D prefix is intended to convey that the word is intended to work >> with double-length integers. 2>R and 2R> don't have any such expectation. >> >> ... > > For what other common-use purposes would the cell order be preserved? > In other words, why isn't 2>R ( x1 x2 -- ) ( R: -- x2 x1 ) ? > > The way it is, it looks like ( d -- ) ( R: -- d ) , right? Lots of situations: address-length pairs, upper & lower limits, value and scale, xy coordinates, or even two unrelated numbers that you need to save off the stack temporarily, but need them to remain in the correct order. 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]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2015-05-25 22:56 -0700 |
| Message-ID | <87943b41-5fa1-4e33-bd93-14971b0e6f86@googlegroups.com> |
| In reply to | #39314 |
On Tuesday, May 26, 2015 at 4:03:27 AM UTC+3, Michael Barry wrote: > On Monday, May 25, 2015 at 5:49:52 PM UTC-7, Elizabeth D. Rather wrote: > > ... > > The D prefix is intended to convey that the word is intended to work > > with double-length integers. 2>R and 2R> don't have any such expectation. > > > > ... > > For what other common-use purposes would the cell order be preserved? > In other words, why isn't 2>R ( x1 x2 -- ) ( R: -- x2 x1 ) ? > > The way it is, it looks like ( d -- ) ( R: -- d ) , right? > > > Mike Hi! To preserve minimum work path to get top. Top-of-stack is used more than Next-of-stack, and that should be preserved even this pair is in return-stack or somewhere in memory: what is on top-data-stack should be reached after storing by 'R@'or '@'. Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-26 08:05 +0000 |
| Message-ID | <2015May26.100534@mips.complang.tuwien.ac.at> |
| In reply to | #39314 |
Michael Barry <barrym95838@yahoo.com> writes:
>On Monday, May 25, 2015 at 5:49:52 PM UTC-7, Elizabeth D. Rather wrote:
>> ...
>> The D prefix is intended to convey that the word is intended to work
>> with double-length integers. 2>R and 2R> don't have any such expectation.
>>
>> ...
>
>For what other common-use purposes would the cell order be preserved?
The only reason to have a particular cell order on the return stack is
if you want to access it with single-cell words (or maybe with
something like RP@ 3 CELLS + 2@).
> In other words, why isn't 2>R ( x1 x2 -- ) ( R: -- x2 x1 ) ?
My guess is that it is because you can achieve that with >R >R, so if
you want to access individual cells on the return stack with R@, with
the standard 2>R you have two options: If you want to access x1, you
use >R >R, and if you want to access x2, you use 2>R. The standard
2>R may also be cheaper to implement on architectures that have
double-register loads and stores (if the return stack grows in the
same direction as the data stack).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-24 10:43 -0400 |
| Message-ID | <mjso0v$apk$2@dont-email.me> |
| In reply to | #39239 |
On 5/24/2015 1:26 AM, Michael Barry wrote: > On Saturday, May 23, 2015 at 10:10:32 PM UTC-7, hughag...@gmail.com wrote: >> ... >> >> I'm pretty sure that DO loops go back to the very original Forth, so it >> was likely Charles Moore who came up with the idea. >> >> ... > > I meant the optimization, not the implementation. You can check your > Forth by comparing R@ and I inside a loop. If they're equal, then > there is no V-flag optimization. If they're different, then it is > likely present. Could you explain this to a newbie? With V-flag (I assume that means overflow?) optimization is the count being done over a range other than the values expected for I? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2015-05-24 08:29 -0700 |
| Message-ID | <9bca4add-f007-4853-835e-78d0c964d48a@googlegroups.com> |
| In reply to | #39249 |
On Sunday, May 24, 2015 at 7:43:50 AM UTC-7, rickman wrote: > Could you explain this to a newbie? With V-flag (I assume that means > overflow?) optimization is the count being done over a range other than > the values expected for I? > I'll try, but I can't guarantee that I'll make sense. The idea with twos complement machines is that V will set if an add instruction causes the value to cross the border between the largest positive integer and the largest negative integer, or vice-versa. On a 16-bit machine (which I will continue to use in this example) that border is between $7fff and $8000. The trick comes from "fudge- factoring" your index so that the limit and that border coincide. In (DO) instead of saving the index and limit on the Rstack, you instead save the fudge-factor (which is $8000-limit) and your fudged index (which is index+fudge). (LOOP) and (+LOOP) now only have to update and check the V flag to see if they're done, but I and J have to be modified to "un-fudge" the index values, using the saved fudge-factor. I'm not convinced that it's a great idea, but it happens to be the easiest way to duplicate the odd behavior that the OP described, making it something like a case of "the tail wagging the dog" for this little gem. More discussion here: http://forum.6502.org/viewtopic.php?f=9&t=2026#p33091 and here: http://forum.6502.org/viewtopic.php?f=9&t=3086&p=35162 HTH. Mike
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-24 15:44 +0000 |
| Message-ID | <2015May24.174418@mips.complang.tuwien.ac.at> |
| In reply to | #39250 |
Michael Barry <barrym95838@yahoo.com> writes:
>On Sunday, May 24, 2015 at 7:43:50 AM UTC-7, rickman wrote:
>> Could you explain this to a newbie? With V-flag (I assume that means
>> overflow?) optimization is the count being done over a range other than
>> the values expected for I?
>>
>
>I'll try, but I can't guarantee that I'll make sense.
>
>The idea with twos complement machines is that V will set if an add
> instruction causes the value to cross the border between the largest
> positive integer and the largest negative integer, or vice-versa.
> On a 16-bit machine (which I will continue to use in this example)
> that border is between $7fff and $8000. The trick comes from "fudge-
> factoring" your index so that the limit and that border coincide.
>
>In (DO) instead of saving the index and limit on the Rstack, you
> instead save the fudge-factor (which is $8000-limit) and your
> fudged index (which is index+fudge). (LOOP) and (+LOOP) now only
> have to update and check the V flag to see if they're done, but I
> and J have to be modified to "un-fudge" the index values, using
> the saved fudge-factor. I'm not convinced that it's a great idea,
> but it happens to be the easiest way to duplicate the odd behavior
> that the OP described, making it something like a case of "the
> tail wagging the dog" for this little gem.
One can also do the fudging in LOOP/+LOOP, and avoid the unfudging in
I. Something like, for (+LOOP):
x=index-limit+$8000 \ one lea on 386
y=x+n
if overflow
... loop ends ...
else
index = index+n
jump to the loop start
This will be slower on the all important empty do-loop benchmark, but
probably faster if there is more than one I per iteration.
But a /LOOP that counts only upwards and a \LOOP (called -LOOP in
Gforth) that counts only downwards are more efficient yet.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2015-05-27 00:57 -0700 |
| Message-ID | <b88b88ed-7500-4878-80dc-ae2fa838d214@googlegroups.com> |
| In reply to | #39251 |
On Sunday, May 24, 2015 at 9:01:56 AM UTC-7, Anton Ertl wrote: > ... > One can also do the fudging in LOOP/+LOOP, and avoid the unfudging > in I. Something like, for (+LOOP): > > x=index-limit+$8000 \ one lea on 386 > y=x+n > if overflow > ... loop ends ... > else > index = index+n > jump to the loop start > > This will be slower on the all important empty do-loop benchmark, > but probably faster if there is more than one I per iteration. > ... I gave that a try on my 65m32 DTC Forth, and arrived theoretically (and tentatively) at the following, after some rewriting and shuffling around: Good: Total size of implementation is 4 words smaller. (do) is 6 memory cycles faster. I is 1 memory cycle faster. Not-so-good: J is 1 memory cycle slower. R@ is 2 memory cycles slower. (loop) is 8 memory cycles slower. (+loop) is 8 memory cycles slower. The slowing of J and R@ is due to re-arrangement of internal code- sharing among the primitives, but for an amateur compulsive size-optimizer like me, I am tempted to call it an over-all win, even though there would be a minor performance hit for any small-bodied loop of one or more iterations. Thanks, Dr. Ertl ... I think! ;-) Mike
[toc] | [prev] | [next] | [standalone]
| From | chitselb <chitselb@gmail.com> |
|---|---|
| Date | 2015-06-05 13:11 -0700 |
| Message-ID | <6d569c62-0590-456b-a962-fff81ba4e285@googlegroups.com> |
| In reply to | #39251 |
On Sunday, May 24, 2015 at 12:01:56 PM UTC-4, Anton Ertl wrote: > Michael Barry writes: > >On Sunday, May 24, 2015 at 7:43:50 AM UTC-7, rickman wrote: > >> Could you explain this to a newbie? With V-flag (I assume that means > >> overflow?) optimization is the count being done over a range other than > >> the values expected for I? > >> > > > >I'll try, but I can't guarantee that I'll make sense. > > > >The idea with twos complement machines is that V will set if an add > > instruction causes the value to cross the border between the largest > > positive integer and the largest negative integer, or vice-versa. > > On a 16-bit machine (which I will continue to use in this example) > > that border is between $7fff and $8000. The trick comes from "fudge- > > factoring" your index so that the limit and that border coincide. > > > >In (DO) instead of saving the index and limit on the Rstack, you > > instead save the fudge-factor (which is $8000-limit) and your > > fudged index (which is index+fudge). (LOOP) and (+LOOP) now only > > have to update and check the V flag to see if they're done, but I > > and J have to be modified to "un-fudge" the index values, using > > the saved fudge-factor. I'm not convinced that it's a great idea, > > but it happens to be the easiest way to duplicate the odd behavior > > that the OP described, making it something like a case of "the > > tail wagging the dog" for this little gem. > > One can also do the fudging in LOOP/+LOOP, and avoid the unfudging in > I. Something like, for (+LOOP): > > x=index-limit+$8000 \ one lea on 386 > y=x+n > if overflow > ... loop ends ... > else > index = index+n > jump to the loop start > > This will be slower on the all important empty do-loop benchmark, but > probably faster if there is more than one I per iteration. > > But a /LOOP that counts only upwards and a \LOOP (called -LOOP in > Gforth) that counts only downwards are more efficient yet. > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard: http://www.forth200x.org/forth200x.html > EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm I applied this approach put all the heavy lifting in `(+LOOP)` and things are a bit slower than Blazin' Forth, which does the fudging in `(DO)` and `I`. So the tradeoff in speed is a matter of guessing which of these two is a closer balance of `I` vs `(+LOOP)` executions in typical code (whatever that is) A) Lots of I 10000 0 do i drop i drop i drop i drop 3 +loop B) Not so much I 10000 0 do 3 +loop
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-06-05 12:24 -1000 |
| Message-ID | <Le2dnfnlYOwGvO_InZ2dnUU7-QudnZ2d@supernews.com> |
| In reply to | #39599 |
On 6/5/15 10:11 AM, chitselb wrote:
> On Sunday, May 24, 2015 at 12:01:56 PM UTC-4, Anton Ertl wrote:
>> Michael Barry writes:
>>> On Sunday, May 24, 2015 at 7:43:50 AM UTC-7, rickman wrote:
>>>> Could you explain this to a newbie? With V-flag (I assume that means
>>>> overflow?) optimization is the count being done over a range other than
>>>> the values expected for I?
>>>>
>>>
>>> I'll try, but I can't guarantee that I'll make sense.
>>>
>>> The idea with twos complement machines is that V will set if an add
>>> instruction causes the value to cross the border between the largest
>>> positive integer and the largest negative integer, or vice-versa.
>>> On a 16-bit machine (which I will continue to use in this example)
>>> that border is between $7fff and $8000. The trick comes from "fudge-
>>> factoring" your index so that the limit and that border coincide.
>>>
>>> In (DO) instead of saving the index and limit on the Rstack, you
>>> instead save the fudge-factor (which is $8000-limit) and your
>>> fudged index (which is index+fudge). (LOOP) and (+LOOP) now only
>>> have to update and check the V flag to see if they're done, but I
>>> and J have to be modified to "un-fudge" the index values, using
>>> the saved fudge-factor. I'm not convinced that it's a great idea,
>>> but it happens to be the easiest way to duplicate the odd behavior
>>> that the OP described, making it something like a case of "the
>>> tail wagging the dog" for this little gem.
>>
>> One can also do the fudging in LOOP/+LOOP, and avoid the unfudging in
>> I. Something like, for (+LOOP):
>>
>> x=index-limit+$8000 \ one lea on 386
>> y=x+n
>> if overflow
>> ... loop ends ...
>> else
>> index = index+n
>> jump to the loop start
>>
>> This will be slower on the all important empty do-loop benchmark, but
>> probably faster if there is more than one I per iteration.
>>
>> But a /LOOP that counts only upwards and a \LOOP (called -LOOP in
>> Gforth) that counts only downwards are more efficient yet.
...
> I applied this approach put all the heavy lifting in `(+LOOP)` and things are a bit slower than Blazin' Forth, which does the fudging in `(DO)` and `I`. So the tradeoff in speed is a matter of guessing which of these two is a closer balance of `I` vs `(+LOOP)` executions in typical code (whatever that is)
>
> A) Lots of I
> 10000 0 do i drop i drop i drop i drop 3 +loop
>
> B) Not so much I
> 10000 0 do 3 +loop
>
FWIW in my experience I is used far, far more than +LOOP, which is
relatively rare. /LOOP and \LOOP ("ramp-up loop" and "ramp down loop")
are quite useful, and indeed quite fast.
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]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-06-06 13:29 -0700 |
| Message-ID | <0219820b-87dc-4ab9-a28c-ea11d3243ff3@googlegroups.com> |
| In reply to | #39602 |
On Friday, 5 June 2015 23:24:28 UTC+1, Elizabeth D. Rather wrote:
>
> FWIW in my experience I is used far, far more than +LOOP, which is
> relatively rare. /LOOP and \LOOP ("ramp-up loop" and "ramp down loop")
> are quite useful, and indeed quite fast.
>
Its nice to see this thread coming back to +LOOP! ;)
I wonder if the solution is instead to have a \DO
The loop stack always holds the limit and the remaining count
With DO, I subtracts; with \DO it adds (this is known at compile time).
If increment<count, LOOP and +LOOP subtract and loop; otherwise they fall through.
10 1 DO loop stack count=9 limit=10
10 1 \DO loop stack count=9 limit=1
10 1 \DO I . LOOP 10 9 8 7 6 5 3 2
10 1 \DO I . 2 +LOOP 10 8 6 4 2
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-07 14:56 +0000 |
| Message-ID | <2015Jun7.165616@mips.complang.tuwien.ac.at> |
| In reply to | #39602 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>FWIW in my experience I is used far, far more than +LOOP, which is
>relatively rare.
In the data from https://www.complang.tuwien.ac.at/forth/peep/sorted
Total cross gs prims2x
99120 47603 39014 12503 i
73426 45805 14153 13468 (loop)
23886 9496 7604 6786 (+loop)
These are dynamic execution counts.
>/LOOP and \LOOP ("ramp-up loop" and "ramp down loop")
>are quite useful, and indeed quite fast.
What do they do and how are they used?
: test1 4 0 ?do i . 2 /loop ;
Does this print "0 2 "?
: test2 -4 0 ?do i . 2 \loop ;
Does this print "0 -2"? Or do I need to give -2 as increment?
And why are they not in SwiftForth by default?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-06-07 10:38 -1000 |
| Message-ID | <LbmdnQIvJKBNNunInZ2dnUU7-a2dnZ2d@supernews.com> |
| In reply to | #39616 |
On 6/7/15 4:56 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> FWIW in my experience I is used far, far more than +LOOP, which is
>> relatively rare.
>
> In the data from https://www.complang.tuwien.ac.at/forth/peep/sorted
>
> Total cross gs prims2x
> 99120 47603 39014 12503 i
> 73426 45805 14153 13468 (loop)
> 23886 9496 7604 6786 (+loop)
>
> These are dynamic execution counts.
>
>> /LOOP and \LOOP ("ramp-up loop" and "ramp down loop")
>> are quite useful, and indeed quite fast.
>
> What do they do and how are they used?
>
> : test1 4 0 ?do i . 2 /loop ;
>
> Does this print "0 2 "?
>
> : test2 -4 0 ?do i . 2 \loop ;
>
> Does this print "0 -2"? Or do I need to give -2 as increment?
>
> And why are they not in SwiftForth by default?
Not in SwiftForth because they're mostly used in control applications
(e.g. to run stepper motors), and SwF isn't used in those applications
so much. And I'm afraid I don't remember the answer to your question
(it's been a while). If you want an unsigned incrementing or
decrementing loop, since they aren't standardized you can make them work
the most efficient way.
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]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web