Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #131984 > unrolled thread
| Started by | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| First post | 2024-08-10 12:57 +0200 |
| Last post | 2024-09-09 17:34 +0000 |
| Articles | 20 on this page of 153 — 14 participants |
Back to article view | Back to comp.lang.forth
"Back & Forth" is back! Hans Bezemer <the.beez.speaks@gmail.com> - 2024-08-10 12:57 +0200
Re: "Back & Forth" is back! dxf <dxforth@gmail.com> - 2024-08-11 13:35 +1000
Re: "Back & Forth" is back! Hans Bezemer <the.beez.speaks@gmail.com> - 2024-08-11 14:46 +0200
Avoid treating the stack as an array [Re: "Back & Forth" is back!] Buzz McCool <buzz_mccool@yahoo.com> - 2024-08-30 09:04 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-08-30 20:32 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] BuzzMcCool <buzz_mccool@yahoo.com> - 2024-08-30 23:00 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Buzz McCool <buzz_mccool@yahoo.com> - 2024-09-02 09:03 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-03 11:23 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Buzz McCool <buzz_mccool@yahoo.com> - 2024-09-02 22:53 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-03 17:27 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-11 11:20 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-11 09:49 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-11 14:41 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-12 14:01 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-08-31 11:05 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] BuzzMcCool <buzz_mccool@yahoo.com> - 2024-08-30 22:59 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-05 17:18 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-05 17:37 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-05 17:42 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Buzz McCool <buzz_mccool@yahoo.com> - 2024-09-06 14:03 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-07 14:40 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-10 04:26 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-10 23:19 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-11 12:03 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-11 14:32 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-11 23:51 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-12 18:21 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-12 09:08 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-12 10:11 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-12 10:31 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-12 10:19 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-13 09:37 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-13 07:56 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-13 19:47 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-13 03:38 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Jan Coombs <jan4comp.lang.forth@murray-microft.co.uk> - 2024-09-13 13:07 +0100
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-13 17:59 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-14 01:12 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-14 01:56 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-14 21:56 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-14 09:10 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-15 15:17 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 09:52 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-16 12:46 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-15 11:14 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-13 13:07 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-13 18:07 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-14 12:48 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-14 05:47 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-14 06:19 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-14 18:40 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-15 15:04 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-15 16:16 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-15 21:35 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 14:45 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-16 12:19 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-16 14:37 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 17:37 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-16 18:58 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 19:26 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-17 06:53 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 17:29 +0000
value-flavoured structures (was: Avoid treating the stack as an array) Ruvim <ruvim.pinka@gmail.com> - 2024-09-27 12:15 +0400
Re: value-flavoured structures minforth@gmx.net (minforth) - 2024-09-27 08:51 +0000
Re: value-flavoured structures mhx@iae.nl (mhx) - 2024-09-27 09:38 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-09-27 16:27 +0400
Re: value-flavoured structures minforth@gmx.net (minforth) - 2024-09-27 12:46 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-09-27 23:28 +0400
Re: value-flavoured structures Paul Rubin <no.email@nospam.invalid> - 2024-09-27 19:13 -0700
Re: value-flavoured structures dxf <dxforth@gmail.com> - 2024-09-28 14:19 +1000
Re: value-flavoured structures Paul Rubin <no.email@nospam.invalid> - 2024-09-27 22:38 -0700
Re: value-flavoured structures albert@spenarnc.xs4all.nl - 2024-09-28 13:21 +0200
Re: value-flavoured structures Paul Rubin <no.email@nospam.invalid> - 2024-09-28 10:52 -0700
Re: value-flavoured structures Paul Rubin <no.email@nospam.invalid> - 2024-09-28 11:06 -0700
Re: value-flavoured structures dxf <dxforth@gmail.com> - 2024-09-28 14:04 +1000
Re: value-flavoured structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 16:32 +0000
Re: value-flavoured structures dxf <dxforth@gmail.com> - 2024-10-04 13:00 +1000
Re: value-flavoured structures albert@spenarnc.xs4all.nl - 2024-10-04 23:27 +0200
Re: value-flavoured structures (was: Avoid treating the stack as an array) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 15:58 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-10-04 11:17 +0400
Re: value-flavoured structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-04 11:52 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-10-04 19:17 +0400
Re: value-flavoured structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-04 18:04 +0000
Re: value-flavoured structures Ruvim <ruvim.pinka@gmail.com> - 2024-10-05 15:06 +0400
Re: value-flavoured structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-05 15:52 +0000
value-flavoured properties of a word (was: value-flavoured structures) Ruvim <ruvim.pinka@gmail.com> - 2024-10-06 17:12 +0400
value-flavoured approach (was: value-flavoured structures) Ruvim <ruvim.pinka@gmail.com> - 2024-10-06 20:04 +0400
value-flavoured approach in API (was: value-flavoured structures) Ruvim <ruvim.pinka@gmail.com> - 2024-10-06 20:58 +0400
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-14 12:32 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 14:52 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-14 15:08 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 17:13 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 17:43 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 17:41 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-14 18:54 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-14 19:19 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-15 06:17 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-15 07:30 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-15 07:35 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-15 11:42 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-15 18:14 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-15 08:58 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-15 09:58 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (ahmed) - 2024-09-15 12:06 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-16 09:13 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-16 10:13 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-16 10:36 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-16 22:47 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] melahi_ahmed@yahoo.fr (Ahmed) - 2024-09-16 13:21 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-16 13:33 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-16 12:16 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 19:55 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-16 21:43 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-17 10:47 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-17 09:12 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-17 08:43 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-17 07:24 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 09:56 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-16 14:11 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 23:32 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-16 08:48 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-16 20:01 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-15 11:20 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-15 15:28 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-15 11:53 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-12 08:55 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-15 12:39 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-16 16:26 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-17 12:18 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-18 13:08 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-17 22:39 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-18 17:30 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-18 13:10 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-19 14:14 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-28 13:49 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-28 22:36 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-29 14:22 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-29 11:44 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-30 16:13 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-29 14:40 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] mhx@iae.nl (mhx) - 2024-09-29 16:53 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-29 11:33 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-11 11:02 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-11 13:29 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Paul Rubin <no.email@nospam.invalid> - 2024-09-12 00:10 -0700
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Stephen Pelc <stephen@vfxforth.com> - 2024-09-08 14:56 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-08 16:09 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] Hans Bezemer <the.beez.speaks@gmail.com> - 2024-09-09 17:15 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] minforth@gmx.net (minforth) - 2024-09-09 21:16 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] dxf <dxforth@gmail.com> - 2024-09-10 12:21 +1000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] albert@spenarnc.xs4all.nl - 2024-09-10 12:10 +0200
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-08 16:27 +0000
Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-09-09 17:34 +0000
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2024-09-07 14:40 +0200 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <nnd$26b4d59b$27bdb181@ce638e508b04426e> |
| In reply to | #132104 |
On 06-09-2024 23:03, Buzz McCool wrote: > On 9/5/2024 8:18 AM, Hans Bezemer wrote: > >> Given that the area of the circle doesn't change - why recalculate >> that every time? > > Excellent observation. > > Would you have any videos talking about Forth locals? You and dxf are > far more adept at stack manipulations than I. I'm thinking I can get a > word up and working with locals and then convert to manual stack > manipulations afterwards if necessary. Oh, I talk a lot about locals: don't use them. The point is: you have random access to locals. So I doubt very much it will help you to uncover a smart way to do it without them. Basically any non-Forth Algol-like language will do the job. And that's in essence you I am opposed to them. It takes out what makes Forth unique - and the way thinking of Forth unique. > When is it necessary? dxf showed a word w/o locals to have ~%30 fewer > instructions than a word with locals. Is that a common occurrence? I can't really tell. In 4tH (my own implementation) the use of locals requires an external library - so it always consumes more instructions. It also heavily depends on the style and the skill of the programmer. If you're a newbie doing a lot of stack acrobatics, I doubt it. What bothers me most technologically is that parameters flow through the stack undisturbed. You break that paradigm when using locals. With locals you *HAVE TO* create some kind of stack frame that you have to destroy when you exit. Needless to say this copying, releasing and stuff takes time. Even when you don't use locals. In all honesty I must state that this overhead is not always translated to a diminished performance - at least not in the tests I did. **** TL;DR my objections are mostly based on pure architectural arguments, rather than practicality. I also don't like Python, PHP and Perl for those very same reasons - one because I think its paradigms are fundamentally flawed, the second and third because of their "have we thrown in the kitchen sink yet" mentality. I don't think there will ever be a "Back&Forth" episode on locals - frankly, because - apart from some demonstrations - there is only one single, ported program that uses locals in my repository. How can you teach if you never used them yourself? **** Note that 4tH features R@, R'@ and R"@ which can server very conveniently as "local variables" - provided you leave the Return Stack alone. I learned that trick from the programmer of the FIG editor. See: https://sourceforge.net/p/forth-4th/code/HEAD/tree/trunk/4th.src/lib/gcircle.4th for a nice example of that one. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2024-09-10 04:26 -0700 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <87bk0vbvgk.fsf@nightsong.com> |
| In reply to | #132105 |
Hans Bezemer <the.beez.speaks@gmail.com> writes: > What bothers me most technologically is that parameters flow through > the stack undisturbed. You break that paradigm when using locals. With > locals you *HAVE TO* create some kind of stack frame that you have to > destroy when you exit. Forth programs very frequently end up juggling parameters and other data to and from the return stack, instead of using locals. Simple implementations of locals put them in the return stack too. "Destroying" the stack frame just means adjusting RP when the function exits. Usually a single instruction. > Needless to say this copying, releasing and stuff takes time. Similar to DUP (copy) or DROP (release). > In all honesty I must state that this overhead is not always > translated to a diminished performance Right, I don't think one can assert a performance hit without measurements supporting the idea. > TL;DR my objections are mostly based on pure architectural arguments, > rather than practicality. Sure, that's reasonable, it's a matter of what you prefer. That's harder to take issue with than claims about performance. > I also don't like Python, PHP and Perl for those very same reasons - Those are at a totally different level than Forth, in terms of layers of implementation and runtime libraries, overhead, etc. It's better to compare to something like C, or a hypothetical cleaned up version of C, or even to Forth with locals ;).
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-10 23:19 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e04762$1@news.ausics.net> |
| In reply to | #132124 |
On 10/09/2024 9:26 pm, Paul Rubin wrote: > Hans Bezemer <the.beez.speaks@gmail.com> writes: >> What bothers me most technologically is that parameters flow through >> the stack undisturbed. You break that paradigm when using locals. With >> locals you *HAVE TO* create some kind of stack frame that you have to >> destroy when you exit. > > Forth programs very frequently end up juggling parameters and other data > to and from the return stack, instead of using locals. Simple > implementations of locals put them in the return stack too. > "Destroying" the stack frame just means adjusting RP when the function > exits. Usually a single instruction. > ... In forth the programmer uses the return stack as a temporary holder. Not so locals which spill all input to the return stack and then shuffle these to/from the parameter stack. The latter is akin to a novice programmer who uses too many variables.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-11 12:03 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e0fa58$1@news.ausics.net> |
| In reply to | #132124 |
On 10/09/2024 9:26 pm, Paul Rubin wrote: > Hans Bezemer <the.beez.speaks@gmail.com> writes: >> What bothers me most technologically is that parameters flow through >> the stack undisturbed. You break that paradigm when using locals. With >> locals you *HAVE TO* create some kind of stack frame that you have to >> destroy when you exit. > > Forth programs very frequently end up juggling parameters and other data > to and from the return stack, instead of using locals. Looking at an application with 154 colon definitions, only 2 were found to use the return stack for temporary storage. Even I was surprised :)
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-11 14:32 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e11d64$1@news.ausics.net> |
| In reply to | #132127 |
On 11/09/2024 12:03 pm, dxf wrote: > On 10/09/2024 9:26 pm, Paul Rubin wrote: >> Hans Bezemer <the.beez.speaks@gmail.com> writes: >>> What bothers me most technologically is that parameters flow through >>> the stack undisturbed. You break that paradigm when using locals. With >>> locals you *HAVE TO* create some kind of stack frame that you have to >>> destroy when you exit. >> >> Forth programs very frequently end up juggling parameters and other data >> to and from the return stack, instead of using locals. > > Looking at an application with 154 colon definitions, only 2 were found > to use the return stack for temporary storage. Even I was surprised :) From the same app: dup 54 drop 29 swap 22 over 16 2drop 9 rot 8 2dup 3 >r 2 r> 2 2swap 1 2nip 1 locals 0 The easiest stack operations (DUP DROP) account for most. SWAP averaged 1 in 7 definitions. OVER 1 in 9. Is 'stack juggling' a problem in forth? It doesn't appear to be.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2024-09-11 23:51 -0700 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <877cbh4b6z.fsf@nightsong.com> |
| In reply to | #132128 |
dxf <dxforth@gmail.com> writes: >> Looking at an application with 154 colon definitions... > From the same app: > The easiest stack operations (DUP DROP) account for most. Is the code for this app available? > SWAP averaged 1 in 7 definitions. OVER 1 in 9. Is 'stack juggling' a > problem in forth? It doesn't appear to be. The 100+ occurrences of DUP, DROP, and SWAP are either an abstraction inversion (with a smart compiler, the data ends up in registers that could be named by locals) or they are stack traffic whose cost has to be compared with the cost of indexed references to locals in the return stack. I'd agree that they aren't necessary "juggling" which evokes permuting stuff in the stack outside the usual FIFO order. That does happpen a little bit though, with OVER, ROT, etc.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-12 18:21 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e2a497$1@news.ausics.net> |
| In reply to | #132135 |
On 12/09/2024 4:51 pm, Paul Rubin wrote: > dxf <dxforth@gmail.com> writes: >>> Looking at an application with 154 colon definitions... >> From the same app: >> The easiest stack operations (DUP DROP) account for most. > > Is the code for this app available? Previously posted. You may have seen it. https://pastebin.com/2xcRSbQW >> SWAP averaged 1 in 7 definitions. OVER 1 in 9. Is 'stack juggling' a >> problem in forth? It doesn't appear to be. > > The 100+ occurrences of DUP, DROP, and SWAP are either an abstraction > inversion (with a smart compiler, the data ends up in registers that > could be named by locals) or they are stack traffic whose cost has to be > compared with the cost of indexed references to locals in the return > stack. I'd agree that they aren't necessary "juggling" which evokes > permuting stuff in the stack outside the usual FIFO order. That does > happpen a little bit though, with OVER, ROT, etc. If a cost, it's one the programmer can keep to minimum. With locals there's an upfront cost that can't be avoided. Using registers is appealing until one realizes a call to an external function necessitates placing it back on the stack. Costs multiply in the face of many small functions. Moore touches on this in one of his speeches: "I keep asking that question. What is Forth? Forth is highly factored code. I don't know anything else to say except that Forth is definitions. If you have a lot of small definitions you are writing Forth. In order to write a lot of small definitions you have to have a stack. Stacks are not popular. Its strange to me that they are not. There is a just lot of pressure from vested interests that don't like stacks, they like registers. Stacks are not a solve all problems concept but they are very very useful, especially for information hiding and you have to have two of them." - Chuck Moore 1999
[toc] | [prev] | [next] | [standalone]
| From | minforth@gmx.net (minforth) |
|---|---|
| Date | 2024-09-12 09:08 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <6f20e14815243aea4e91b9cf0fb2488d@www.novabbs.com> |
| In reply to | #132137 |
On Thu, 12 Sep 2024 8:21:43 +0000, dxf wrote: > If a cost, it's one the programmer can keep to minimum. With locals > there's > an upfront cost that can't be avoided. Using registers is appealing > until > one realizes a call to an external function necessitates placing it back > on > the stack. Costs multiply in the face of many small functions. This is history (or your archaic compiler). Modern compilers try to pass most parameters through registers. https://langdev.stackexchange.com/questions/2584/are-modern-compilers-passing-parameters-in-registers-instead-of-on-the-stack
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (mhx) |
|---|---|
| Date | 2024-09-12 10:11 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <16f28f2970c4c2eedffac0809116bcfa@www.novabbs.com> |
| In reply to | #132138 |
On Thu, 12 Sep 2024 9:08:20 +0000, minforth wrote: > This is history (or your archaic compiler). Modern compilers try to pass > most parameters through registers. The rules are very complicated, though. One has to account for there being too many parameters, for different architectures with different register assignments, for integer and floating-point type parameters, and under some circumstances both the registers *and* the stack must be used, where some extra 'working space' may, or may not, be needed. I was very happy when it finally worked on all of our target OSes. -marcel
[toc] | [prev] | [next] | [standalone]
| From | minforth@gmx.net (minforth) |
|---|---|
| Date | 2024-09-12 10:31 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <b9227400729ecf0fa63c6a0b7adbac0d@www.novabbs.com> |
| In reply to | #132139 |
I can well imagine that. Some wheels are particularly difficult to reinvent. For desktop systems, it can therefore make sense to use an IR (e.g. LLVM or WASM, or simply C) and use the optimisation functions of proven compilers for this IR. Sometimes a much simpler solution: use code inlining.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-09-12 10:19 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <2024Sep12.121903@mips.complang.tuwien.ac.at> |
| In reply to | #132137 |
dxf <dxforth@gmail.com> writes:
>Using registers is appealing until
>one realizes a call to an external function necessitates placing it back on
>the stack.
Not if the stack item does not live across the call. And even if it
lives across the call and cannot be placed in a callee-saved register,
the save before and restore after the call is amortized typically
across more than one register access on each side of the call.
Register allocation is one of the most effective optimizations in
compilers. That's also true of Forth.
>Costs multiply in the face of many small functions.
Register allocation is also effective for small functions.
- 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: https://forth-standard.org/
EuroForth 2024: https://euro.theforth.net
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-13 09:37 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e37b37$1@news.ausics.net> |
| In reply to | #132141 |
On 12/09/2024 8:19 pm, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> Using registers is appealing until >> one realizes a call to an external function necessitates placing it back on >> the stack. > > Not if the stack item does not live across the call. And even if it > lives across the call and cannot be placed in a callee-saved register, > the save before and restore after the call is amortized typically > across more than one register access on each side of the call. > > Register allocation is one of the most effective optimizations in > compilers. That's also true of Forth. > >> Costs multiply in the face of many small functions. > > Register allocation is also effective for small functions. Moore talked about registers. It's worth repeating for those who may be new to forth. "But such registers raises the question of local variables. There is a lot of discussion about local variables. That is another aspect of your application where you can save 100% of the code. I remain adamant that local variables are not only useless, they are harmful. If you are writing code that needs them you are writing, non-optimal code" - Chuck Moore 1999
[toc] | [prev] | [next] | [standalone]
| From | minforth@gmx.net (minforth) |
|---|---|
| Date | 2024-09-13 07:56 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <05fd5a0056972ac60f43598f23a170ad@www.novabbs.com> |
| In reply to | #132143 |
On Thu, 12 Sep 2024 23:37:29 +0000, dxf wrote: > On 12/09/2024 8:19 pm, Anton Ertl wrote: >> Register allocation is one of the most effective optimizations in >> compilers. That's also true of Forth. >> >>> Costs multiply in the face of many small functions. >> >> Register allocation is also effective for small functions. > > Moore talked about registers. It's worth repeating for those who may be > new > to forth. > > "But such registers raises the question of local variables. There is a > lot of > discussion about local variables. That is another aspect of your > application > where you can save 100% of the code. I remain adamant that local > variables > are not only useless, they are harmful. If you are writing code that > needs > them you are writing, non-optimal code" - Chuck Moore 1999 The only thing that can be deduced from this is that back in 1999 this was Moore's opinion in the specific context of his work. Besides, the world has changed a wee bit since then...
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-13 19:47 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e40a42$1@news.ausics.net> |
| In reply to | #132148 |
On 13/09/2024 5:56 pm, minforth wrote: > On Thu, 12 Sep 2024 23:37:29 +0000, dxf wrote: > >> On 12/09/2024 8:19 pm, Anton Ertl wrote: >>> Register allocation is one of the most effective optimizations in >>> compilers. That's also true of Forth. >>> >>>> Costs multiply in the face of many small functions. >>> >>> Register allocation is also effective for small functions. >> >> Moore talked about registers. It's worth repeating for those who may be >> new >> to forth. >> >> "But such registers raises the question of local variables. There is a >> lot of >> discussion about local variables. That is another aspect of your >> application >> where you can save 100% of the code. I remain adamant that local >> variables >> are not only useless, they are harmful. If you are writing code that >> needs >> them you are writing, non-optimal code" - Chuck Moore 1999 > > The only thing that can be deduced from this is that back in 1999 > this was Moore's opinion in the specific context of his work. > > Besides, the world has changed a wee bit since then... Claims made in respect of locals in forth - ease of use, better performance through less 'stack juggling', better readability/maintainability - were all made in the 1980's. What has changed? Forthers today are more willing to believe, to accept the word of authority, lack the interest to discover the truth for themselves? If so, that would be a pity.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2024-09-13 03:38 -0700 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <87o74r3kjo.fsf@nightsong.com> |
| In reply to | #132149 |
dxf <dxforth@gmail.com> writes: >>> "I remain adamant that local variables are not only useless, they >>> are harmful. If you are writing code that needs them you are >>> writing, non-optimal code" - Chuck Moore 1999 ... > > Claims made in respect of locals in forth - ease of use, better > performance through less 'stack juggling', better > readability/maintainability - were all made in the 1980's. What has > changed? Forthers today are more willing to believe, to accept the > word of authority, lack the interest to discover the truth for > themselves? Is avoiding locals because of the Chuck Moore quote not an example of accepting the word of authority? And how often do even you care whether your code is optimal? It's likely difficult to get any interpreted Forth code to run at better than 1/5th the speed of assembly code. So if optimization is your main concern, why use Forth to begin with? I would say that the claim of better performance from locals depends on the implementation and in any case has to be scrutinized if it matters, but even if there's a performance loss, that might be an acceptable trade if the programmer finds offsetting gains in the other areas. My main programming language for random hacking is Python, which is possibly 10x slower than interpreted Forth or 50x slower than compiled Forth or C. Yet it usually doesn't matter unless I'm trying to do something unusually compute intensive. Once the program is fast enough to not be annoying to use, I don't need to optimize it more.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jan4comp.lang.forth@murray-microft.co.uk> |
|---|---|
| Date | 2024-09-13 13:07 +0100 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <20240913130732.06c11152@t530> |
| In reply to | #132150 |
On Fri, 13 Sep 2024 03:38:51 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > I would say that the claim of better performance from locals depends > on the implementation[...] Absolutely. As Chucks prime target of interest (hardware) uses LIFO registers for stacks, only the top top one, or so, R stack items could be used for restricted local storage (which is also common practice). I accept that locals are useful, and would like to see hardware stack engine implementations that support this better while retaining the performance advantage of a stack cache implemented as LIFO registers rather than in RAM. Jan Coombs --
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-09-13 17:59 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <2024Sep13.195927@mips.complang.tuwien.ac.at> |
| In reply to | #132153 |
Jan Coombs <jan4comp.lang.forth@murray-microft.co.uk> writes:
>Absolutely. As Chucks prime target of interest (hardware) uses LIFO
>registers for stacks, only the top top one, or so, R stack items could
>be used for restricted local storage (which is also common practice).
>
>I accept that locals are useful, and would like to see hardware stack
>engine implementations that support this better while retaining the
>performance advantage of a stack cache implemented as LIFO registers
>rather than in RAM.
AFAIK Chuck Moore implements the stack as SRAM indexed with his stack
pointer; maybe the stack pointer is a rotating shift register with
only one bit set, don't remember.
He also uses an A register in addition to R and the data TOS last I
looked. So much for Chuck Moore denouncing registers. When he
introduced A, some people played with the idea to add A and possibly
more registers to Forth.
- 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: https://forth-standard.org/
EuroForth 2024: https://euro.theforth.net
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-14 01:12 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e4564c$1@news.ausics.net> |
| In reply to | #132150 |
On 13/09/2024 8:38 pm, Paul Rubin wrote: > dxf <dxforth@gmail.com> writes: >>>> "I remain adamant that local variables are not only useless, they >>>> are harmful. If you are writing code that needs them you are >>>> writing, non-optimal code" - Chuck Moore 1999 ... >> >> Claims made in respect of locals in forth - ease of use, better >> performance through less 'stack juggling', better >> readability/maintainability - were all made in the 1980's. What has >> changed? Forthers today are more willing to believe, to accept the >> word of authority, lack the interest to discover the truth for >> themselves? > > Is avoiding locals because of the Chuck Moore quote not an example of > accepting the word of authority? Or I've yet to hear a convincing argument from the locals authorities :) You have the source to my app. Perhaps you can nominate where locals could have been used to better effect.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2024-09-14 01:56 -0700 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <87cyl6396z.fsf@nightsong.com> |
| In reply to | #132154 |
dxf <dxforth@gmail.com> writes:
> You have the source to my app. Perhaps you can nominate where locals
> could have been used to better effect.
: EMITS ( n char -- ) swap 0 ?do dup emit loop drop ;
could be written:
: EMITS {: n char -- :} n 0 ?do char emit loop ;
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-14 21:56 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e579f9$1@news.ausics.net> |
| In reply to | #132161 |
On 14/09/2024 6:56 pm, Paul Rubin wrote:
> dxf <dxforth@gmail.com> writes:
>> You have the source to my app. Perhaps you can nominate where locals
>> could have been used to better effect.
>
> : EMITS ( n char -- ) swap 0 ?do dup emit loop drop ;
>
> could be written:
>
> : EMITS {: n char -- :} n 0 ?do char emit loop ;
Compiling under DX-Forth resulted in a code size of 23 and 26 bytes
respectively. Under VFX ...
( 71 bytes, 18 instructions )
( 102 bytes, 28 instructions )
Not only were you able to read forth code, the result was more efficient.
Perhaps locals in forth were meant to be clever? That would explain the
interest however it's high price to pay.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web