Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #7710 > unrolled thread
| Started by | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| First post | 2011-12-03 19:07 +0000 |
| Last post | 2011-12-08 03:37 -0600 |
| Articles | 20 on this page of 187 — 17 participants |
Back to article view | Back to comp.lang.forth
Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-03 19:07 +0000
Re: Memoizing recursive words "A. K." <akk@nospam.org> - 2011-12-04 13:21 +0100
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-04 14:20 +0000
Re: Memoizing recursive words Josh Grams <josh@qualdan.com> - 2011-12-04 16:03 +0000
Re: Memoizing recursive words "A. K." <akk@nospam.org> - 2011-12-04 17:25 +0100
Re: Memoizing recursive words BruceMcF <agila61@netscape.net> - 2011-12-04 10:51 -0800
Re: Memoizing recursive words "Elizabeth D. Rather" <erather@forth.com> - 2011-12-04 12:50 -1000
Re: Memoizing recursive words BruceMcF <agila61@netscape.net> - 2011-12-04 15:40 -0800
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-05 11:17 +0000
Re: Memoizing recursive words "Elizabeth D. Rather" <erather@forth.com> - 2011-12-04 08:24 -1000
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-04 19:14 +0000
Re: Memoizing recursive words BruceMcF <agila61@netscape.net> - 2011-12-04 12:09 -0800
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-05 04:00 +0000
Re: Memoizing recursive words BruceMcF <agila61@netscape.net> - 2011-12-07 12:41 -0800
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-05 11:04 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 07:24 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 04:02 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 08:03 +0000
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-06 10:46 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 04:54 -0600
Re: Memoizing recursive words Hans Bezemer <thebeez@xs4all.nl> - 2011-12-08 00:08 +0100
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 12:36 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 10:28 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 16:32 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 10:40 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 16:51 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 12:03 -0600
Re: Memoizing recursive words Hans Bezemer <thebeez@xs4all.nl> - 2011-12-07 23:55 +0100
Re: Memoizing recursive words Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-07 01:06 +0100
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 03:37 -0600
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-07 10:36 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 06:23 -0600
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-07 13:50 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 11:49 -0600
Re: Memoizing recursive words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-08 15:36 +0000
Re: Memoizing recursive words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-08 16:15 +0000
Re: Memoizing recursive words Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-10 17:23 +0000
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-10 17:34 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 11:43 -0600
return address manipulation (was: Memoizing recursive words) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-07 13:29 +0000
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 11:55 -0600
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-08 00:03 +0100
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-07 15:11 -0800
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-08 01:52 +0100
Re: return address manipulation Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-08 11:12 +0000
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-08 18:04 +0100
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-08 15:51 +0000
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-08 12:17 -0600
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-13 13:07 -0600
Re: return address manipulation Alex McDonald <blog@rivadpm.com> - 2011-12-13 13:37 -0800
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 03:45 -0600
Re: return address manipulation Alex McDonald <blog@rivadpm.com> - 2011-12-14 01:58 -0800
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 04:09 -0600
Re: return address manipulation "Elizabeth D. Rather" <erather@forth.com> - 2011-12-14 10:43 -1000
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-14 14:08 +0100
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 09:18 -0600
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 09:48 -0600
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-14 23:24 +0100
Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 04:50 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 07:45 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-15 15:48 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 08:08 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 10:44 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 09:07 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-15 17:16 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 09:44 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-15 17:55 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 10:13 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 17:24 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 11:25 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 09:40 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 12:11 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 19:01 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 03:14 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-16 07:54 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 16:58 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-17 09:58 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-19 14:36 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-19 12:49 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-20 02:55 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-20 06:34 -0800
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 10:22 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 12:44 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 17:27 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 09:33 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 12:52 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 11:07 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 03:16 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-16 08:10 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 12:38 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-16 08:13 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 12:43 -0600
Re: Quotations [Was: return address manipulation] Sieur de Bienville <morrimichael@gmail.com> - 2011-12-17 15:35 -0800
Re: Quotations [Was: return address manipulation] Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2011-12-19 20:40 +0100
Re: Quotations [Was: return address manipulation] Sieur de Bienville <morrimichael@gmail.com> - 2011-12-19 13:41 -0800
Re: Quotations [Was: return address manipulation] Mark Wills <markrobertwills@yahoo.co.uk> - 2011-12-27 07:30 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-27 16:21 +0000
Re: Quotations [Was: return address manipulation] Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-27 20:55 +0100
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-27 14:42 -0600
Re: Quotations [Was: return address manipulation] Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-27 22:58 +0100
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-27 16:43 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-30 12:00 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-30 06:09 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-30 13:23 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-30 08:13 -0600
Re: Quotations [Was: return address manipulation] mhx@iae.nl (Marcel Hendrix) - 2011-12-30 16:48 +0200
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-30 16:36 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-30 15:16 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-31 14:00 +0000
Re: Quotations [Was: return address manipulation] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-01 12:22 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-01 06:09 -0600
Re: Quotations [Was: return address manipulation] mhx@iae.nl (Marcel Hendrix) - 2012-01-01 14:17 +0200
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-01 09:50 -0600
Re: Quotations [Was: return address manipulation] Bernd Paysan <bernd.paysan@gmx.de> - 2012-01-01 18:15 +0100
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-01 11:48 -0600
Re: Quotations [Was: return address manipulation] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-02 11:19 +0000
Re: Quotations [Was: return address manipulation] mhx@iae.nl (Marcel Hendrix) - 2012-01-01 14:02 +0200
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-01 09:37 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-02 14:30 +0000
Re: Quotations [Was: return address manipulation] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-03 13:28 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2012-01-01 13:35 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-02 14:14 +0000
Re: Quotations [Was: return address manipulation] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-03 12:04 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-31 14:19 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-31 11:46 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-02 13:47 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-02 10:19 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-03 09:08 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-03 04:47 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-03 16:55 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-03 11:28 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 14:52 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 09:54 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 17:28 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 12:10 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2012-01-03 10:09 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 17:14 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 11:26 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 17:49 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 12:11 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2012-01-04 12:59 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-05 16:46 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-03 16:34 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-03 11:40 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 15:03 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 12:01 -0600
Re: Quotations [Was: return address manipulation] Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-01-04 21:02 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-05 16:38 +0000
Re: Quotations [Was: return address manipulation] Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-01-07 14:27 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-30 11:33 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-30 11:53 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 17:18 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 13:16 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-19 15:01 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 10:40 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-22 16:21 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-22 11:40 -0600
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-26 13:01 -0600
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-27 03:54 -0600
Re: Quotations [Was: return address manipulation] Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-15 20:11 +0100
Quotations (was: return address manipulation) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-14 15:27 +0000
Re: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 09:50 -0600
Re: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-14 22:38 +0100
Re: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-14 23:03 +0000
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-15 15:56 +0000
Re: return address manipulation stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-09 14:48 +0000
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-09 16:35 +0000
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-09 10:18 -0800
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-09 12:36 -0600
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-09 12:07 -0800
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 12:37 +0000
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 11:49 -0600
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-10 10:06 -0800
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 12:37 -0600
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-10 11:28 -0800
Re: return address manipulation "Elizabeth D. Rather" <erather@forth.com> - 2011-12-09 08:39 -1000
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 12:34 +0000
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-10 06:39 -0800
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 11:30 +0000
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-06 17:18 +0000
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-07 14:30 +0000
Re: Memoizing recursive words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-07 15:33 +0000
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-07 17:09 +0000
Re: Memoizing recursive words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-07 17:26 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 12:08 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-08 00:05 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-08 03:37 -0600
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Hans Bezemer <thebeez@xs4all.nl> |
|---|---|
| Date | 2011-12-08 00:08 +0100 |
| Message-ID | <4edff194$0$6878$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #7750 |
Andrew Haley wrote: >> The performance gain for the tail recursive CALL/JMP change is often >> marginal, while the loss of reliability (it's a hidden return stack >> transformation) can be significant. The discussions at MPE on this >> issue were long and heated. Overall, we went for reliability. > > That makes some sense. Depends on the implementation. When assembly, yes maybe. But when coding such a thing in high level C, it becomes clear: CALL-RETURN - Get current address - Push on return stack - Jump .. - Get address from return stack - Jump Vs. - Jump Like I said before: the only thing is when the called word CHANGES the return stack. If there is something left on the return stack by you BEFORE you jump, you should not use tail recursion, because it isn't tail recursion - cleaning up is something that is left to do. >> I haven't measured it on current desktop CPUs, but on some >> architectures, JMP and CALL take the same space and execution time. > > Mmm, but the difference is between CALL ; RET and just JMP . > It's not the difference between a simple CALL and a JMP . Correct. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-06 12:36 +0000 |
| Message-ID | <jbl28o$c6e$1@dont-email.me> |
| In reply to | #7749 |
On Tue, 06 Dec 2011 10:46:29 +0000, Stephen Pelc wrote:
> On Tue, 6 Dec 2011 08:03:03 +0000 (UTC), Arnold Doray
> <thinksquared@gmail.com> wrote:
>
>>I notice that SwiftForth nicely does a JMP for this tail-recursive
>>ASSOC, while VFX, ( which seems otherwise to be an excellent compiler,
>>IMHO ) uses a CALL.
>
> The performance gain for the tail recursive CALL/JMP change is often
> marginal, while the loss of reliability (it's a hidden return stack
> transformation) can be significant. The discussions at MPE on this issue
> were long and heated. Overall, we went for reliability. Show me a
> measurement where the impact is significant, and I'll rethink my
> attitude.
>
> I haven't measured it on current desktop CPUs, but on some
> architectures, JMP and CALL take the same space and execution time.
>
> Stephen
From the high quality of code I've seen VFX produce I was sure MPE had a
very good reason. But I don't understand what you mean by a "hidden
return stack transformation". Could you elaborate?
As I understand it, the use of CALL vs JMP in this context has less to do
with performance than converting tail-recursive functions into an
iteration. Since CALL pushes the current IP onto the stack before making
the jump, it could potentially cause a stack overflow for large
iterations. This is why most "C" programmers shy away from recursion,
even tail-recursive ones. But reliance on tail-call optimization is very
common in languages like Scheme / Lisp, and some problems are nicely
expressed this way. Like ASSOC.
But I'm probably being pedantic. Because Forth has so little by way of
syntax, I could do it here too if I used BEGIN ... AGAIN instead of
RECURSE as Andrew suggests.
To clarify, if I replace the terminal RECURSE by AGAIN ... BEGIN, then VFX
uses a JMP instead of a CALL:
: assoc
begin
< some code >
again ;
--> VFX produces a JMP at the end of the word.
While:
: assoc
< some code>
recurse ;
--> VFX produces a CALL at the end of the word.
Can't the phrase "RECURSE ;" be replaced by just a JMP as you have done
in the BEGIN -- AGAIN construct?
Cheers,
Arnold
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-06 10:28 -0600 |
| Message-ID | <v-adnQ8WrLMA30PTnZ2dnUVZ_qmdnZ2d@supernews.com> |
| In reply to | #7752 |
Arnold Doray <thinksquared@gmail.com> wrote: > > Can't the phrase "RECURSE ;" be replaced by just a JMP as you have done > in the BEGIN -- AGAIN construct? Not always, because some silly bleepers manipulate the return stack to do control flow manipulation. Doing this isn't standard, but that isn't enough to stop everyone. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-06 16:32 +0000 |
| Message-ID | <jblg37$qhp$2@dont-email.me> |
| In reply to | #7759 |
On Tue, 06 Dec 2011 10:28:13 -0600, Andrew Haley wrote: > Arnold Doray <thinksquared@gmail.com> wrote: >> >> Can't the phrase "RECURSE ;" be replaced by just a JMP as you have done >> in the BEGIN -- AGAIN construct? > > Not always, because some silly bleepers manipulate the return stack to > do control flow manipulation. Doing this isn't standard, but that isn't > enough to stop everyone. > > Andrew. Couldn't the same error occur within in a BEGIN ... AGAIN loop? What makes RECURSE special in this respect? Arnold
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-06 10:40 -0600 |
| Message-ID | <a9udnfSVPbXg2EPTnZ2dnUVZ_uydnZ2d@supernews.com> |
| In reply to | #7760 |
Arnold Doray <thinksquared@gmail.com> wrote: > On Tue, 06 Dec 2011 10:28:13 -0600, Andrew Haley wrote: > >> Arnold Doray <thinksquared@gmail.com> wrote: >>> >>> Can't the phrase "RECURSE ;" be replaced by just a JMP as you have done >>> in the BEGIN -- AGAIN construct? >> >> Not always, because some silly bleepers manipulate the return stack to >> do control flow manipulation. Doing this isn't standard, but that isn't >> enough to stop everyone. > > Couldn't the same error occur within in a BEGIN ... AGAIN loop? What > makes RECURSE special in this respect? It pushes an address onto the return stack and jumps; AGAIN just jumps. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-06 16:51 +0000 |
| Message-ID | <jblh5p$qhp$3@dont-email.me> |
| In reply to | #7761 |
On Tue, 06 Dec 2011 10:40:29 -0600, Andrew Haley wrote: > Arnold Doray <thinksquared@gmail.com> wrote: >> On Tue, 06 Dec 2011 10:28:13 -0600, Andrew Haley wrote: >> >>> Arnold Doray <thinksquared@gmail.com> wrote: >>>> >>>> Can't the phrase "RECURSE ;" be replaced by just a JMP as you have >>>> done in the BEGIN -- AGAIN construct? >>> >>> Not always, because some silly bleepers manipulate the return stack to >>> do control flow manipulation. Doing this isn't standard, but that >>> isn't enough to stop everyone. >> >> Couldn't the same error occur within in a BEGIN ... AGAIN loop? What >> makes RECURSE special in this respect? > > It pushes an address onto the return stack and jumps; AGAIN just jumps. > > Andrew. I'm not saying that RECURSE in general should be a jump. But RECURSE ; ( ie, a RECURSE that is the *last* word in a definition ) can be compiled to a JMP. It is the same as AGAIN. AGAIN JMPs to BEGIN, while RECURSE ; (note, recurse in terminal position) should JMP to the start of the function. Arnold
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-06 12:03 -0600 |
| Message-ID | <CZCdnWPNau2RxEPTnZ2dnUVZ_tKdnZ2d@supernews.com> |
| In reply to | #7762 |
Arnold Doray <thinksquared@gmail.com> wrote: > On Tue, 06 Dec 2011 10:40:29 -0600, Andrew Haley wrote: > >> Arnold Doray <thinksquared@gmail.com> wrote: >>> On Tue, 06 Dec 2011 10:28:13 -0600, Andrew Haley wrote: >>> >>>> Arnold Doray <thinksquared@gmail.com> wrote: >>>>> >>>>> Can't the phrase "RECURSE ;" be replaced by just a JMP as you have >>>>> done in the BEGIN -- AGAIN construct? >>>> >>>> Not always, because some silly bleepers manipulate the return stack to >>>> do control flow manipulation. Doing this isn't standard, but that >>>> isn't enough to stop everyone. >>> >>> Couldn't the same error occur within in a BEGIN ... AGAIN loop? What >>> makes RECURSE special in this respect? >> >> It pushes an address onto the return stack and jumps; AGAIN just jumps. > > I'm not saying that RECURSE in general should be a jump. > > But RECURSE ; ( ie, a RECURSE that is the *last* word in a definition ) > can be compiled to a JMP. No, it can't. Not in the presence of R-stack manipulation. > It is the same as AGAIN. No, it isn't. Think about what happens if the word contains R> . Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <thebeez@xs4all.nl> |
|---|---|
| Date | 2011-12-07 23:55 +0100 |
| Message-ID | <4edfeeaa$0$6878$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #7767 |
Andrew Haley wrote: >> But RECURSE ; ( ie, a RECURSE that is the last word in a definition ) >> can be compiled to a JMP. True. > No, it can't. Not in the presence of R-stack manipulation. Also true. In 4tH, there is agressive tail-call optimization, but is needs special attention in the following cases: : someword if something else something-else then ; Will translate to: JUMP Z CALL SOMETHING JUMP to RETURN JUMP SOMETHING-ELSE RETURN While: : someword something ; Will translate to: JUMP SOMETHING However, if a RS changing word is called the tail-call optimizer has to be disabled. The occasions this is needed are rare, so detecting such a word isn't done by the compiler. The programmer has to tell the tail-call optimizer not to kick in: : someword something rs-changer [FORCE] ; I'd be delighted to know if there are other occasions this scheme doesn't work. It does so far for 20,000+ lines of code. P.S. BTW, the first example can be further optimized by writing: : someword if something exit then something-else ; Which will render to: JUMP Z JUMP SOMETHING JUMP SOMETHING-ELSE But it's ugly source ;-) Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-07 01:06 +0100 |
| Message-ID | <jbman1$nu6$1@online.de> |
| In reply to | #7759 |
Andrew Haley wrote: > Not always, because some silly bleepers manipulate the return stack to > do control flow manipulation. Doing this isn't standard, but that > isn't enough to stop everyone. No, because we are not in the C camp, where compilers are deliberately breaking programs that are "not standard", despite they work almost everywhere (which means "common practice") ;-). The return stack in Forth is visible. It's the return stack. It's not some arbitrary stack designed to keep temporary values. The main reason to make return stack control flow manipulations non-standard is that there are a few weird systems like F-PC, which use two return stack elements instead of one to store the previous IP. This is wasted time. It's just as wasted as trying to write the standard so that Chuck Moore's Forth-of-the-year could be standard. Chuck doesn't want to be standard, and next year his Forth will be different, anyways. I've implemented tail call optimization in my b16 assembler. The approach there is a pragmatic one: If you want to have the return stack manipulation feature, you add a nop between call and ;, which prevents the optimization to trigger. Since ; is a last-slot instruction on the b16, this nop would have been inserted anyways. The reason I added this optimization is not that it is that much faster, but that it saves return stack space, which is quite precious on the b16. I wouldn't do it for that reason in bigForth. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-07 03:37 -0600 |
| Message-ID | <vNKdnTQRr_RwrkLTnZ2dnUVZ_hidnZ2d@supernews.com> |
| In reply to | #7773 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: >> Not always, because some silly bleepers manipulate the return stack to >> do control flow manipulation. Doing this isn't standard, but that >> isn't enough to stop everyone. > > No, because we are not in the C camp, where compilers are deliberately > breaking programs that are "not standard", despite they work almost > everywhere (which means "common practice") ;-). Speak for yourself! :-) > The return stack in Forth is visible. It's the return stack. It's > not some arbitrary stack designed to keep temporary values. Maybe, maybe not. On some systems that's exactly what it is. > The main reason to make return stack control flow manipulations > non-standard is that there are a few weird systems like F-PC, which > use two return stack elements instead of one to store the previous > IP. There are other possible variations, such as systems with a call stack that can't be used for data. But as I've said before, allowing R-stack manipulation effectively defeats useful optimizations. For example, inlining is hard. These optimizations are far more useful than R-stack manipulation, which serves only to produce obscure write-only code. There are no upsides to R-stack manipulation, only downsides. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2011-12-07 10:36 +0000 |
| Message-ID | <4edf3e69.143030702@192.168.0.50> |
| In reply to | #7777 |
On Wed, 07 Dec 2011 03:37:49 -0600, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >But as I've said before, allowing >R-stack manipulation effectively defeats useful optimizations. I'm fairly sure that all return stack flow control words can be detected at compile time. I cannot convince myself that the number of return stack levels that they affect is entirely predictable. >For example, inlining is hard. These optimizations are far more useful >than R-stack manipulation, So far, true. >which serves only to produce obscure write-only code. There are no >upsides to R-stack manipulation, only downsides. That sounds like dogma and hand-waving. There are a very few occasions on which return stack flow control words are useful notational conveniences. For example, the MPE prefix assemblers depend on one such. It's done that way so that the user can choose between prefix and postfix notation. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-07 06:23 -0600 |
| Message-ID | <H-ydnTj_5LVFx0LTnZ2dnUVZ_hSdnZ2d@supernews.com> |
| In reply to | #7778 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Wed, 07 Dec 2011 03:37:49 -0600, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>But as I've said before, allowing >>R-stack manipulation effectively defeats useful optimizations. > > I'm fairly sure that all return stack flow control words can be > detected at compile time. I'm sure they can't unless you're conservative and mark all "suspect" uses of the R-stack as preventing inlining. >>For example, inlining is hard. These optimizations are far more useful >>than R-stack manipulation, > > So far, true. > >>which serves only to produce obscure write-only code. There are no >>upsides to R-stack manipulation, only downsides. > > That sounds like dogma and hand-waving. Even if it does, it's still true AFAIK. Perhaps I should have said that in all the code I've looked at that uses R-stack manipulation I have never seen a single use that wouldn't be improved by taking it out. But you're right in that one can never prove that X does not exist in this universe. Maybe there is a use of R-stack manipulation that makes code clearer and less obscure. (I exclude here real Forth hardware that necessarily uses R-stack manipulation to do control flow.) > There are a very few occasions on which return stack flow control > words are useful notational conveniences. For example, the MPE > prefix assemblers depend on one such. It's done that way so that > the user can choose between prefix and postfix notation. Hmmm. I've a pretty good idea how that trick works, and I don't think it needs R-stack manipulation. As usual, I'm prepared to be convinced. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2011-12-07 13:50 +0000 |
| Message-ID | <4edf693c.153985716@192.168.0.50> |
| In reply to | #7779 |
On Wed, 07 Dec 2011 06:23:52 -0600, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:
>Hmmm. I've a pretty good idea how that trick works, and I don't think
>it needs R-stack manipulation. As usual, I'm prepared to be
>convinced.
Prove it.
So here's a simple and not entirely portable implementation
that works on most desktop class CPUs and classical Forths.
The original code was presented by Bob Smith at a FORML conference.
Your version should preserve the prefix/postfix switch.
2variable aprior \ holds previous instruction and data
0 0 aprior 2!
variable <prefix> \ prefix/postfix mode
<prefix> on
: prefix? \ -- t/f ; true if in prefix mode
<prefix> @
;
: ?prefix \ n -- n' ; executes previous opcode
prefix? if
r>
aprior 2@ 2swap aprior 2!
>r
endif
;
The assembler uses this, often as below, to permit prefix or
postfix operation.
: 2op-r/m \ op1 op2 reg -- ; reg/mem16 --
create
, , ,
does>
?prefix \ do the last one
... \ lay the code
reset \ ready for next opcode
;
$0f $00 $02 2op-r/m LLDT
...
There is a derivative with fewer side effects, but it's harder
to understand. What is nice about ?PREFIX is that you just stick
it into a Forth assembler in the right places and the assembler
becomes switchable between prefix and postfix.
Stephen
--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-07 11:49 -0600 |
| Message-ID | <OvadnVJPp7SBOkLTnZ2dnUVZ_rydnZ2d@supernews.com> |
| In reply to | #7782 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Wed, 07 Dec 2011 06:23:52 -0600, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
>
>>Hmmm. I've a pretty good idea how that trick works, and I don't think
>>it needs R-stack manipulation. As usual, I'm prepared to be
>>convinced.
>
> Prove it.
I'm not sure what "it" is in this context.
> So here's a simple and not entirely portable implementation
> that works on most desktop class CPUs and classical Forths.
> The original code was presented by Bob Smith at a FORML conference.
> Your version should preserve the prefix/postfix switch.
>
> 2variable aprior \ holds previous instruction and data
> 0 0 aprior 2!
>
> variable <prefix> \ prefix/postfix mode
> <prefix> on
>
> : prefix? \ -- t/f ; true if in prefix mode
> <prefix> @
> ;
>
> : ?prefix \ n -- n' ; executes previous opcode
> prefix? if
> r>
> aprior 2@ 2swap aprior 2!
> >r
> endif
> ;
>
> The assembler uses this, often as below, to permit prefix or
> postfix operation.
>
> : 2op-r/m \ op1 op2 reg -- ; reg/mem16 --
> create
> , , ,
> does>
> ?prefix \ do the last one
> ... \ lay the code
> reset \ ready for next opcode
> ;
>
> $0f $00 $02 2op-r/m LLDT
> ...
Jeez, that's evil. :-)
> There is a derivative with fewer side effects, but it's harder
> to understand. What is nice about ?PREFIX is that you just stick
> it into a Forth assembler in the right places and the assembler
> becomes switchable between prefix and postfix.
Hmmm, that's impressively devious. Perhaps I've missed something, but
isn't ?PREFIX just
: (prefix) ( a)
body> aprior @ swap aprior !
<prefix> off execute <prefix> on ;
: ?prefix
postpone prefix? postpone if
postpone (prefix) postpone exit
postpone then ; immediate
Unfortuately that's not portable either because of the BODY> , although
I think most Forths can do it. I wonder if there's a nice portable
way.
It'd be more difficult in the case of something like
: blah x y z ?prefix a b c ;
but I don't think an assembler ever needs to do that.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-08 15:36 +0000 |
| Message-ID | <2011Dec8.163611@mips.complang.tuwien.ac.at> |
| In reply to | #7782 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Wed, 07 Dec 2011 06:23:52 -0600, Andrew Haley
><andrew29@littlepinkcloud.invalid> wrote:
>
>>Hmmm. I've a pretty good idea how that trick works, and I don't think
>>it needs R-stack manipulation. As usual, I'm prepared to be
>>convinced.
>
>Prove it.
...
>Your version should preserve the prefix/postfix switch.
>
>2variable aprior \ holds previous instruction and data
> 0 0 aprior 2!
>
>variable <prefix> \ prefix/postfix mode
> <prefix> on
>
>: prefix? \ -- t/f ; true if in prefix mode
> <prefix> @
>;
>
>: ?prefix \ n -- n' ; executes previous opcode
> prefix? if
> r>
> aprior 2@ 2swap aprior 2!
> >r
> endif
>;
>
>The assembler uses this, often as below, to permit prefix or
>postfix operation.
>
>: 2op-r/m \ op1 op2 reg -- ; reg/mem16 --
> create
> , , ,
> does>
> ?prefix \ do the last one
> ... \ lay the code
> reset \ ready for next opcode
>;
Andrew presented a version that uses BODY>. If you don't insist on
using the same syntax, this can also be implemented in standard Forth
(untested):
: create-?prefix ( "name" -- )
>in @ create >in ! ' , ;
: (?prefix) ( addr1 -- addr2 )
prefix? if
dup cell+ swap @ ( addr2 xt )
aprior 2@ 2swap aprior 2!
execute exit
then
cell+ ;
: does>-?prefix ( -- )
postpone does> postpone (?prefix) ;
: 2op-r/m \ op1 op2 reg -- ; reg/mem16 --
create-?prefix
, , ,
does>-?prefix \ do the last one
... \ lay the code
reset \ ready for next opcode
;
\ the rest is not affected by the changed syntax
$0f $00 $02 2op-r/m LLDT
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-08 16:15 +0000 |
| Message-ID | <2011Dec8.171537@mips.complang.tuwien.ac.at> |
| In reply to | #7832 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Andrew presented a version that uses BODY>. If you don't insist on
>using the same syntax, this can also be implemented in standard Forth
>(untested):
>
>: create-?prefix ( "name" -- )
> >in @ create >in ! ' , ;
>
>: (?prefix) ( addr1 -- addr2 )
> prefix? if
> dup cell+ swap @ ( addr2 xt )
> aprior 2@ 2swap aprior 2!
> execute exit
> then
> cell+ ;
>
>: does>-?prefix ( -- )
> postpone does> postpone (?prefix) ;
>
>: 2op-r/m \ op1 op2 reg -- ; reg/mem16 --
> create-?prefix
> , , ,
> does>-?prefix \ do the last one
> ... \ lay the code
> reset \ ready for next opcode
>;
>
>\ the rest is not affected by the changed syntax
>
>$0f $00 $02 2op-r/m LLDT
Hmm, I think that leads to an endless recursion if PREFIX? is true,
because the EXECUTE always starts such a word again from the start
(alternating between the latest and the previous one). And there are
other bugs. All of them are correct in Andrew Haley's version. So
let's see how I can correct that:
: create-?prefix ( "name" -- )
>in @ create >in ! ' , ;
: (?prefix) ( addr1 -- addr2 )
dup cell+ swap @ ( addr2 xt )
aprior 2@ 2swap aprior 2!
<prefix> off execute <prefix> on exit
then ;
: does>-?prefix ( -- )
postpone does>
postpone prefix? postpone if
postpone (?prefix) postpone exit
postpone then
postpone cell+ ; immediate
: 2op-r/m \ op1 op2 reg -- ; reg/mem16 --
create-?prefix
, , ,
does>-?prefix \ do the last one
... \ lay the code
reset \ ready for next opcode
;
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2011-12-10 17:23 +0000 |
| Message-ID | <lw00b3.4b5@spenarnc.xs4all.nl> |
| In reply to | #7782 |
In article <4edf693c.153985716@192.168.0.50>, Stephen Pelc <stephenXXX@INVALID.mpeforth.com> wrote: >On Wed, 07 Dec 2011 06:23:52 -0600, Andrew Haley ><andrew29@littlepinkcloud.invalid> wrote: > >>Hmmm. I've a pretty good idea how that trick works, and I don't think >>it needs R-stack manipulation. As usual, I'm prepared to be >>convinced. > >Prove it. > >So here's a simple and not entirely portable implementation >that works on most desktop class CPUs and classical Forths. >The original code was presented by Bob Smith at a FORML conference. >Your version should preserve the prefix/postfix switch. > >2variable aprior \ holds previous instruction and data > 0 0 aprior 2! The Pentium has instructions with both address data and immediate data plus operands that can be specified by complicated expressions like [AX +8* BX]. Then there are prefixes. I really wonder how you store that in a 2-variable? Or is that a simplification for pedagogic purposes? > >variable <prefix> \ prefix/postfix mode > <prefix> on > >: prefix? \ -- t/f ; true if in prefix mode > <prefix> @ >; > >: ?prefix \ n -- n' ; executes previous opcode > prefix? if > r> > aprior 2@ 2swap aprior 2! > >r > endif >; > >The assembler uses this, often as below, to permit prefix or >postfix operation. > >: 2op-r/m \ op1 op2 reg -- ; reg/mem16 -- > create > , , , > does> > ?prefix \ do the last one > ... \ lay the code > reset \ ready for next opcode >; Does this work out for error detection? > >$0f $00 $02 2op-r/m LLDT >... > >There is a derivative with fewer side effects, but it's harder >to understand. What is nice about ?PREFIX is that you just stick >it into a Forth assembler in the right places and the assembler >becomes switchable between prefix and postfix. > >Stephen Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2011-12-10 17:34 +0000 |
| Message-ID | <4ee396c8.164004287@192.168.0.50> |
| In reply to | #7896 |
On 10 Dec 2011 17:23:27 GMT, Albert van der Horst
<albert@spenarnc.xs4all.nl> wrote:
>>2variable aprior \ holds previous instruction and data
>> 0 0 aprior 2!
>
>The Pentium has instructions with both address data and immediate
>data plus operands that can be specified by complicated
>expressions like [AX +8* BX]. Then there are prefixes.
>I really wonder how you store that in a 2-variable?
>Or is that a simplification for pedagogic purposes?
: ?prefix \ struct -- struct' ; executes previous opcode
prefix? if
r> \ -- struct pc
aprior 2@ 2swap aprior 2!
>r
endif
;
What is stored in APRIOR is a pointer to a data structure, the address
returned by DOES>, and the address to be executed. Just two items.
The examples are taken from a production assembler. We have used this
technique for 20+ years.
>>: 2op-r/m \ op1 op2 reg -- ; reg/mem16 --
>> create
>> , , ,
>> does>
>> ?prefix \ do the last one
>> ... \ lay the code
>> reset \ ready for next opcode
>>;
>
>Does this work out for error detection?
The error handler is a few lines that are also sensitive to the
prefix/postfix mode.
Stephen
--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-10 11:43 -0600 |
| Message-ID | <79mdnYVu9J_HB37TnZ2dnUVZ_oadnZ2d@supernews.com> |
| In reply to | #7896 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <4edf693c.153985716@192.168.0.50>, > Stephen Pelc <stephenXXX@INVALID.mpeforth.com> wrote: > >>So here's a simple and not entirely portable implementation >>that works on most desktop class CPUs and classical Forths. >>The original code was presented by Bob Smith at a FORML conference. >>Your version should preserve the prefix/postfix switch. >> >>2variable aprior \ holds previous instruction and data >> 0 0 aprior 2! > > The Pentium has instructions with both address data and immediate > data plus operands that can be specified by complicated > expressions like [AX +8* BX]. Then there are prefixes. > I really wonder how you store that in a 2-variable? > Or is that a simplification for pedagogic purposes? This isn't really anything to do with the Pentium ISA is it? All that the 2variable stores is a code address and a data address. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-07 13:29 +0000 |
| Subject | return address manipulation (was: Memoizing recursive words) |
| Message-ID | <2011Dec7.142922@mips.complang.tuwien.ac.at> |
| In reply to | #7778 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Wed, 07 Dec 2011 03:37:49 -0600, Andrew Haley
><andrew29@littlepinkcloud.invalid> wrote:
>
>>But as I've said before, allowing
>>R-stack manipulation effectively defeats useful optimizations.
>
>I'm fairly sure that all return stack flow control words can be
>detected at compile time.
Yes.
However, the more Forth-style way IMO would be to notify the compiler
of the return-address manipulation rather than have the compiler
perform data-flow analysis.
>I cannot convince myself that the number
>of return stack levels that they affect is entirely predictable.
In the usual (among return-address manipulating programs) cases it is,
but of course there could be things like:
( n ) begin
dup while
r> drop 1- repeat
But these cases are so rare that it would not be a problem to disable
inlining and tail-call optimization for all callers (even through
multiple levels of direct calls) of such words.
The main problem is EXECUTE etc. (e.g. DEFERred words); in most cases
you cannot exclude the possibility of an EXECUTE executing an
arbitrary word, including a word that performs some return address
manipulation. So the compiler would have to disable inlining and
tail-call optimization for all words that contain EXECUTE or call
DEFERred words (and words that call such words etc.). That would
disable these optimizations for a pretty large part of the code.
>>For example, inlining is hard. These optimizations are far more useful
>>than R-stack manipulation,
>
>So far, true.
That's in the eye of the beholder.
What I find more problematic about return-address manipulation is that
it is not compatible with other (standard) features, in particular,
locals. That's why it cannot be properly added as a feature to the
standard.
There is also the issue of processors that put the return addresses in
a place that is not accessible as data, but I doubt that Forth
implementations for these CPUs are fully compliant anyway, so if we
standardized return-address manipulation, that would be just one
standard feature among several that such a system does not implement.
Another implementation issue is that compilation-through-C becomes
harder and produces much slower code if it has to support
return-address manipulation. However, AFAIK no such system is
currently maintained (not sure what became of Rob Chapman's Timbre
system), so maybe we should not worry about that too much.
The uses of return-address manipulation I have seen from Bernd can be
replaced without too much effort with quotations (nested variants of
:NONAME words) and words that take xts. Some of the things Michael
Gassanenko has done may be harder to replace (not sure).
Overall, I think that we should add quotations and use them to replace
return-address manipulating code. Then the compiler can happily
perform inlining and tail-call optimization.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web