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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2024-09-14 09:10 -0700 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <878qvu2p2l.fsf@nightsong.com> |
| In reply to | #132162 |
dxf <dxforth@gmail.com> writes: > Compiling under DX-Forth resulted in a code size of 23 and 26 bytes > respectively. Under VFX ... I can't help it if those compilers generate worse code for the locals version. Can you conveniently try lxf? > Not only were you able to read forth code, the result was more > efficient. Sometimes it isn't too hard to read, sometimes it takes head scratching, and sometimes I can't make any sense of it. The function Anton posted was an example that didn't make sense. I remember thinking I might sit down and try to figure it out to rewrite it, but it doesn't seem worth the effort. Anyway, if efficiency was important for that example, I'd use CODE.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-15 15:17 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e66ddf@news.ausics.net> |
| In reply to | #132166 |
On 15/09/2024 2:10 am, Paul Rubin wrote: > dxf <dxforth@gmail.com> writes: >> Compiling under DX-Forth resulted in a code size of 23 and 26 bytes >> respectively. Under VFX ... > > I can't help it if those compilers generate worse code for the locals > version. Can you conveniently try lxf? Windows NT/Forth (32 bit): ( 67 bytes, 19 instructions ) ( 87 bytes, 24 instructions ) >> Not only were you able to read forth code, the result was more >> efficient. > > Sometimes it isn't too hard to read, sometimes it takes head scratching, > and sometimes I can't make any sense of it. The function Anton posted > was an example that didn't make sense. I remember thinking I might sit > down and try to figure it out to rewrite it, but it doesn't seem worth > the effort. It would be no different were locals used. It would still require one to sit down and figure out what the code did. The more experienced one is in the language the easier it is. Going back to the EMITS example: - despite lack of comments you quickly deduced what it did - stack operations were few and simple and still you didn't like it - your ideal is that every stack operation should go, which is what you did If one takes from forth that which makes it efficient, then one takes away its reason for existence. Unfortunately for forth, this is what locals users are doing, whether they're aware of it or not. > Anyway, if efficiency was important for that example, I'd use CODE. In other words forth is not important to you. I understand. You've stated Python is your language of preference. Forth is mine and I'll program it the best way I know how.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2024-09-15 09:52 -0700 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <871q1k3lmf.fsf@nightsong.com> |
| In reply to | #132172 |
dxf <dxforth@gmail.com> writes:
> Going back to the EMITS example:
>
> - despite lack of comments you quickly deduced what it did
> - stack operations were few and simple and still you didn't like it
> - your ideal is that every stack operation should go, which is what
> you did
It was the first word in the program that used any stack operations at
all. I saw that it was more concise and imho more readable without
them. Other words there were much harder to read.
> If one takes from forth that which makes it efficient, then one takes away
> its reason for existence. Unfortunately for forth, this is what locals
> users are doing, whether they're aware of it or not.
I'm not persuaded that the stack ops make Forth efficient. Certainly
not as much as advanced compilers do, and yet one of the big attractions
of Forth has been very simple interpreters.
On my x86-64 laptop, gcc -c -S -Os on
void emit(char);
void emits(char c, int n) {
while (n-- > 0) emit(c);
}
gives me 27 bytes, 15 instructions, beating all of the Forth examples.
Several of the 14 instructions seem related to passing parameters in
registers. Passing on the stack like in old fashioned systems would
save a few more, at the expense of some speed. So if I want efficiency,
I should use C.
>> Anyway, if efficiency was important for that example, I'd use CODE.
> In other words forth is not important to you.
I would say efficiency is usually not very important to me, whether in
forth or any other language. It's the usual story of programs having
hot spots. Aim for efficiency in the hot spots and readability and ease
of implementation everywhere else.
Also, you define "forth" as using stack ops instead of locals. I don't
define it that way. Forth with locals is still Forth. They are in the
standard after all.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2024-09-16 12:46 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e79c14$1@news.ausics.net> |
| In reply to | #132186 |
On 16/09/2024 2:52 am, Paul Rubin wrote:
> dxf <dxforth@gmail.com> writes:
>> Going back to the EMITS example:
>>
>> - despite lack of comments you quickly deduced what it did
>> - stack operations were few and simple and still you didn't like it
>> - your ideal is that every stack operation should go, which is what
>> you did
>
> It was the first word in the program that used any stack operations at
> all. I saw that it was more concise and imho more readable without
> them. Other words there were much harder to read.
>
>> If one takes from forth that which makes it efficient, then one takes away
>> its reason for existence. Unfortunately for forth, this is what locals
>> users are doing, whether they're aware of it or not.
>
> I'm not persuaded that the stack ops make Forth efficient.
That's been the evidence thus far.
> Certainly
> not as much as advanced compilers do, and yet one of the big attractions
> of Forth has been very simple interpreters.
>
> On my x86-64 laptop, gcc -c -S -Os on
>
> void emit(char);
> void emits(char c, int n) {
> while (n-- > 0) emit(c);
> }
>
> gives me 27 bytes, 15 instructions, beating all of the Forth examples.
> Several of the 14 instructions seem related to passing parameters in
> registers. Passing on the stack like in old fashioned systems would
> save a few more, at the expense of some speed. So if I want efficiency,
> I should use C.
Yes - if you want efficiency with locals use C since C is built upon a
locals paradigm. Also modern cpu's are optimized for the likes of C.
But just because C can beat forth on a benchmark is no reason to dismiss
either Forth or efficient programming. The weak links are the programmer
and the tools he's given. All I ever seem to hear about other languages
is how they make life easy for the programmer. And this is what some are
trying to bring to forth. To hell with what they offer I say. The universe
gave me a brain. I intend to use it.
>
>>> Anyway, if efficiency was important for that example, I'd use CODE.
>> In other words forth is not important to you.
>
> I would say efficiency is usually not very important to me, whether in
> forth or any other language. It's the usual story of programs having
> hot spots. Aim for efficiency in the hot spots and readability and ease
> of implementation everywhere else.
>
> Also, you define "forth" as using stack ops instead of locals. I don't
> define it that way. Forth with locals is still Forth. They are in the
> standard after all.
I don't believe in religion - the priests, the holy books, the promises.
I'll take what is and make the best of it.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2024-09-15 11:14 +0200 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <nnd$1f07f16e$3fc1bdac@5d021b7c2adb2f81> |
| In reply to | #132161 |
In article <87cyl6396z.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> 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 ;
I think TYPE should be the primitive and EMIT should
be handle a 1 char string.
: EMIT DSP@ 1 TYPE DROP ;
Imagine that you have concurrent tasks and one will write
in red, the other in blue. You could lock up the terminal
with undefined escape sequence.
Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2024-09-13 13:07 +0200 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <nnd$74cd4057$3ab3003c@b7bb6e02afaa9baa> |
| In reply to | #132149 |
In article <66e40a42$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote: >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. I object to locals because it introduce a superfluous extra concept. It is foreign to a stack oriented language. Also there are numerous conflicting notations, and giving a name to a single cell, isn't sufficient. You need not local doubles, floats and structures. There are people fond of their information hiding aspect, that can easily be done with normal data and an addition like marking some words private. The remaining argument is re-entrancy, an overrated argument. I am also fond of Algol68/go. A different end of the spectrum, but it has a common feature that Forth has: consistency. Local variables break that. I don't take Moore's word for gospel, but I pay attention, because he is an accomplished individual. Groetjes Albert -- Temu exploits Christians: (Disclaimer, only 10 apostles) Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall Art For Home, Office And Garden Decor - Perfect For Windows, Bars, And Gifts For Friends Family And Colleagues.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-09-13 18:07 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <2024Sep13.200734@mips.complang.tuwien.ac.at> |
| In reply to | #132149 |
dxf <dxforth@gmail.com> writes:
>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.
Where can I find claims about better performance? All I have read is
claims about worse performance.
>What has changed? Forthers today are more willing to
>believe, to accept the word of authority
Is that why you cite Chuck Moore on locals rather than arguing from
facts?
- 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 12:48 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e4f98b$1@news.ausics.net> |
| In reply to | #132156 |
On 14/09/2024 4:07 am, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> 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. > > Where can I find claims about better performance? All I have read is > claims about worse performance. 'Eliminate stack juggling' sounds like an argument for better performance. It's a catch cry that's become synonymous with locals. Identify something wrong with forth and introduce a solution is the gameplay. >> What has changed? Forthers today are more willing to >> believe, to accept the word of authority > > Is that why you cite Chuck Moore on locals rather than arguing from > facts? The facts AFAICT is locals are an appeal to prejudice. If locals were a bona- fide extension it ought to be crystal clear when to apply them and when not. Vague statements about readability and maintainability don't cut it. The fact is locals challenge and contradict forth - why I'm vitally interested in getting at the truth of it. The best way I knew of doing that is see whether I needed locals in practice. When the result is good forth coding can stand on its own, why shouldn't I quote Moore.
[toc] | [prev] | [next] | [standalone]
| From | minforth@gmx.net (minforth) |
|---|---|
| Date | 2024-09-14 05:47 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <4eb4a2ef401af182018968586a02ab6b@www.novabbs.com> |
| In reply to | #132157 |
On Sat, 14 Sep 2024 2:48:45 +0000, dxf wrote: > The facts AFAICT is locals are an appeal to prejudice. This is one of the best sentences ever uttered on this forum! :-)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-09-14 06:19 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <2024Sep14.081952@mips.complang.tuwien.ac.at> |
| In reply to | #132157 |
dxf <dxforth@gmail.com> writes:
>On 14/09/2024 4:07 am, Anton Ertl wrote:
>> Where can I find claims about better performance? All I have read is
>> claims about worse performance.
>
>'Eliminate stack juggling' sounds like an argument for better performance.
Not to me. To me it sounds like a statement about the ease of writing
and reading the code.
The performance of locals vs. stack juggling depends on the
implementation. I know no implementation that performs register
allocation of locals or stack items (except the TOS) to registers
across basic block boundaries. This seems to hurt code with locals
more than code that keeps everything on the stacks. Here's the data
from an earlier posting <2024Sep12.105526@mips.complang.tuwien.ac.at>,
now including data from iForth:
locals stack
401 336 gforth-fast (AMD64)
179 132 lxf 1.6-982-823 (IA-32)
182 119 VFX FX Forth for Linux IA32 Version: 4.72 (IA-32)
241 159 VFX Forth 64 5.43 (AMD64)
163 175 iforth-5.1 mini (AMD64)
The data from iForth is the outlier here, let's look at the code:
Source code:
defer dummy
: z" [char] " parse 2drop postpone dummy ; immediate
defer zformat
defer z+
defer >name
defer error
: VICHECK1 {: pindex paddr -- pindex' paddr :} \ Checks for valid index
\ paddr is the address of the data, the first cell of which contains
\ the array size
pindex 0 paddr @ WITHIN IF \ Index is valid
pindex paddr
ELSE \ Index is invalid
Z" Invalid index " pindex ZFORMAT Z+
Z" for " Z+ paddr >NAME 1+ Z+ \ >NAME does not work for separated data
Z" length " Z+ paddr @ ZFORMAT Z+
ERROR
0 paddr \ Use zeroth index
THEN ;
: VICHECK2 ( pindex paddr -- pindex' paddr ) \ Checks for valid index
\ paddr is the address of the data, the first cell of which contains
\ the array size
over 0 2 pick @ WITHIN 0= IF \ Index is invalid
Z" Invalid index " 2 PICK ZFORMAT Z+
Z" for " Z+ OVER CELL- @ Z+ \ Add NFA from extra cell
Z" length " Z+ OVER @ ZFORMAT Z+
ERROR
NIP 0 SWAP \ Use zeroth index
THEN ;
One difference is that VICHECK2 does not just replace the locals with
stack stuff and eliminate the first branch of the IF, but also
replaces ">NAME 1+" with "CELL- @".
Disassembled code:
VICHECK1 VICHECK2
pop rbx pop rbx
lea rsi, [rsi #-16 +] qword mov rdi, [rsp] qword
mov [esi] dword, rbx push rbx
pop rbx push rdi
lea rsi, [rsi #-16 +] qword push 0 b#
mov [esi] dword, rbx mov rbx, [rsp #16 +] qword
mov rbx, [rsi #16 +] qword pop rdi
mov rbx, [rbx] qword mov rax, rdi
mov rdi, [rsi] qword sub rax, [rbx] qword
cmp rbx, rdi neg rax
jbe $10227337 offset NEAR pop rbx
push [rsi] qword sub rbx, rdi
push [rsi #16 +] qword cmp rax, rbx
jmp $10227395 offset NEAR seta bl
call $10226600 qword-offset movzx rbx, bl
push [rsi] qword neg rbx
call $10226E90 qword-offset cmp rbx, 0 b#
call $10226EB0 qword-offset jne $10227465 offset NEAR
call $10226600 qword-offset call $10226600 qword-offset
call $10226EB0 qword-offset mov rbx, [rsp #16 +] qword
push [rsi #16 +] qword push rbx
call $10226ED0 qword-offset call $10226E90 qword-offset
pop rbx call $10226EB0 qword-offset
lea rbx, [rbx 1 +] qword call $10226600 qword-offset
push rbx call $10226EB0 qword-offset
call $10226EB0 qword-offset pop rbx
call $10226600 qword-offset mov rdi, [rsp] qword
call $10226EB0 qword-offset push rbx
mov rbx, [rsi #16 +] qword push [rdi -8 +] qword
push [rbx] qword call $10226EB0 qword-offset
call $10226E90 qword-offset call $10226600 qword-offset
call $10226EB0 qword-offset call $10226EB0 qword-offset
call $10226EF0 qword-offset pop rbx
push 0 b# mov rdi, [rsp] qword
push [rsi #16 +] qword push rbx
add rsi, #32 b# push [rdi] qword
; call $10226E90 qword-offset
call $10226EB0 qword-offset
call $10226EF0 qword-offset
pop rbx
pop rdi
mov rdi, 0 d#
mov rcx, rdi
push rcx
push rbx
;
iForth 5.1-mini does not even keep the TOS in a register on basic
block boundaries, which results in pops and pushes at all the
boundaries, especially for the stack-only code. However, in the
actual application (where Z", ZFORMAT etc. don't compile as deferred
words) it would probably inline many of these words which might result
in better code for the stack variant. It does not keep locals in
stack items, either, but accesses them in memory through a separate
stack pointer.
The code at the start of VICHECK2 does not suffer from basic block
boundaries, yet makes less use of registers than I expected. By
contrast, in VICHECK1 iforth discovers that "0 paddr @ within" is
equivalent to "paddr @ u<", while for "0 2 pick @ within" it fails to
make the equivalent discovery.
- 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 18:40 +1000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <66e54c15$1@news.ausics.net> |
| In reply to | #132159 |
On 14/09/2024 4:19 pm, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> On 14/09/2024 4:07 am, Anton Ertl wrote: >>> Where can I find claims about better performance? All I have read is >>> claims about worse performance. >> >> 'Eliminate stack juggling' sounds like an argument for better performance. > > Not to me. To me it sounds like a statement about the ease of writing > and reading the code. > > The performance of locals vs. stack juggling depends on the > implementation. > ... Surely you mean locals vs. forth. The easiest way to achieve performance in forth is making your stack operations efficient. 'Stack juggling' is a visual cue that it's not. I'm sorry that you feel forth isn't readable.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Pelc <stephen@vfxforth.com> |
|---|---|
| Date | 2024-09-15 15:04 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <vc6t1b$27sna$1@dont-email.me> |
| In reply to | #132159 |
On 14 Sep 2024 at 08:19:52 CEST, "Anton Ertl" <Anton Ertl> wrote:
> locals stack
> 401 336 gforth-fast (AMD64)
> 179 132 lxf 1.6-982-823 (IA-32)
> 182 119 VFX FX Forth for Linux IA32 Version: 4.72 (IA-32)
> 241 159 VFX Forth 64 5.43 (AMD64)
> 163 175 iforth-5.1 mini (AMD64)
There are design decisions within locals that can impact optimisation.
The design of locals in VFX was influenced by Don Colburn's Forth's
and by a desire to use locals to simplify source code when interfacing
to a host operating system. Many operating systems return data
to the caller by passing the address of a variable/buffer as an input
parameter. Locals that can have an accessible address make such
code much easier to read and write. The example below comes from
early system access code in VFX (see kernel/386Lin/syspatch.fth).
The locals design dates from long before ANS.
$541B equ FIONREAD
: (OS_key?) { | nread[ cell ] -- flag }
?PrepTerm nread[ off
nread[ FIONREAD stdin @ dll_ioctl @ 3 nxcall -1 = if
0 \ Error return from ioctl
else
nread[ @ 0<>
then
;
: (OS_Key) \ -- key ; SFP003
{ | iobuff[ cell ] -- char }
?PrepTerm
1 iobuff[ stdin @ dll_ReadFile @ 3 nxcall drop
iobuff[ c@
;
Code such as this has been around for a very long time and the use
of addresses of locals, and of local buffers, has proven itself over
time. Yes, we could put in a great effort to improve the performance
of locals, but this is Forth and there are other optimisations that may
produce bigger changes to application performance. In the last
decade or so there has been very little customer demand for
faster code. However, higher level source code has been much
in demand. An example is Nick Nelson's value flavoured structures,
which are of particular merit when converting code from 32 bit to
64 bit host Forths.
Just because many of the Forth applications visible to the Forth
community now run on CPUs with 16 or 32 address registers
does not mean that all systems can implement the compiler
techniques required for high-performance locals.
I can buy a lot of CPU cycles for the cost of one day of programmer
time. I am reminded when looking at locals that a client's Forth
engine is currently at 4GHz on a 12nm process. The performance
was detuned to 4GHz becuase the machine was more than fast
enough.
Stephen
--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com
MPE website
http://www.vfxforth.com/downloads/VfxCommunity/
downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-09-15 16:16 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <2024Sep15.181634@mips.complang.tuwien.ac.at> |
| In reply to | #132185 |
Stephen Pelc <stephen@vfxforth.com> writes:
>On 14 Sep 2024 at 08:19:52 CEST, "Anton Ertl" <Anton Ertl> wrote:
>
>> locals stack
>> 401 336 gforth-fast (AMD64)
>> 179 132 lxf 1.6-982-823 (IA-32)
>> 182 119 VFX FX Forth for Linux IA32 Version: 4.72 (IA-32)
>> 241 159 VFX Forth 64 5.43 (AMD64)
>> 163 175 iforth-5.1 mini (AMD64)
>
>There are design decisions within locals that can impact optimisation.
>The design of locals in VFX was influenced by Don Colburn's Forth's
>and by a desire to use locals to simplify source code when interfacing
>to a host operating system. Many operating systems return data
>to the caller by passing the address of a variable/buffer as an input
>parameter. Locals that can have an accessible address make such
>code much easier to read and write.
Gforth has had variable-flavoured locals from the start, and
implemented VFX's local-buffer syntax some time ago without problems,
so Gforth's design decisions are obviously compatible with these
requirements.
Now Gforth's numbers above are the worst of all Forth systems, so why
would Gforth be relevant? The native code for locals by iForth seems
to be very much in the same spirit: A separate locals stack, and
locals are accessed relative to the locals-stack pointer; and iForth
has the best locals code size of all (but looking at the VFX code, my
guess is that this happens to be in the present case mainly because
iForth uses RSP for the data stack and some other stack for the return
stack). Actually, even with your approach of keeping the locals on
the return stack, and having a separate locals-frame pointer, I don't
see why the locals code should be worse. But looking at the start of
the VFX64 code for VICHECK1, there is a bit of superfluous work:
: VICHECK1 {: pindex paddr -- pindex' paddr :} \ Checks for valid index
\ paddr is the address of the data, the first cell of which contains
\ the array size
pindex 0 paddr @ WITHIN IF \ Index is valid
VICHECK1
( 0050A460 488BD4 ) MOV RDX, RSP
( 0050A463 48FF7500 ) PUSH QWORD [RBP]
( 0050A467 53 ) PUSH RBX
( 0050A468 52 ) PUSH RDX
( 0050A469 57 ) PUSH RDI
( 0050A46A 488BFC ) MOV RDI, RSP
( 0050A46D 4881EC00000000 ) SUB RSP, # 00000000
( 0050A474 488B5D08 ) MOV RBX, [RBP+08]
( 0050A478 488D6D10 ) LEA RBP, [RBP+10]
( 0050A47C 488B5710 ) MOV RDX, [RDI+10]
( 0050A480 488B12 ) MOV RDX, 0 [RDX]
( 0050A483 B900000000 ) MOV ECX, # 00000000
( 0050A488 482BD1 ) SUB RDX, RCX
( 0050A48B 488B4718 ) MOV RAX, [RDI+18]
( 0050A48F 482BC1 ) SUB RAX, RCX
( 0050A492 483BC2 ) CMP RAX, RDX
( 0050A495 0F8319000000 ) JNB/AE 0050A4B4
It's not clear to me why you push so much on the return stack at the
start, instead of just the two values pindex and paddr (which you do
in 0050A463 and 0050A467). Ok, you also push old locals-frame pointer
RDI in 0050A469, which is a result of having the locals on the return
stack instead of in a separate stack, but why push the old return
stack pointer? You know the size of your locals, just adjust RSP by
that much in the end.
The instruction at 0050A46D seems superfluous. My guess is that it's
there for the possible | part in the locals definition.
The next two instructions refill the TOS register RBX and adjust the
data stack pointer RBP. That completes the code for the locals
definition. From then on locals are loaded from memory, as
in iforth. Let's also inspect the end:
0 paddr \ Use zeroth index
THEN ;
( 0050A535 488D6DF0 ) LEA RBP, [RBP+-10]
( 0050A539 48C7450000000000 ) MOV QWord [RBP], # 00000000
( 0050A541 48895D08 ) MOV [RBP+08], RBX
( 0050A545 488B5F10 ) MOV RBX, [RDI+10]
( 0050A549 488B6708 ) MOV RSP, [RDI+08]
( 0050A54D 488B3F ) MOV RDI, 0 [RDI]
( 0050A550 C3 ) RET/NEXT
The THEN is right before 0050A549. The code before THEN pushes 0 and paddr
on the data stack, and stores the former TOS in memory before loading
the new TOS. The three instructions after the THEN restore the return
stack and locals-frame pointer and return.
So there is a little bit that can be done without much effort, but not
much.
I always thought that a separate locals stack is a thing I did in
Gforth out of lazyness, and pay for it by having to maintain a
separate stack pointer, but it turns out that with locals on the
return stack, you still need an extra register for locals in memory,
and you spend additional overhead.
>In the last
>decade or so there has been very little customer demand for
>faster code.
See below.
>However, higher level source code has been much
>in demand. An example is Nick Nelson's value flavoured structures,
>which are of particular merit when converting code from 32 bit to
>64 bit host Forths.
Gforth has worked on 64-bit hosts since early 1996, and I found that
Forth code tends to have fewer portability problems between 32-bit and
64-bit platforms than C code, and that's not just my code, the
applications in appbench and many others are also quite portable.
A major merit for value-flavoured structures is that you can change
the field size (e.g, from 1 byte to 2 bytes or vice versa) without
changing all the code accessing those fields. That's independent of
cell size.
>Just because many of the Forth applications visible to the Forth
>community now run on CPUs with 16 or 32 address registers
>does not mean that all systems can implement the compiler
>techniques required for high-performance locals.
It's obvious that hardly any Forth system implements register
allocation of locals, with the exception being lxf, which uses an
architecture with 8 general-purpose registers (address registers
recall bad memories from the 68000 days); and for lxf, register
allocation is limited to basic blocks or less.
>I can buy a lot of CPU cycles for the cost of one day of programmer
>time.
Some guy called Stephen Pelc (must be a different one) recentlu posted
<vbkdu0$1v8lq$1@dont-email.me>:
|We (MPE) converted much of our TCP/IP stack not to use locals. This
|was mostly on ARM7 devices, but the figures for other 32 bit CPUs of
|the period (say 15 years ago) were similar. Code density improved by
|about 25% and performance by about 50%.
How much time did that conversion cost? And this Stephen Pelc
suggested that Buzz McCool (and probably everyone else) should also
spend their time on avoiding and eliminating locals from their code.
I am with you here, not with the other Stephen Pelc: Programmers
should use locals liberally if it saves them time, even in the face of
slow locals implementations, because you can buy a lot of CPU cycles
for the additional programming cost of avoiding locals.
- 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 | Stephen Pelc <stephen@vfxforth.com> |
|---|---|
| Date | 2024-09-15 21:35 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <vc7ju4$2cu8t$1@dont-email.me> |
| In reply to | #132188 |
On 15 Sep 2024 at 18:16:34 CEST, "Anton Ertl" <Anton Ertl> wrote: >> I can buy a lot of CPU cycles for the cost of one day of programmer >> time. > > Some guy called Stephen Pelc (must be a different one) recentlu posted > <vbkdu0$1v8lq$1@dont-email.me>: > > |We (MPE) converted much of our TCP/IP stack not to use locals. This > |was mostly on ARM7 devices, but the figures for other 32 bit CPUs of > |the period (say 15 years ago) were similar. Code density improved by > |about 25% and performance by about 50%. > > How much time did that conversion cost? And this Stephen Pelc > suggested that Buzz McCool (and probably everyone else) should also > spend their time on avoiding and eliminating locals from their code. > > I am with you here, not with the other Stephen Pelc: Programmers > should use locals liberally if it saves them time, even in the face of > slow locals implementations, because you can buy a lot of CPU cycles > for the additional programming cost of avoiding locals. What you ignore is that the constraints of embedded systems with small alow CPUs (by comparison with desktop CPUs) are very different from those of desktop CPUs. Converting the TCP/IP stack was driven by the client requirement to fit a TCP/IP app into 128k/256k Flash and 16k RAM. I would not make that trade off today. So there's only one Stephen Pelc but two application domains. Stephen -- Stephen Pelc, stephen@vfxforth.com MicroProcessor Engineering, Ltd. - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)78 0390 3612, +34 649 662 974 http://www.mpeforth.com MPE website http://www.vfxforth.com/downloads/VfxCommunity/ downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2024-09-15 14:45 -0700 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <87o74o1thp.fsf@nightsong.com> |
| In reply to | #132190 |
Stephen Pelc <stephen@vfxforth.com> writes: > I would not make that trade off today. > So there's only one Stephen Pelc but two application domains. I wonder how much effort de-localizing the TCP/IP stack took, compared to hypothetically updating the compiler to optimize locals more. If the TCP/IP stack code can compile with iForth or lxf, is there a way to compare the code size with VFX's? I can understand wanting to use VFX for actual delivery, of course.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Pelc <stephen@vfxforth.com> |
|---|---|
| Date | 2024-09-16 12:19 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <vc97od$2r97o$1@dont-email.me> |
| In reply to | #132191 |
On 15 Sep 2024 at 23:45:22 CEST, "Paul Rubin" <no.email@nospam.invalid> wrote:
> Stephen Pelc <stephen@vfxforth.com> writes:
>> I would not make that trade off today.
>> So there's only one Stephen Pelc but two application domains.
>
> I wonder how much effort de-localizing the TCP/IP stack took, compared
> to hypothetically updating the compiler to optimize locals more. If the
> TCP/IP stack code can compile with iForth or lxf, is there a way to
> compare the code size with VFX's? I can understand wanting to use VFX
> for actual delivery, of course.
On modern desktop CPUs, I would probably spend the effort on
optimising locals more. However, the ability to provide the address
of a local is essential in our world. I have not inspected our code
base to see how many uses of a local declaration of a buffer
: bah {: ... | FOO[ cell ] ... -- :}
there are compared to the use of the ADDR (address) operator
applied to a normally defined local
: bah {: ... | FOO ... -- :}
...
addr FOO
Local buffers are remarkably useful.
--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com
MPE website
http://www.vfxforth.com/downloads/VfxCommunity/
downloads
[toc] | [prev] | [next] | [standalone]
| From | minforth@gmx.net (minforth) |
|---|---|
| Date | 2024-09-16 14:37 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <8e20f39a3d8702fe97b8bfdad21d853a@www.novabbs.com> |
| In reply to | #132200 |
On Mon, 16 Sep 2024 12:19:25 +0000, Stephen Pelc wrote:
> Local buffers are remarkably useful.
True. In addition, to pass the address of normal locals
to other words or to external library functions
(pass-by-reference instead of pass-by-value)
I borrowed the address operator & from C, like in:
: FUNC { f: a b -- badr f: aval }
... a \ push value of a to fp-stack
... &b \ push address of b to stack
... ;
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-09-16 17:37 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <2024Sep16.193719@mips.complang.tuwien.ac.at> |
| In reply to | #132200 |
Stephen Pelc <stephen@vfxforth.com> writes:
>On 15 Sep 2024 at 23:45:22 CEST, "Paul Rubin" <no.email@nospam.invalid> wrote:
>
>> Stephen Pelc <stephen@vfxforth.com> writes:
>>> I would not make that trade off today.
>>> So there's only one Stephen Pelc but two application domains.
>>
>> I wonder how much effort de-localizing the TCP/IP stack took, compared
>> to hypothetically updating the compiler to optimize locals more. If the
>> TCP/IP stack code can compile with iForth or lxf, is there a way to
>> compare the code size with VFX's? I can understand wanting to use VFX
>> for actual delivery, of course.
>
>On modern desktop CPUs, I would probably spend the effort on
>optimising locals more. However, the ability to provide the address
>of a local is essential in our world. I have not inspected our code
>base to see how many uses of a local declaration of a buffer
>: bah {: ... | FOO[ cell ] ... -- :}
>there are compared to the use of the ADDR (address) operator
>applied to a normally defined local
>: bah {: ... | FOO ... -- :}
>...
> addr FOO
Yes, that's why Gforth does not support ADDR for locals by default:
: bah {: ... | FOO ... -- :}
...
addr foo
*the terminal*:3:8: error: Unsupported operation
addr >>>foo<<<
If you want that, there are two options: Either make it explicit with
WA: which local should support ADDR:
: bah {: ... | wa: FOO ... -- :}
...
addr foo
;
compiles without error. Alternatively, you can force slow mode on all
locals with DEFAULT-WA:. So
default-wa:
: bah {: ... | FOO ... -- :}
...
addr foo
;
compiles without error.
One intermediate option is to warn about ADDR applied to locals
defined without WA: FA: DA: CA:. Once the program compiles without
any of these warnings, you can set
DEFAULT-W:
to gain the full speed for all the other locals.
- 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 | mhx@iae.nl (mhx) |
|---|---|
| Date | 2024-09-16 18:58 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <e2d54b78169fdb62b22cacd72aee1f2d@www.novabbs.com> |
| In reply to | #132207 |
On Mon, 16 Sep 2024 17:37:19 +0000, Anton Ertl wrote: [..] > Yes, that's why Gforth does not support ADDR for locals by default: iForth supports getting the address of any type local with " 'OF a ". This indeed has a negative effect on execution time. The experimental PARAMS| a | construct does not support 'OF and tries to keep integer locals in a register. It is not successful when there are too many locals. Maybe I'll repair that with the next major revision. -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2024-09-16 19:26 +0000 |
| Subject | Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!] |
| Message-ID | <2024Sep16.212601@mips.complang.tuwien.ac.at> |
| In reply to | #132208 |
mhx@iae.nl (mhx) writes:
>The experimental PARAMS| a | construct does not support 'OF and tries
>to keep integer locals in a register.
Great. And using the same order as {: ... :} is also great. Now if
only (LOCAL) (which is used by the reference implementation of {:
... :}) used the same mechanism.
I just tried VICHECK1 with PARAMS| ... | instead of {: ... :}
401 336 gforth-fast (AMD64)
179 132 lxf 1.6-982-823 (IA-32)
182 119 VFX FX Forth for Linux IA32 Version: 4.72 (IA-32)
241 159 VFX Forth 64 5.43 (AMD64)
163 175 iforth-5.1 mini (AMD64)
182 iforth-5.1 mini using PARAMS|
Looking at the code, you store these registered locals on the locals
stack before the IF, and then load them into registers again after the
IF, and then reload them after every call (so apparently the registers
you use for them are caller-saved in iforth). And the problem in this
code is that ever local is used at most once between calls, so storing
it in a caller-saved register results in no better code than storing
it in memory.
Let's see how the 3DUP.3 example fares:
instr. bytes system
28 103 Gforth AMD64
16 44 iforth 5.0.27 (plus 20 bytes entry and return code)
8 11 iforth 5.0.27 PARAMS| (plus 20 bytes entry and return code)
7 19 lxf 1.6-982-823 32-bit
32 127 SwiftForth 4.0.0-RC89 (calls LSPACE)
26 92 VFX Forth 64 5.11 RC2
Yes, in the right setting PARAMS| is very nice, too bad it's not used
for (LOCAL) (or directly for {:).
- 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]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web