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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-14 15:27 +0000 |
| Subject | Quotations (was: return address manipulation) |
| Message-ID | <2011Dec14.162757@mips.complang.tuwien.ac.at> |
| In reply to | #8045 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>RECURSE doesn't work properly, though; is that a
>problem? Do we even know what RECURSE should to inside a quotation?
That would be up for discussion, but my opinion is that it should be
specified to do the following:
RECURSE calls the definition/quotation that directly contains it.
Example:
: foo
... recurse ... \ calls foo
[: ... recurse ... ;] \ calls first quotation
... recurse ... \ calls foo
[: ... recurse ... \ calls second quotation
[: ... recurse ... ;] \ calls quotation 2.1
... recurse ... ;] \ calls second quotation
... recurse ... \ calls foo
;
>The capture of locals' values would be nice to have, but perhaps
>that's rather too much.
Yes, expensive to implement. IMO using the names of locals that are
defined in definitions or quotations outside the directly containing
definition/quotation should be specified to be an ambiguous condition.
So an ambitious implementor can implement full closures (and maybe
they will catch on), but the rest will not be burdened with this
requirement.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-14 09:50 -0600 |
| Subject | Re: Quotations |
| Message-ID | <ZcOdnY6D6fg0WHXTnZ2dnUVZ_jOdnZ2d@supernews.com> |
| In reply to | #8066 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > IMO using the names of locals that are defined in definitions or > quotations outside the directly containing definition/quotation > should be specified to be an ambiguous condition. So an ambitious > implementor can implement full closures (and maybe they will catch > on), but the rest will not be burdened with this requirement. This makes sense. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-14 22:38 +0100 |
| Subject | Re: Quotations |
| Message-ID | <jcb50a$g6i$1@online.de> |
| In reply to | #8069 |
Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>> IMO using the names of locals that are defined in definitions or
>> quotations outside the directly containing definition/quotation
>> should be specified to be an ambiguous condition. So an ambitious
>> implementor can implement full closures (and maybe they will catch
>> on), but the rest will not be burdened with this requirement.
>
> This makes sense.
I'd expect that closures in Forth would be more explicit than just
having a local of an outside scope inside a quotation, especially I'd
expect closures to take their parameters from the stack. Something like
: foo
3 4 [{: a b :} a b + ;] execute . ;
foo 7 ok
would create a closure with two values. At least I would know how to
implement this, whereas an implicit closure with out-of-scope locals...
that's beyond the analysis capabilities I want a Forth compiler to have.
The way to implement this requires two things: a pointer to the
"currently active closure", which is saved and restored by the closure's
entry and exit point. Closure values use that pointer to refer to the
data, otherwise they work like locals.
And to create the closure itself, you allocate some memory, and use
CREATE DOES> there to set up the memory area (with a nameless CREATE).
The part following DOES> is the code after :}, preceeded by a >closure.
Memory? Closures need dynamic memory allocation, so you probably have
to explicitely free them in Forth.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-12-14 23:03 +0000 |
| Subject | Re: Quotations |
| Message-ID | <jcb9u6$474$1@dont-email.me> |
| In reply to | #8075 |
On 14/12/2011 21:38, Bernd Paysan wrote:
> Andrew Haley wrote:
>
>> Anton Ertl<anton@mips.complang.tuwien.ac.at> wrote:
>>
>>> IMO using the names of locals that are defined in definitions or
>>> quotations outside the directly containing definition/quotation
>>> should be specified to be an ambiguous condition. So an ambitious
>>> implementor can implement full closures (and maybe they will catch
>>> on), but the rest will not be burdened with this requirement.
>>
>> This makes sense.
>
> I'd expect that closures in Forth would be more explicit than just
> having a local of an outside scope inside a quotation, especially I'd
> expect closures to take their parameters from the stack. Something like
>
> : foo
> 3 4 [{: a b :} a b + ;] execute . ;
>
> foo 7 ok
>
> would create a closure with two values. At least I would know how to
> implement this, whereas an implicit closure with out-of-scope locals...
> that's beyond the analysis capabilities I want a Forth compiler to have.
>
> The way to implement this requires two things: a pointer to the
> "currently active closure", which is saved and restored by the closure's
> entry and exit point. Closure values use that pointer to refer to the
> data, otherwise they work like locals.
>
> And to create the closure itself, you allocate some memory, and use
> CREATE DOES> there to set up the memory area (with a nameless CREATE).
> The part following DOES> is the code after :}, preceeded by a>closure.
>
> Memory? Closures need dynamic memory allocation, so you probably have
> to explicitely free them in Forth.
>
Did you ever see the implementation I wrote a couple of years or so ago.
It does some very similar things.
www.qlikz.org/forth/library/lambda.zip
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-15 15:56 +0000 |
| Subject | Re: Quotations |
| Message-ID | <2011Dec15.165636@mips.complang.tuwien.ac.at> |
| In reply to | #8075 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Andrew Haley wrote:
>
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>
>>> IMO using the names of locals that are defined in definitions or
>>> quotations outside the directly containing definition/quotation
>>> should be specified to be an ambiguous condition. So an ambitious
>>> implementor can implement full closures (and maybe they will catch
>>> on), but the rest will not be burdened with this requirement.
>>
>> This makes sense.
>
>I'd expect that closures in Forth would be more explicit than just
>having a local of an outside scope inside a quotation,
But that's the meaning of "closure". E.g., the definition from
<http://en.wikipedia.org/wiki/Closure_(computer_science)>:
|a closure (also lexical closure, function closure, function value or
|functional value) is a function together with a referencing
|environment for the non-local variables of that function.[1] A closure
|allows a function to access variables outside its typical scope.
> especially I'd
>expect closures to take their parameters from the stack. Something like
>
>: foo
> 3 4 [{: a b :} a b + ;] execute . ;
That's just quotations with locals and does not need a special syntax:
: foo
3 4 [: {: a b :} a b + ;] execute . ;
A closure would be:
: foo
3 4 {: a b :}
[: a b + ;] execute ;
Hmm, reading on, I see that what you have in mind is not quotations
with locals, but that does not come out in your example. Let's try a
different one:
: foo
3 4 [{: a b :} a b + ;] ;
foo 1 swap execute . . \ should print 7 1
So it takes numbers from the stack when the xt is pushed on the stack,
not when the EXECUTE happens. Yes, you would be able to simulate
closures with that, but would already run into the problems mentioned
below.
>would create a closure with two values. At least I would know how to
>implement this, whereas an implicit closure with out-of-scope locals...
>that's beyond the analysis capabilities I want a Forth compiler to have.
You don't need any particular analysis capabilities unless you want a
particularly efficient implementation. However, a simple,
straightforward implementation has two problems:
1) It increases the costs of stuff that does not need closures (should
be manageable with a little analysis).
2) Either the closures are restricted (do not execute them after the
lifetime of the free variables has ended for other reasons), or we
have to use automatic storage reclamation for them (which does not
really fit into Forth).
>Memory? Closures need dynamic memory allocation, so you probably have
>to explicitely free them in Forth.
If you are going that far, you can implement real closures almost as
easily. But given the different usage from quotations, they should be
separated from quotations, in syntax (which you do) and in
discussions. Hmm, one might also have closures with the lifetime
restriction and without explicit freeing, and syntactically different
closures without lifetime restriction that need to be freed
explicitly.
- 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 | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2011-12-09 14:48 +0000 |
| Subject | Re: return address manipulation |
| Message-ID | <4ee21d7d.67416955@192.168.0.50> |
| In reply to | #7833 |
On Thu, 08 Dec 2011 15:51:53 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Please elaborate! Do you know of any standard systems on CPUs where >the return addresses cannot be accessed as data? Or at least of CPUs >large enough for standard systems that have such a restriction? In all ARM systems using the Thumb instruction set, bit 0 is set in the value on the return stack, even though this actually refers to an even address. There are several CPUs, e.g. PIC24/30 in which the return address is not necessarily the same size as a data cell. There are 8051 systems in which the return address is not saved on a Forth stack. In standards and portability terms, you cannot assume the size, location or meaning of the return address item. You have to use new words such as Michael Gassanenko's Open Interpreter word set. We have all wanted return address issues to go away for many years, but silicon designers have just not heard our pleas. We just have to accept this. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-09 16:35 +0000 |
| Subject | Re: return address manipulation |
| Message-ID | <2011Dec9.173518@mips.complang.tuwien.ac.at> |
| In reply to | #7856 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Thu, 08 Dec 2011 15:51:53 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Please elaborate! Do you know of any standard systems on CPUs where
>>the return addresses cannot be accessed as data? Or at least of CPUs
>>large enough for standard systems that have such a restriction?
>
>In all ARM systems using the Thumb instruction set, bit 0 is set in
>the value on the return stack, even though this actually refers to
>an even address.
As long as the only thing we do with a return address is to remove it
from the return stack and possibly push it back on later and jump to
it by performing an actual return, the actual format of a return
"address" is irrelevant. That usage scheme covers most of the uses
that Bernd Paysan and Michael Gassanenko are doing, and anything
beyond (like accessing and skipping literal data) is even less
portable anyway (even outside ARM-based systems).
In any case, on the ARM the return addresses may have a funny format,
but they are accessible as data.
>There are several CPUs, e.g. PIC24/30 in which the return address
>is not necessarily the same size as a data cell.
Are there fully compliant standard systems for these processors? And
are the return addresses larger than a data cell? If not, that's not
a problem.
>There are 8051 systems in which the return address is not saved on
>a Forth stack.
Yes, Andrew mentioned that. Still, my feeling is that a system
implementor will rather leave more memory to the programmer than to
provide all of the core words (hmm, ok, they could provide many of the
words as a listing to type in, then they would not consume memory
unless typed in). Does MPE have a fully compliant standard system for
the 8051? I'd rather expect an umbilical system.
- 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 | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-12-09 10:18 -0800 |
| Subject | Re: return address manipulation |
| Message-ID | <813045fd-9574-420c-b010-bfe7e9ffbc63@k10g2000yqk.googlegroups.com> |
| In reply to | #7859 |
On Dec 9, 11:35 am, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > As long as the only thing we do with a return address is to > remove it from the return stack and possibly push it back on > later and jump to it by performing an actual return, the actual > format of a return "address" is irrelevant. But if the value is actually modified, it can't be done with words named >R and R> which will caused massive legacy code breakage if they do not preserve cell values. > That usage scheme covers most of the uses > that Bernd Paysan and Michael Gassanenko are doing, and anything > beyond (like accessing and skipping literal data) is even less > portable anyway (even outside ARM-based systems). >RET and >RET as single-cell operations would address cases where the return stack is accessible and no larger than a cell, but where for a variety of reasons the return stack is not actually used as the rack. In typical implementations, they'd just be synonyms for >R and R> ... ... that only leaves processors with return stack entries larger than a single cell outside the scope of those words. To include those and have a useful system, it does seem like you'd indeed need to go to the Open Interpreter proposal or something of similar scope: http://forth.sourceforge.net/wordset/open-interpreter/OI-norma.htm
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-09 12:36 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <sJGdnVgfwLiOyH_TnZ2dnUVZ_qqdnZ2d@supernews.com> |
| In reply to | #7859 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > stephenXXX@mpeforth.com (Stephen Pelc) writes: >>There are 8051 systems in which the return address is not saved on >>a Forth stack. > > Yes, Andrew mentioned that. Still, my feeling is that a system > implementor will rather leave more memory to the programmer than to > provide all of the core words (hmm, ok, they could provide many of the > words as a listing to type in, then they would not consume memory > unless typed in). Err, type in? Is this a joke? It'd be distributed electronically, surely. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-12-09 12:07 -0800 |
| Subject | Re: return address manipulation |
| Message-ID | <f961ed64-2f8c-4050-a0e7-0a9964dbac55@f11g2000yql.googlegroups.com> |
| In reply to | #7861 |
On Dec 9, 1:36 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote: >> Yes, Andrew mentioned that. Still, my feeling is that a system >> implementor will rather leave more memory to the programmer than to >> provide all of the core words (hmm, ok, they could provide many of the >> words as a listing to type in, then they would not consume memory >> unless typed in). > Err, type in? Is this a joke? It'd be distributed electronically, > surely. I think rather the point being acknowledged is that if a full system is on the microcontroller, it is a CORE system even if it does not ship with the full CORE in dictionary, so long as if the rest of the CORE is provided somehow. "Typing it in" is just a colorfully distracting way to express it. If its a serial port console, you'd obviously prefer to copy the definition in electronic form and feed it in through your console program. For a cross-compiler set-up, all of that is neither here nor there, since what is on the microcontroller is the runtime code, so if any of the return stack manipulations would occur at runtime, they have to work on the microcontroller, whether or not the microcontroller contains a complete CORE.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-10 12:37 +0000 |
| Subject | Re: return address manipulation |
| Message-ID | <2011Dec10.133756@mips.complang.tuwien.ac.at> |
| In reply to | #7861 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Still, my feeling is that a system
>> implementor will rather leave more memory to the programmer than to
>> provide all of the core words (hmm, ok, they could provide many of the
>> words as a listing to type in, then they would not consume memory
>> unless typed in).
>
>Err, type in? Is this a joke? It'd be distributed electronically,
>surely.
For the point of this discussion (as well as for my opinion of quality
of the system), that makes little difference. The "provides as
listing" option used to be mentioned regularly as a way to standard
compliance in earlier years; it's probably mentioned somewhere in the
standard.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-10 11:49 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <PJWdnWID1PtYBn7TnZ2dnUVZ_j2dnZ2d@supernews.com> |
| In reply to | #7885 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Still, my feeling is that a system implementor will rather leave >>> more memory to the programmer than to provide all of the core >>> words (hmm, ok, they could provide many of the words as a listing >>> to type in, then they would not consume memory unless typed in). >> >>Err, type in? Is this a joke? It'd be distributed electronically, >>surely. > > For the point of this discussion (as well as for my opinion of quality > of the system), that makes little difference. The "provides as > listing" option used to be mentioned regularly as a way to standard > compliance in earlier years; it's probably mentioned somewhere in the > standard. It says "may provide definitions, including definitions of words in the Core word set, in source form only." I think the implication is that it's machine-readable source, not a listing. On desktop systems (not an 8051, admittedly) compilation of the source might be so fast that a user wouldn't even notice it happening when the system was started. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-12-10 10:06 -0800 |
| Subject | Re: return address manipulation |
| Message-ID | <1864ed93-239a-49ee-a3f5-c32a91f5dfaf@h18g2000yqg.googlegroups.com> |
| In reply to | #7901 |
On Dec 10, 12:49 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote: > > Andrew Haley <andre...@littlepinkcloud.invalid> writes: > >>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote: > >>> Still, my feeling is that a system implementor will rather leave > >>> more memory to the programmer than to provide all of the core > >>> words (hmm, ok, they could provide many of the words as a listing > >>> to type in, then they would not consume memory unless typed in). > > >>Err, type in? Is this a joke? It'd be distributed electronically, > >>surely. > > > For the point of this discussion (as well as for my opinion of quality > > of the system), that makes little difference. The "provides as > > listing" option used to be mentioned regularly as a way to standard > > compliance in earlier years; it's probably mentioned somewhere in the > > standard. > > It says "may provide definitions, including definitions of words in > the Core word set, in source form only." I think the implication is > that it's machine-readable source, not a listing. On desktop systems > (not an 8051, admittedly) compilation of the source might be so fast > that a user wouldn't even notice it happening when the system was > started. It would typically be a machine readable listing rather than a printed one, but the standard is awfully vague. But its more a rhetorical point than a pragmatic one, as it'd be highly unlikely to have a printed listing would be distributed without a machine readable file of the listing, and even for systems with just a bidirectional serial port as the console, its highly unlikely to be just a dumb terminal at the other end.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-10 12:37 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <iPSdnb-Zx5lGO37TnZ2dnUVZ_uGdnZ2d@supernews.com> |
| In reply to | #7906 |
BruceMcF <agila61@netscape.net> wrote: > On Dec 10, 12:49?pm, Andrew Haley <andre...@littlepinkcloud.invalid> > wrote: >> >> It says "may provide definitions, including definitions of words in >> the Core word set, in source form only." I think the implication is >> that it's machine-readable source, not a listing. On desktop systems >> (not an 8051, admittedly) compilation of the source might be so fast >> that a user wouldn't even notice it happening when the system was >> started. > > It would typically be a machine readable listing OCR, you mean? :-) > rather than a printed one, but the standard is awfully vague. But > its more a rhetorical point than a pragmatic one, as it'd be highly > unlikely to have a printed listing would be distributed without a > machine readable file of the listing, and even for systems with just > a bidirectional serial port as the console, its highly unlikely to > be just a dumb terminal at the other end. Sure, but even as a rehetorical point it's failed on me. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-12-10 11:28 -0800 |
| Subject | Re: return address manipulation |
| Message-ID | <0e7ee7e4-a96b-412c-8fc5-a365cbb95482@a17g2000yqj.googlegroups.com> |
| In reply to | #7909 |
On Dec 10, 1:37 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: >> It would typically be a machine readable listing > OCR, you mean? :-) Last listing I typed in, the listing was in one window on the computer and the emulator of the target was in another. Since the listing was in a file downloaded from the net, the only way I could have had a paper copy would be printing it out myself. > Sure, but even as a rhetorical point it's failed on me. As I said, I think the original point lies along a red herring branch in any event ~ as long as the return address manipulation is to be done at runtime, then the microcontroller still needs to be able to do it, even if programmed with an umbilical system and there is no complete CORE system on the micro-controller itself. So the issue of having a distinct >RR RR> operation for portable return stack manipulation (as proposed elsewhere) does not go away just because its an umbilical system.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-09 08:39 -1000 |
| Subject | Re: return address manipulation |
| Message-ID | <kPmdnQdg2PVByH_TnZ2dnUVZ_vCdnZ2d@supernews.com> |
| In reply to | #7859 |
On 12/9/11 6:35 AM, Anton Ertl wrote: > stephenXXX@mpeforth.com (Stephen Pelc) writes: >> On Thu, 08 Dec 2011 15:51:53 GMT, anton@mips.complang.tuwien.ac.at >> (Anton Ertl) wrote: >> >>> Please elaborate! Do you know of any standard systems on CPUs where >>> the return addresses cannot be accessed as data? Or at least of CPUs >>> large enough for standard systems that have such a restriction? >> >> In all ARM systems using the Thumb instruction set, bit 0 is set in >> the value on the return stack, even though this actually refers to >> an even address. > > As long as the only thing we do with a return address is to remove it > from the return stack and possibly push it back on later and jump to > it by performing an actual return, the actual format of a return > "address" is irrelevant. That usage scheme covers most of the uses > that Bernd Paysan and Michael Gassanenko are doing, and anything > beyond (like accessing and skipping literal data) is even less > portable anyway (even outside ARM-based systems). If actual return addresses are not kept on the Forth return stack (e.g. on those 8051s), R> etc. won't access them. > In any case, on the ARM the return addresses may have a funny format, > but they are accessible as data. > >> There are several CPUs, e.g. PIC24/30 in which the return address >> is not necessarily the same size as a data cell. > > Are there fully compliant standard systems for these processors? And > are the return addresses larger than a data cell? If not, that's not > a problem. > >> There are 8051 systems in which the return address is not saved on >> a Forth stack. > > Yes, Andrew mentioned that. Still, my feeling is that a system > implementor will rather leave more memory to the programmer than to > provide all of the core words (hmm, ok, they could provide many of the > words as a listing to type in, then they would not consume memory > unless typed in). Does MPE have a fully compliant standard system for > the 8051? I'd rather expect an umbilical system. FORTH, Inc.'s systems for the 8051 (and other MCUs) are compliant with the proposed cross-compiler standard. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-10 12:34 +0000 |
| Subject | Re: return address manipulation |
| Message-ID | <2011Dec10.133435@mips.complang.tuwien.ac.at> |
| In reply to | #7862 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 12/9/11 6:35 AM, Anton Ertl wrote:
>> Does MPE have a fully compliant standard system for
>> the 8051? I'd rather expect an umbilical system.
>
>FORTH, Inc.'s systems for the 8051 (and other MCUs) are compliant with
>the proposed cross-compiler standard.
Thank you for supporting my point.
- 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 | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-12-10 06:39 -0800 |
| Subject | Re: return address manipulation |
| Message-ID | <a1ecf364-f7c6-49dc-b43f-15b74160eb64@l29g2000yqf.googlegroups.com> |
| In reply to | #7884 |
On Dec 10, 7:34 am, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > "Elizabeth D. Rather" <erat...@forth.com> writes: > > >On 12/9/11 6:35 AM, Anton Ertl wrote: > >> Does MPE have a fully compliant standard system for > >> the 8051? I'd rather expect an umbilical system. > > >FORTH, Inc.'s systems for the 8051 (and other MCUs) are compliant with > >the proposed cross-compiler standard. > > Thank you for supporting my point. But if the return stack manipulation occurs at runtime, it doesn't make any difference that the system is an umbilical system ~ the microcontroller still has to be able to support the return stack manipulation.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-11 11:30 +0000 |
| Subject | Re: return address manipulation |
| Message-ID | <2011Dec11.123037@mips.complang.tuwien.ac.at> |
| In reply to | #7890 |
BruceMcF <agila61@netscape.net> writes:
>On Dec 10, 7:34=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> "Elizabeth D. Rather" <erat...@forth.com> writes:
>>
>> >On 12/9/11 6:35 AM, Anton Ertl wrote:
>> >> Does MPE have a fully compliant standard system for
>> >> the 8051? =A0I'd rather expect an umbilical system.
>>
>> >FORTH, Inc.'s systems for the 8051 (and other MCUs) are compliant with
>> >the proposed cross-compiler standard.
>>
>> Thank you for supporting my point.
>
>But if the return stack manipulation occurs at runtime, it doesn't
>make any difference that the system is an umbilical system ~ the
>microcontroller still has to be able to support the return stack
>manipulation.
Sure, but my claim was:
|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.
I have yet to see a counterexample for this claim.
- 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 | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2011-12-06 17:18 +0000 |
| Message-ID | <4ede46bf.79625297@192.168.0.50> |
| In reply to | #7752 |
On Tue, 6 Dec 2011 12:36:50 +0000 (UTC), Arnold Doray <thinksquared@gmail.com> wrote: >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? There are two cases : aa ... recurse ; CALL AA becomes JMP AA : aa ... bbb ; CALL BB becomes JMP BB On the first entry to AA the return stack contains the address just after the AA. On the second entry to AA the return stack contains the address just after the first call to AA. If AA itself performs some (non-standard but classic) return stack manipulations, these will fail in the second case. When you see a word with an active return stack, it can be difficult to predict the number of levels over which the return stack is active. Every time that I have attempted to codify rules for this, I have been defeated by the ingenuity of Forth programmers. >Can't the phrase "RECURSE ;" be replaced by just a JMP as you have done >in the BEGIN -- AGAIN construct? Yes, it can. But for the reasons above, it requires a lot of analysis at compile time to do this safely. I could do this safely for most usage, but Bernd or Michael could probably ruin my construct embarrassingly quickly. Until someone provides a numerical example of why tail call elimination is a really good optimisation, VFX will remain conservative for return stack optimisations. Being an unquantified "neat hack" isn't convincing. Stephen P.S. The primary duty of an exception handler is to get the error out of the lap of the programmer and into the surprised face of the user. Provided you keep this cardinal rule in mind, you can't go far wrong. (Verity Stob) -- 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]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web