Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33379 > unrolled thread
| Started by | Walter Banks <walter@bytecraft.com> |
|---|---|
| First post | 2014-09-16 11:22 -0400 |
| Last post | 2014-09-19 02:53 -0700 |
| Articles | 20 on this page of 230 — 25 participants |
Back to article view | Back to comp.lang.forth
Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 11:22 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 11:41 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:20 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 13:39 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:11 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 17:24 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:58 -0400
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 08:47 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 14:41 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-16 18:55 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 14:33 -1000
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 18:30 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-16 15:44 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:22 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 09:18 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:39 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:41 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 16:11 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 16:34 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-17 17:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 07:21 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 10:01 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 07:42 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 14:46 +0000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 08:09 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 03:41 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:31 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 14:53 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 16:44 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 15:52 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-30 00:08 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 04:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:48 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 12:26 -0500
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 17:07 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-17 07:20 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:03 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:40 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 09:56 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:54 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 15:13 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 13:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 11:13 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 21:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 16:57 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-23 00:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 19:53 -1000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 03:48 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-23 16:01 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 08:07 -1000
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-09-23 22:11 +0100
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 16:22 -0500
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 11:28 -1000
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-24 11:56 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:52 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:00 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:04 -0400
Re: Metrics on stack usage Michael Barry <barrym95838@yahoo.com> - 2014-09-24 16:08 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 12:23 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 19:33 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:02 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-25 18:48 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 16:58 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-24 16:02 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 19:14 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 10:15 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 13:54 -1000
Typing, was [Re: Metrics on stack usage] "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-24 21:07 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 15:25 -1000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-24 18:43 -0700
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 16:08 -1000
Re: Typing, was [Re: Metrics on stack usage] Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:11 -0700
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-10-01 09:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:38 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-29 17:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-30 09:13 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-30 22:37 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-03 16:10 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 08:42 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 14:59 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 09:07 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 17:28 -0400
Re: Typing, was [Re: Metrics on stack usage] Howerd <howerdo@yahoo.co.uk> - 2014-10-04 11:15 -0700
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-07 23:37 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-07 15:07 -1000
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-12 03:03 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-12 10:42 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-13 00:26 +0200
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-11 19:30 -1000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-08 03:42 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 02:46 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 00:43 +0200
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 18:45 +0000
Re: Typing, was [Re: Metrics on stack usage] "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-25 09:22 +0200
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 17:09 +0000
Re: Metrics on stack usage Kaz Kylheku <kaz@kylheku.com> - 2014-09-25 01:43 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:15 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:19 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:06 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 04:25 -0400
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 03:15 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 14:43 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 22:23 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:42 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 14:23 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 10:14 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 17:10 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 12:31 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 21:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 01:34 +0200
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-05 03:29 -0500
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-05 13:46 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-05 15:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 03:44 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 00:12 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-05 18:56 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 01:34 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 19:57 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-07 04:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 16:21 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 05:43 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 02:35 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 21:48 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 05:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 01:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 21:27 +0200
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 00:01 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 19:59 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 03:33 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:30 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-11 15:22 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-11 22:24 -0400
Loading libraries (was: Metrics on stack usage) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-11 09:23 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:11 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:36 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:38 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 23:39 -0400
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-11 12:25 +0100
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 07:52 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 00:34 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-01 23:26 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-01 16:15 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-01 21:57 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 01:20 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-02 15:59 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 19:29 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-03 15:03 +0000
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 02:27 +0200
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-05 09:22 +0100
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-23 19:36 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:40 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-16 17:06 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 07:43 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:04 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:34 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:30 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-17 12:42 -1000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:33 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-18 11:53 -1000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-19 01:14 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 03:32 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:41 +0000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 12:14 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:41 +0000
Re: Metrics on stack usage mhx@iae.nl - 2014-09-19 12:31 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 12:59 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:05 +0000
Re: Metrics on stack usage Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-09-21 07:44 +0200
Re: Metrics on stack usage Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-09-17 11:10 +0200
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-17 14:20 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:41 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-17 16:44 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-18 10:26 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-19 00:12 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-18 19:15 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-18 17:14 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:59 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-19 12:20 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-20 09:04 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 18:08 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-30 04:33 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 19:30 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-30 11:24 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-30 10:55 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-30 18:39 -0700
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-10-01 01:44 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-01 03:57 -0500
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 18:45 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-02 07:53 -0400
Re: Metrics on stack usage G Smith <do.not.use@tectimco.com> - 2014-10-02 13:22 +0100
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-02 08:36 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-02 15:34 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:08 +0000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 18:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-19 13:28 -1000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 19:57 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 13:09 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-20 13:27 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 08:04 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 08:55 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:01 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:15 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 06:57 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 07:31 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:04 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:17 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:49 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:57 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 19:47 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 02:58 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:28 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-21 11:24 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:55 -0400
Re: Metrics on stack usage Coos Haak <chforth@hccnet.nl> - 2014-09-20 14:57 +0200
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:22 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:25 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:08 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:38 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:19 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:35 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:00 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 08:54 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 03:26 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 10:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:29 -0400
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:53 -0700
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
| From | stephen@mpeforth.com |
|---|---|
| Date | 2014-09-20 09:04 -0700 |
| Message-ID | <58ae9a42-3926-40dd-beda-61cec74bab02@googlegroups.com> |
| In reply to | #33443 |
On Friday, 19 September 2014 20:20:42 UTC+1, hughag...@yahoo.com wrote:
> If you are going to make sarcastic statements about my programming ability
> ("world-class super-hero programmers"), then how likely is it that I will want
> to become a loyal customer of MPE?
1) If you can't take it, don't dish it out.
2) Whatever makes you think that MPE wants you as a customer?
Stephen
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-29 18:08 -0700 |
| Message-ID | <f624154f-cc4d-4521-9271-2533dcb1f283@googlegroups.com> |
| In reply to | #33463 |
On Saturday, September 20, 2014 9:04:51 AM UTC-7, ste...@mpeforth.com wrote:
> On Friday, 19 September 2014 20:20:42 UTC+1, hughag...@yahoo.com wrote:
> > If you are going to make sarcastic statements about my programming ability
> > ("world-class super-hero programmers"), then how likely is it that I will want
> > to become a loyal customer of MPE?
>
> 1) If you can't take it, don't dish it out.
> 2) Whatever makes you think that MPE wants you as a customer?
I suppose that you would want me to be a loyal customer because I would send you money.
I am now writing a cross-compiler in ANS-Forth. Just yesterday I discovered another problem with ANS-Forth that I hadn't noticed before: SMUDGE is missing! WTF??? What possible reason could there be to remove SMUDGE from the standard, except to pull the rug out from under cross-compiler writers?
So, being the world-class super-hero programmer that I am, I read the VFX manual. VFX has SMUDGE. So, obviously you understand that SMUDGE is useful, otherwise you wouldn't have included it in VFX. But, when you were on the ANS-Forth committee in 1994, you agreed to have SMUDGE removed. Apparently you don't want ANS-Forth programmers to have functionality that you consider necessary for VFX customers --- that really speaks volumes about how much you care for ANS-Forth programmers! You want everybody in the Forth community to believe that the definition of a "world-class super-hero programmer" is: "Any programmer who reads the VFX manual" --- effectively, you want everybody to be a super-hero and send you money.
Here is the only thread I found on C.L.F. discussing SMUDGE:
https://groups.google.com/forum/#!searchin/comp.lang.forth/smudge/comp.lang.forth/olO-VHXJa1Q/IeWA6qeP_K0J
I think that when you were on the ANS-Forth committee, your goal was to sabotage the standard so that people would be compelled to abandon ANS-Forth and use VFX instead --- become your loyal customers and send you money --- this is why you removed useful features from ANS-Forth but provided them in VFX.
In that thread mentioned above, I found this quote:
On Monday, July 5, 1993 11:21:00 AM UTC-7, Ray Duncan wrote:
> As for Forth-83 and dpANS -- Forth-83 was singularly vague on
> the subject of vocabulary implementation, and (the last time
> I looked) so is dpANS. In the Forth-83 standard there is nothing
> that says the use of system variables named CONTEXT and CURRENT
> makes the system nonstandard. Nor is there anything that says
> the compilation vocabulary CAN'T be part of the search order.
>
> Perhaps you are confusing the infamous Ragsdale ALSO/ONLY
> experimental vocabulary proposal with the Forth-83 standard.
> It's true it was included in the Forth-83 Standard document,
> but it is not part of the standard and is not required.
> We considered, and still consider, the ALSO/ONLY scheme to
> be severely brain-damaged and we have never used it, although
> it is straightforward to layer an ALSO/ONLY compatibility layer
> on top of any of our systems.
I had not previously paid any attention to word-lists in ANS-Forth. Now, writing this cross-compiler, I was obliged to read up on them. When I read the entry on ALSO (16.6.2.0715) I saw this:
"Transform the search order consisting of widn, ... wid2, wid1 (where wid1 is searched first) into widn, ... wid2, wid1, wid1." I said to myself: "WTF? Why would I want wid1 searched twice?" Then after some more reading, I discovered the definition for FORTH (16.6.2.1590):
"Transform the search order consisting of widn, ... wid2, wid1 (where wid1 is searched first) into widn, ... wid2, widFORTH-WORDLIST."
So, apparently the idea is to use FORTH after ALSO to fix the top value of the search-order. ALSO makes no sense except in the context of being followed by a word such as FORTH that fixes the problem that it creates. But there is no word provided to allow the user to do this with his own word-lists. The user has to write code for this himself. I wrote the following, that will go into the next novice package upgrade:
: <set-context> { wid anchor -- widN... N }
get-order dup 1 < abort" *** SET-CONTEXT given empty search-order ***"
over anchor = if
wid anchor = if exit then
wid swap 1+ exit then
nip wid swap ;
\ WID will replace whatever was on top, unless ANCHOR was on top
\ in which case WID will be pushed above it
: set-context ( wid -- )
forth-wordlist <set-context> set-order ;
\ like in Forth-83, the WID becomes the context
\ with FORTH-WORDLIST as the anchor below it
\ FORTH-WORDLIST SET-CONTEXT would do the same thing that FORTH does.
: <push-context> { wid -- }
get-order
over wid = if exit then
wid swap 1+ ;
\ the WID becomes the context, with whatever was below it remaining
: push-context ( wid -- )
<push-context> set-order ;
\ I don't recommend using ALSO with <SET-CONTEXT> because problems will
\ result if the anchor is the top wid. Use PUSH-CONTEXT instead.
\ All in all, ALSO is a screw-ball idea, as it involves making a duplicate
\ in the search-order, which makes no sense.
Why should the user have to write code like this to achieve what Forth-83 already had? Could this be one reason why people didn't move from Forth-83 to ANS-Forth, but instead just abandoned Forth altogether? Do you think?
In 1993, Ray Duncan described ALSO/ONLY as "severely brain-damaged." This was a year prior to ANS-Forth being written in stone. Then, 20 years after ANS-Forth became standard, I wrote a work-around for the problem in my novice package and described ALSO/ONLY as a "screw-ball idea" --- I hadn't read Ray Duncan's comment at the time that I wrote my comment, otherwise I would have described it as "severely brain-damaged" for consistency. Why did you put this in the ANS-Forth standard? What were you thinking?
The ANS-Forth committee wasn't doing any thinking at all --- the whole ANS-Forth standard is a collision of ignorance and arrogance!
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-09-30 04:33 -0400 |
| Message-ID | <op.xmzrdzr0mk81un@localhost> |
| In reply to | #33590 |
On Mon, 29 Sep 2014 21:08:39 -0400, <hughaguilar96@yahoo.com> wrote:
> I am now writing a cross-compiler in ANS-Forth. Just yesterday I
> discovered another problem with ANS-Forth that I hadn't noticed before:
> SMUDGE is missing! WTF??? What possible reason could there be to remove
> SMUDGE from the standard, except to pull the rug out from under
> cross-compiler writers?
What standard was SMUDGE _removed_ from? ...
SMUDGE seems to only be documented as part of fig-Forth,
i.e., it's not part of any standard, apparently.
> Here is the only thread I found on C.L.F. discussing SMUDGE:
> [link]
Search for "SMUDGE" in the message body not the topic and
you'll find some more threads discussing SMUDGE. E.g., I've
mentioned SMUDGE over a half-dozen times according to Google
Group's index of Usenet. Most were just casual mentions, but
two were more in-depth.
> : <set-context> { wid anchor -- widN... N }
> get-order dup 1 < abort" *** SET-CONTEXT given empty search-order
> ***"
> over anchor = if
> wid anchor = if exit then
> wid swap 1+ exit then
> nip wid swap ;
> \ WID will replace whatever was on top, unless ANCHOR was on top
> \ in which case WID will be pushed above it
>
> : set-context ( wid -- )
> forth-wordlist <set-context> set-order ;
> \ like in Forth-83, the WID becomes the context
> \ with FORTH-WORDLIST as the anchor below it
> \ FORTH-WORDLIST SET-CONTEXT would do the same thing that FORTH does.
>
> : <push-context> { wid -- }
> get-order
> over wid = if exit then
> wid swap 1+ ;
> \ the WID becomes the context, with whatever was below it remaining
> : push-context ( wid -- )
> <push-context> set-order ;
> \ I don't recommend using ALSO with <SET-CONTEXT> because problems will
> \ result if the anchor is the top wid. Use PUSH-CONTEXT instead.
> \ All in all, ALSO is a screw-ball idea, as it involves making a
> duplicate
> \ in the search-order, which makes no sense.
1) Many people are still ignoring or filtering you.
They're not seeing anything you post or are flat out
ignoring it, even if it is of merit.
2) No one is going to locate this topic here.
You should start new threads on this stuff, Hugh.
Maybe, try an alias. Of course, if people know
it's still you, perhaps still ranting on Ms. Rather,
they'll block or ignore the alias too. E.g., they
know when "gavino" changes aliases by his writing
style.
> In 1993, Ray Duncan described ALSO/ONLY as "severely brain-damaged."
He used Forth? Aw, I like that guy. Now, I think less of him ...
Thanks a lot, Hugh! I'm just joking. Although, it's amazing he
didn't make that claim of other utterly insane Forth issues.
> Why did [Ms. Rather] put this in the ANS-Forth standard?
> What were you thinking?
Well, almost no one puts code here. They might as well have put something
in the standard. You can't charge for 500 pages if you've only got 5
pages.
Personally, I think that **I** have posted more code than you,
Ms. Rather, Bernd, Alex, Anton, Paul, Rick, and a bunch of other
current regulars combined since I started reading here circa 2007.
Andrew, Albert, Mark, and a few others still post some.
> The ANS-Forth committee wasn't doing any thinking at all --- the whole
> ANS-Forth standard is a collision of ignorance and arrogance!
Did you really expect any committee to _not_ be somewhat misguided?
... camel ... horse ... by committee ...
... too many ... cooks ... spoil ... broth ...
etc. cliches.
Decisions made by any group of sufficient size is going to be dumbed
down to the level of the least intelligent member. This is why
allowing everyone the right to vote is so risky and still radical even
today. There are too many dumb people in the world. Unfortunately, it
costs the smart people much money and time to improve the food, education,
health and sanitation of ordinary citizens to the point that they stop
wrecking the place, i.e., the world.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-01 19:30 -0700 |
| Message-ID | <89086b26-f6eb-4cde-b817-f1da66011d00@googlegroups.com> |
| In reply to | #33593 |
On Tuesday, September 30, 2014 1:29:39 AM UTC-7, Rod Pemberton wrote: > You should start new threads on this stuff, Hugh. > Maybe, try an alias. Of course, if people know > it's still you, perhaps still ranting on Ms. Rather, > they'll block or ignore the alias too. E.g., they > know when "gavino" changes aliases by his writing > style. If I change my name, that is effectively the same as abandoning all of the Forth code that I have ever written, including MFX and the novice package. I don't have to actually change my name to do that though --- I could just announce that all of my past Forth was crap, and promise not to write Forth code ever again. If I did this, Elizabeth Rather would welcome me back into comp.lang.forth again, and proclaim me to be a great Forth expert --- afaik, all that she has ever wanted from me is that I stop writing Forth code --- this is all that she wants from everybody, as her goal is for Forth Inc. to have a monopoly on the writing of Forth code. And, if I not only stopped writing Forth code but also turned gay, she would proclaim me to be fully equal to Passaniti, who had previously been the king of comp.lang.forth, up until the day that he stopped showing up here (and nobody knows why he abdicated the throne). I could be the new king of comp.lang.forth! Why don't I do it? Is it because I don't care enough about comp.lang.forth to bother taking the throne? If I don't care about comp.lang.forth, why do I bother posting code here? What is the point of visiting comp.lang.forth and not being the king?
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-09-30 11:24 +0000 |
| Message-ID | <542a92ff$0$15825$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #33590 |
In article <f624154f-cc4d-4521-9271-2533dcb1f283@googlegroups.com>,
<hughaguilar96@yahoo.com> wrote:
>On Saturday, September 20, 2014 9:04:51 AM UTC-7, ste...@mpeforth.com wrote:
>> On Friday, 19 September 2014 20:20:42 UTC+1, hughag...@yahoo.com wrote:
>> > If you are going to make sarcastic statements about my programming ability
>> > ("world-class super-hero programmers"), then how likely is it that I
>will want
>> > to become a loyal customer of MPE?
>>
>> 1) If you can't take it, don't dish it out.
>> 2) Whatever makes you think that MPE wants you as a customer?
>
>I suppose that you would want me to be a loyal customer because I would
>send you money.
>
>I am now writing a cross-compiler in ANS-Forth. Just yesterday I
>discovered another problem with ANS-Forth that I hadn't noticed before:
>SMUDGE is missing! WTF??? What possible reason could there be to remove
>SMUDGE from the standard, except to pull the rug out from under
>cross-compiler writers?
>
>So, being the world-class super-hero programmer that I am, I read the
>VFX manual. VFX has SMUDGE. So, obviously you understand that SMUDGE is
>useful, otherwise you wouldn't have included it in VFX. But, when you
>were on the ANS-Forth committee in 1994, you agreed to have SMUDGE
>removed. Apparently you don't want ANS-Forth programmers to have
>functionality that you consider necessary for VFX customers --- that
>really speaks volumes about how much you care for ANS-Forth programmers!
>You want everybody in the Forth community to believe that the definition
>of a "world-class super-hero programmer" is: "Any programmer who reads
>the VFX manual" --- effectively, you want everybody to be a super-hero
>and send you money.
>
>Here is the only thread I found on C.L.F. discussing SMUDGE:
>https://groups.google.com/forum/#!searchin/comp.lang.forth/smudge/comp.lang.forth/olO-VHXJa1Q/IeWA6qeP_K0J
Indeed the functionality of SMUDGE is indispensable.
In lina the word HIDDEN replaces the strange word SMUDGE. It has the same
property ; one can unhide by using HIDDEN twice on the same dea.
I don't feel bad when I hide dictionary entries to reduce confusion
or prevent their accidental use. I would feel worried if I SMUDGEd
them, or I would expect a casual reader to be feel worried.
>
>I think that when you were on the ANS-Forth committee, your goal was to
>sabotage the standard so that people would be compelled to abandon
>ANS-Forth and use VFX instead --- become your loyal customers and send
>you money --- this is why you removed useful features from ANS-Forth but
>provided them in VFX.
>
>In that thread mentioned above, I found this quote:
>On Monday, July 5, 1993 11:21:00 AM UTC-7, Ray Duncan wrote:
>> As for Forth-83 and dpANS -- Forth-83 was singularly vague on
>> the subject of vocabulary implementation, and (the last time
>> I looked) so is dpANS. In the Forth-83 standard there is nothing
>> that says the use of system variables named CONTEXT and CURRENT
>> makes the system nonstandard. Nor is there anything that says
>> the compilation vocabulary CAN'T be part of the search order.
>>
>> Perhaps you are confusing the infamous Ragsdale ALSO/ONLY
>> experimental vocabulary proposal with the Forth-83 standard.
>> It's true it was included in the Forth-83 Standard document,
>> but it is not part of the standard and is not required.
>> We considered, and still consider, the ALSO/ONLY scheme to
>> be severely brain-damaged and we have never used it, although
>> it is straightforward to layer an ALSO/ONLY compatibility layer
>> on top of any of our systems.
>
>I had not previously paid any attention to word-lists in ANS-Forth. Now,
>writing this cross-compiler, I was obliged to read up on them. When I
>read the entry on ALSO (16.6.2.0715) I saw this:
>"Transform the search order consisting of widn, ... wid2, wid1 (where
>wid1 is searched first) into widn, ... wid2, wid1, wid1." I said to
>myself: "WTF? Why would I want wid1 searched twice?" Then after some
>more reading, I discovered the definition for FORTH (16.6.2.1590):
>"Transform the search order consisting of widn, ... wid2, wid1 (where
>wid1 is searched first) into widn, ... wid2, widFORTH-WORDLIST."
>So, apparently the idea is to use FORTH after ALSO to fix the top value
>of the search-order. ALSO makes no sense except in the context of being
>followed by a word such as FORTH that fixes the problem that it creates.
>But there is no word provided to allow the user to do this with his own
>word-lists. The user has to write code for this himself. I wrote the
>following, that will go into the next novice package upgrade:
>
>: <set-context> { wid anchor -- widN... N }
> get-order dup 1 < abort" *** SET-CONTEXT given empty search-order ***"
> over anchor = if
> wid anchor = if exit then
> wid swap 1+ exit then
> nip wid swap ;
>\ WID will replace whatever was on top, unless ANCHOR was on top
>\ in which case WID will be pushed above it
>
>: set-context ( wid -- )
> forth-wordlist <set-context> set-order ;
>\ like in Forth-83, the WID becomes the context
>\ with FORTH-WORDLIST as the anchor below it
>
>\ FORTH-WORDLIST SET-CONTEXT would do the same thing that FORTH does.
>
>: <push-context> { wid -- }
> get-order
> over wid = if exit then
> wid swap 1+ ;
>\ the WID becomes the context, with whatever was below it remaining
>
>: push-context ( wid -- )
> <push-context> set-order ;
>
>\ I don't recommend using ALSO with <SET-CONTEXT> because problems will
>\ result if the anchor is the top wid. Use PUSH-CONTEXT instead.
>\ All in all, ALSO is a screw-ball idea, as it involves making a duplicate
>\ in the search-order, which makes no sense.
>
>Why should the user have to write code like this to achieve what
>Forth-83 already had? Could this be one reason why people didn't move
>from Forth-83 to ANS-Forth, but instead just abandoned Forth altogether?
>Do you think?
>
>In 1993, Ray Duncan described ALSO/ONLY as "severely brain-damaged."
>This was a year prior to ANS-Forth being written in stone. Then, 20
>years after ANS-Forth became standard, I wrote a work-around for the
>problem in my novice package and described ALSO/ONLY as a "screw-ball
>idea" --- I hadn't read Ray Duncan's comment at the time that I wrote my
>comment, otherwise I would have described it as "severely brain-damaged"
>for consistency. Why did you put this in the ANS-Forth standard? What
>were you thinking?
>
>The ANS-Forth committee wasn't doing any thinking at all --- the whole
>ANS-Forth standard is a collision of ignorance and arrogance!
This is one of the few places where ciforth deviates from ISO.
From the manual of lina:
"
FORTH:
The name of the primary namespace. Execution pushes the FORTH WID to
the top of the search order . (For ISO-compliance it would replace the
top.) ...
"
What one really wants is get things under control, whatever the situation.
That is why ISO demands that SET-ORDER is available after ONLY (minimum search
order).
(In ciforth SET-ORDER is a loadable extension, which creates a weird situation
to say the least. SET-ORDER would be useful only after creating a new system.)
Howver, in practice everybody uses:
ONLY FORTH DEFINITIONS
This works on ciforth. Unless one takes extreme measure to shoot oneself.
E.g.
' ONLY HIDDEN
or
' FORTH HIDDEN
or
'NOOP ALIAS ONLY
would do that.
So once again implementors converge on idea's. You really should
have a look at yourforth, by the way.
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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-09-30 10:55 -0700 |
| Message-ID | <12de3404-bee5-4e2e-b6bf-e126c6de2c71@googlegroups.com> |
| In reply to | #33595 |
http://turboforth.net/applications.htm The above is my take on vocabulary handling/search orders which I much prefer. I was shocked at how much code it didn't require to implement something so cool.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-30 18:39 -0700 |
| Message-ID | <725ef6af-1e6a-43bc-a090-596b2a3b4026@googlegroups.com> |
| In reply to | #33597 |
On Tuesday, September 30, 2014 10:55:27 AM UTC-7, Mark Wills wrote: > http://turboforth.net/applications.htm > > The above is my take on vocabulary handling/search orders which I much prefer. I was shocked at how much code it didn't require to implement something so cool. Your code appears to be very similar to what I had in MFX (MODULE and END-MODULE were like your APPLICATION: and END-APPLICATION). I discussed this on comp.lang.forth --- is that where you got the idea? --- or is this just convergent evolution? What you are describing is useful for reducing name-space pollution (getting a lot of words in the dictionary, most of which were only used in one small section of code, and aren't useful in the larger context). This is a good idea; it gets rid of a lot of spurious redefinition warning messages that tend to confuse the user. Also, it helps the user learn the software --- he only has to learn the globally available words, because they are obviously important, but he can ignore everything else. What you are describing is not useful for writing a cross-compiler however. For that, I need word-lists (Forth-83 vocabularies were adequate in MFX).
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-10-01 01:44 -0700 |
| Message-ID | <d2bdb0b2-b137-4fcd-b74f-2def5efa7f5b@googlegroups.com> |
| In reply to | #33599 |
On Wednesday, 1 October 2014 02:39:04 UTC+1, hughag...@yahoo.com wrote:
> Your code appears to be very similar to what I had in MFX (MODULE and END-MODULE were like your APPLICATION: and END-APPLICATION). I discussed this on comp.lang.forth --- is that where you got the idea? --- or is this just convergent evolution?
Thanks for taking a look. I guess you could call it convergent
evolution! Although I think it's a rather obvious idea and I'm
sure it's been done many times over the years. There's probably
a few articles in Forth Dimensions along similar lines. In fact
VFX has similar concept, which is very nice: It has MODULE
END-MODULE and EXPORT (IIRC), so I probably owe Mr. Pelc a beer.
I just took it a little bit further, in the sense the name of
the application can be linked to a word in the application, such
that naming the application in other code elsewhere causes the
application to run. This is done with ENTRY-POINT.
I'm thinking of expanding it one level inwards, to incorporate
modules within applications:
APPLICATION: pressure_monitor
variable ...
variable ...
MODULE: setup
variable ...
: do_setup ... ;
END-MODULE
MODULE: RS232
variable ...
: ... ... ... ;
END-MODULE
END-APPLICATION
To me, this is perfect, and all this rather ugly vocabulary
stuff just vanishes. I've never liked the vocabularies in Forth.
It's very Forthy (simple, and clever) actually rather cool, but
I've never been a fan of how it actually works from a *user*
point-of-view. I imagine a newcomer to Forth, seeing something
like the above example would be comfortable with it immediately.
It'd need no practical explanation whatsoever.
>
> What you are describing is useful for reducing name-space pollution (getting a lot of words in the dictionary, most of which were only used in one small section of code, and aren't useful in the larger context).
Exactly. That's exactly why I wrote it. On my system there's no
vocabulary, or, only one vocabulary if you like (a single linked
list). So, you type WORDS and get hundreds of words listed, but
you really have to know what they are. I mean, variables,
constants, colon-definitions, CODE words etc. are all in there.
With APPLICATION: they're all hidden, and only the application's
interfaces (the useful words that do *stuff*) are listed.
Everything else is hidden. It's just neater. It also speeds up
(in my case) dictionary searches (which are lightning fast, being
implemented in assembler) because once an application is sealed
the private words are not seen by FIND. They've been linked out.
>Also, it helps the user learn the software --- he only has to learn the globally available words, because they are obviously important, but he can ignore everything else.
Totally. As mentioned above, that's kind of where I'm coming from
- not particularly Forthy, but very easy to understand.
> What you are describing is not useful for writing a cross-compiler however. For that, I need word-lists (Forth-83 vocabularies were adequate in MFX).
Okay. I really have no insight as to how Forth cross-compilers work.
From what i've read it's voodoo!
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-01 03:57 -0500 |
| Message-ID | <9tKdnSUccZd5XLbJnZ2dnUU7-cmdnZ2d@supernews.com> |
| In reply to | #33602 |
Mark Wills <markwills1970@gmail.com> wrote: > > I'm thinking of expanding it one level inwards, to incorporate > modules within applications: > > APPLICATION: pressure_monitor > variable ... > variable ... > > MODULE: setup > variable ... > : do_setup ... ; > END-MODULE > > MODULE: RS232 > variable ... > : ... ... ... ; > END-MODULE > END-APPLICATION > > To me, this is perfect, and all this rather ugly vocabulary > stuff just vanishes. I've never liked the vocabularies in Forth. > It's very Forthy (simple, and clever) actually rather cool, but > I've never been a fan of how it actually works from a *user* > point-of-view. I imagine a newcomer to Forth, seeing something > like the above example would be comfortable with it immediately. Perhaps, but having to remember which namespace contained which word would make for a pretty miserable interactive programming experience. That's always been the problem with using vocabularies in this way, IME. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-01 18:45 -0700 |
| Message-ID | <f50406b6-7664-4940-bae5-c2b468742cef@googlegroups.com> |
| In reply to | #33602 |
On Wednesday, October 1, 2014 1:44:06 AM UTC-7, Mark Wills wrote: > On Wednesday, 1 October 2014 02:39:04 UTC+1, hughag...@yahoo.com wrote: > > Your code appears to be very similar to what I had in MFX (MODULE and END-MODULE were like your APPLICATION: and END-APPLICATION). I discussed this on comp.lang.forth --- is that where you got the idea? --- or is this just convergent evolution? > > Thanks for taking a look. I guess you could call it convergent > evolution! Although I think it's a rather obvious idea and I'm > sure it's been done many times over the years. There's probably > a few articles in Forth Dimensions along similar lines. In fact > VFX has similar concept, which is very nice: It has MODULE > END-MODULE and EXPORT (IIRC), so I probably owe Mr. Pelc a beer. > I just took it a little bit further, in the sense the name of > the application can be linked to a word in the application, such > that naming the application in other code elsewhere causes the > application to run. This is done with ENTRY-POINT. You did take the idea further than I did, as you describe. > I'm thinking of expanding it one level inwards, to incorporate > modules within applications: > ... That would be a good idea, although I don't think any further expansion beyond that would be worthwhile. > To me, this is perfect, and all this rather ugly vocabulary > stuff just vanishes. I've never liked the vocabularies in Forth. Vocabularies are quite useful for implementing assemblers. You switch to the assembler vocabulary during inline assembly, and then back again for Forth. Assemblers often have words (AND, OR, XOR, etc.) that clash with Forth. In the old days of line-editors, you switched to the editor vocabulary while editing, and then back again to Forth. Editors had some words (I is the only one that I remember) that clashed with Forth. Nobody uses line-editors anymore though. I don't think your system would be adequate for an assembler --- vocabularies are the way to go --- that is what vocabularies were originally provided for. Honestly, I have never used vocabularies for anything except cross-compiling --- MFX was my first and only experience with vocabularies (except for using other people's assemblers). > > What you are describing is not useful for writing a cross-compiler however. For that, I need word-lists (Forth-83 vocabularies were adequate in MFX). > > Okay. I really have no insight as to how Forth cross-compilers work. > From what i've read it's voodoo! I've never read anything about cross-compilers --- I'm entirely self-taught on the subject. What have you read that makes them seem like voodoo? Jeff Fox once asked me if I had read the Forth-200x document on cross-compilers. When I said, "no," he advised me to not bother reading it as it grossly over-complicated the subject --- is that what you read? I almost never research any subject. The LLRB trees were an exception. I wasn't going to invent my own self-balancing tree algorithm, as the subject has already been done to death. MFX worked fine using Forth-83 vocabularies (CONTEXT and CURRENT). I am writing a cross-compiler now in ANS-Forth, and I am emulating Forth-83 vocabularies using that code I posted earlier in this thread. I would like to be able to write my cross-compiler in itself though, so I could dispense with ANS-Forth entirely. ANS-Forth is an over-complicated mess! To do this though, I would need to support a search-chain of word-lists --- the basic Forth-83 system does not support multiple levels like this. I sent you an email a while ago telling you that I was writing a cross-compiler for the ARM, and asking if you wanted to get involved, but got nothing back --- were you not interested? The ARM is used for the SCADA that you work in, isn't it? I don't know what SCADA is though, and (as you may have predicted) I don't want to take the time to research it --- I really just enjoy writing code, but research is boring!
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-10-02 07:53 -0400 |
| Message-ID | <op.xm3pyps9mk81un@localhost> |
| In reply to | #33616 |
On Wed, 01 Oct 2014 21:45:13 -0400, <hughaguilar96@yahoo.com> wrote: > On Wednesday, October 1, 2014 1:44:06 AM UTC-7, Mark Wills wrote: >> Okay. I really have no insight as to how Forth cross-compilers >> work. From what i've read it's voodoo! > > I've never read anything about cross-compilers --- I'm entirely > self-taught on the subject. It shouldn't be that hard ... All a cross-compiler does is emit code for a different platform. The code emitted as assembly or coded in assembly must be converted to assembly or executable binary for the new host. I.e., all the low-level Forth words and "primitives" which use assembly must be emitted in assembly or executable binary for the new host. I.e., the high-level Forth words will be emitted as assembly or executable binary for Forth's that compile, and emitted as compiled interpretable Forth for Forth's that interpret. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | G Smith <do.not.use@tectimco.com> |
|---|---|
| Date | 2014-10-02 13:22 +0100 |
| Message-ID | <zuWdnQlkXqQF3rDJnZ2dnUVZ8vqdnZ2d@bt.com> |
| In reply to | #33636 |
On 02/10/2014 12:53, Rod Pemberton wrote: > On Wed, 01 Oct 2014 21:45:13 -0400, <hughaguilar96@yahoo.com> wrote: >> On Wednesday, October 1, 2014 1:44:06 AM UTC-7, Mark Wills wrote: > >>> Okay. I really have no insight as to how Forth cross-compilers >>> work. From what i've read it's voodoo! >> >> I've never read anything about cross-compilers --- I'm entirely >> self-taught on the subject. > > It shouldn't be that hard ... > > All a cross-compiler does is emit code for a different platform. I'm reminded of Feynman's remark about quantum mechanics - and to mis-quote him: "If you think you understand cross-compilers you don't understand cross-compilers". > > The code emitted as assembly or coded in assembly must be converted > to assembly or executable binary for the new host. > > I.e., all the low-level Forth words and "primitives" which use > assembly must be emitted in assembly or executable binary for > the new host. > > I.e., the high-level Forth words will be emitted as assembly > or executable binary for Forth's that compile, and emitted > as compiled interpretable Forth for Forth's that interpret. > > > Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-02 08:36 -1000 |
| Message-ID | <xPCdnZoCLISHBrDJnZ2dnUU7-audnZ2d@supernews.com> |
| In reply to | #33636 |
On 10/2/14 1:53 AM, Rod Pemberton wrote: > On Wed, 01 Oct 2014 21:45:13 -0400, <hughaguilar96@yahoo.com> wrote: >> On Wednesday, October 1, 2014 1:44:06 AM UTC-7, Mark Wills wrote: > >>> Okay. I really have no insight as to how Forth cross-compilers >>> work. From what i've read it's voodoo! >> >> I've never read anything about cross-compilers --- I'm entirely >> self-taught on the subject. > > It shouldn't be that hard ... > > All a cross-compiler does is emit code for a different platform. Correct. > The code emitted as assembly or coded in assembly must be converted > to assembly or executable binary for the new host. > > I.e., all the low-level Forth words and "primitives" which use > assembly must be emitted in assembly or executable binary for > the new host. > > I.e., the high-level Forth words will be emitted as assembly > or executable binary for Forth's that compile, and emitted > as compiled interpretable Forth for Forth's that interpret. The forth cross-compilers I know generate executable binaries, with no intermediate steps. SwiftX cross-compilers are usually attached to the target and not only generate executable code but automatically download and launch it, whereupon the host provides an interactive debugging capability. You may find this overview helpful: http://www.forth.com/downloads/ANS/XCpaper.pdf 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-02 15:34 -0700 |
| Message-ID | <7452e4af-eb8b-42cf-ad60-717279e9c23d@googlegroups.com> |
| In reply to | #33590 |
On Monday, September 29, 2014 6:08:41 PM UTC-7, hughag...@yahoo.com wrote: > I wrote the following, that will go into the next novice package upgrade: This code is a bug-ridden mess. SET-CONTEXT doesn't work, and I don't know how to make it work. I'm retracting this code. If anybody cares to comment, go to this thread: https://groups.google.com/forum/#!topic/comp.lang.forth/olO-VHXJa1Q
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-19 12:08 +0000 |
| Message-ID | <2014Sep19.140810@mips.complang.tuwien.ac.at> |
| In reply to | #33425 |
Celeros <kerneels@gmail.com> writes:
>Interesting thread. Although not related to the link posted above, I
>seem to recall from Eric LaForest's thesis:
>
>http://www.eecg.toronto.edu/~laforest/Second-Generation_Stack_Computer_Architecture.pdf
>
>that research has been done into the stack depth / sizes required for
>even fairly deep recursive algorithmic problems such as the 8 queens
>problem, and that it has been shown that usually code can be written
>that would not require a deep stack at all - tens of items as aposed to
>hundreds or more.
A typical recursive implementation of 8-queens is not deeply
recursive, as there are at most 8 levels of recursion. A walk of a
degenerated tree would be a more realistic example.
Anyway, yes, for my work on stack caching
<https://www.complang.tuwien.ac.at/misc/stack-caching-data/> I
simulated a number of stack caches, and found that, out of the four
application programs I used, one used 30 stack items, and the others
used more than 32 (but probably not hundreds), but have a very low
stack cache miss rate with more than 16 items in the stack cache.
>I find it hard to believe and understand since intuitively it feels like
>if you have a hardware stack of say x cells that you can only have a max
>recursion depth of x or less than x?
>Maybe it was more that, with some hard stack depth of say x cells and
>the ability to have recursion to whatever level through use of memory,
>that statistically, even for aparently very recursive algorithms, an
>unusually shallow stack is *actually* needed most of the time.
Yes. Many recursive algorithms are of the divide-and-conquer sort,
and the expected recursion depth of these algorithms is logarithmic in
the problem size. If such a problem can degenerate, one sometimes
uses techniques for avoiding the recursion in that case. E.g., for
quicksort, you can recurse into the smaller partition, and use
tail-recursion (i.e., iteration) for the larger, thus ensuring that the recursion depth does not exceed ld(n).
>Can also remember reading that the RTX2000 had something like 256 deep
>stack, which was considered absolutely sufficient for it's space
>applications.
>So there is a nice upper limit, and they thought it sufficient enough to
>send it into space!
Certainly. Whatever the stack size, you won't use a possibly
badly-behaved recursive algorithm in such an application; you will
probably even be quite cautious about the well-behaved ones.
>I'm an extreme newbie here, but it sounds to me like stacks don't need
>to be very deep in order to do *most* things.
Right. 256 stack items seems to be significantly more than enough for
the kinds of code I expect is run there.
I don't expect it to run a parser generator, but anyway, I first ran
the parser generator Gray (recursive) on a C64, where the Forth system
had about 128 bytes of data stack and 256 bytes of return stack (with
2-byte cells). I was worried about stack overflows, so I took stuff
off the return and data stacks in the recursive calls and put it on a
separate, larger stack (and restored the data and return stack items
from there when returning from the recursive call). So even if you
want to run such code, there are ways to do it.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-09-19 18:58 -0400 |
| Message-ID | <op.xmgh4lgzmk81un@localhost> |
| In reply to | #33435 |
On Fri, 19 Sep 2014 08:08:10 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Celeros <kerneels@gmail.com> writes: >> I'm an extreme newbie here, but it sounds to me like stacks don't >> need to be very deep in order to do *most* things. > > Right. 256 stack items seems to be significantly more than enough > for the kinds of code I expect is run there. > While I've been using only 256 during development, I expected the actual size needed would be much larger. E.g., DJGPP (GCC for DOS) allocates 512KB for stack, and 32KB for interrupt stacks. So, maybe, the wrong question is being asked ... Instead of asking how deep a stack should be, maybe we should be asking if anyone has ever run out of stack space in Forth? If so, which Forth, which app, and under what conditions? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-19 13:28 -1000 |
| Message-ID | <Eq6dnZz0Jd-MIYHJnZ2dnUU7-K-dnZ2d@supernews.com> |
| In reply to | #33446 |
On 9/19/14 12:58 PM, Rod Pemberton wrote: > On Fri, 19 Sep 2014 08:08:10 -0400, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: >> Celeros <kerneels@gmail.com> writes: > >>> I'm an extreme newbie here, but it sounds to me like stacks don't >>> need to be very deep in order to do *most* things. >> >> Right. 256 stack items seems to be significantly more than enough >> for the kinds of code I expect is run there. >> > > While I've been using only 256 during development, I expected the > actual size needed would be much larger. E.g., DJGPP (GCC for DOS) > allocates 512KB for stack, and 32KB for interrupt stacks. So, maybe, > the wrong question is being asked ... Instead of asking how deep a > stack should be, maybe we should be asking if anyone has ever run > out of stack space in Forth? If so, which Forth, which app, and > under what conditions? We had to program very carefully to manage 32-byte data and return stacks in a control application on an 8051 with 64 bytes of on-chip memory some years ago, but we managed (it was a 16-bit implementation). Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-09-19 19:57 -0400 |
| Message-ID | <op.xmgkt6vvmk81un@localhost> |
| In reply to | #33447 |
On Fri, 19 Sep 2014 19:28:15 -0400, Elizabeth D. Rather <erather@forth.com> wrote: > On 9/19/14 12:58 PM, Rod Pemberton wrote: >> On Fri, 19 Sep 2014 08:08:10 -0400, Anton Ertl >> <anton@mips.complang.tuwien.ac.at> wrote: >>> Celeros <kerneels@gmail.com> writes: >>>> I'm an extreme newbie here, but it sounds to me like stacks don't >>>> need to be very deep in order to do *most* things. >>> >>> Right. 256 stack items seems to be significantly more than enough >>> for the kinds of code I expect is run there. >>> >> >> While I've been using only 256 during development, I expected the >> actual size needed would be much larger. E.g., DJGPP (GCC for DOS) >> allocates 512KB for stack, and 32KB for interrupt stacks. So, maybe, >> the wrong question is being asked ... Instead of asking how deep a >> stack should be, maybe we should be asking if anyone has ever run >> out of stack space in Forth? If so, which Forth, which app, and >> under what conditions? > > We had to program very carefully to manage 32-byte data and return > stacks in a control application on an 8051 with 64 bytes of on-chip > memory some years ago, but we managed (it was a 16-bit implementation). > Stephen mentioned Koopman's book earlier. Koopman has some articles in Forth Dimensions magazine too, including one on the Harris RTX 32P. Koopman seems to have come to the same conclusion as you: "The right answer, then, to how big stacks should be is 16 or 32 elements, no more." This conclusion is from his Figure-Five which is a cost of register spills versus stack size simulation. Of course, it is 1990 data. Earlier in the article: " One of the big unknowns in producing the RTX 32P was how big to make the stacks. Before, I had been limited either by the need to keep chip count low or by standard high-speed memory chip sizes. On the RTX 32P, I guessed at 512 stack elements. I guessed wrong. Simulations of several Forth programs show that many progrmas never used more than four or five stack elements. Of those that used more stack elements, all showed a small variability in stack size across reasonably large periods of time. ..." -Philipp Koopman The quote is from "Design Tradeoffs in Stack Computers," Forth Dimensions, Volume 11 Number 6, March/April 1990. An article only pdf is available from Koopman: http://users.ece.cmu.edu/~koopman/forth/4thdim_11_6.pdf Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-21 13:09 +0000 |
| Message-ID | <2014Sep21.150926@mips.complang.tuwien.ac.at> |
| In reply to | #33446 |
"Rod Pemberton" <buzzoff@nonamewhichexists.cmm> writes:
>On Fri, 19 Sep 2014 08:08:10 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>> Celeros <kerneels@gmail.com> writes:
>
>>> I'm an extreme newbie here, but it sounds to me like stacks don't
>>> need to be very deep in order to do *most* things.
>>
>> Right. 256 stack items seems to be significantly more than enough
>> for the kinds of code I expect is run there.
>>
>
>While I've been using only 256 during development, I expected the
>actual size needed would be much larger. E.g., DJGPP (GCC for DOS)
>allocates 512KB for stack, and 32KB for interrupt stacks.
C compilers put records and arrays on the stack, the Forth data and
return stacks only contain cells.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Celeros <kerneels@gmail.com> |
|---|---|
| Date | 2014-09-20 13:27 +0200 |
| Message-ID | <nqCdnfUJgocs-YDJnZ2dnUVZ7r2dnZ2d@saix.net> |
| In reply to | #33435 |
On 2014-09-19 02:08 PM, Anton Ertl wrote: > Celeros <kerneels@gmail.com> writes: >> Interesting thread. Although not related to the link posted above, I >> seem to recall from Eric LaForest's thesis: >> >> http://www.eecg.toronto.edu/~laforest/Second-Generation_Stack_Computer_Architecture.pdf >> >> that research has been done into the stack depth / sizes required for >> even fairly deep recursive algorithmic problems such as the 8 queens >> problem, and that it has been shown that usually code can be written >> that would not require a deep stack at all - tens of items as aposed to >> hundreds or more. > > A typical recursive implementation of 8-queens is not deeply > recursive, as there are at most 8 levels of recursion. A walk of a > degenerated tree would be a more realistic example. > Ok, thanks. I suppose it's not the 8 queens problem but the n-queens problem then :-). While writing it I thought, hmm.... 8 Queens - can that really be that recursive - but I did not have time to go refresh my memory on what the problem actually is, so as a shortcut I replaced my initial "very" with "fairly" - just in case, and good so else I would have been even more wrong! :-) Need to go check out what is a "degenerated tree ". Interesting stuff, and thanks for the nice responses. > Anyway, yes, for my work on stack caching > <https://www.complang.tuwien.ac.at/misc/stack-caching-data/> I > simulated a number of stack caches, and found that, out of the four > application programs I used, one used 30 stack items, and the others > used more than 32 (but probably not hundreds), but have a very low > stack cache miss rate with more than 16 items in the stack cache. > Thanks - filed it for future reading. >> I find it hard to believe and understand since intuitively it feels like >> if you have a hardware stack of say x cells that you can only have a max >> recursion depth of x or less than x? >> Maybe it was more that, with some hard stack depth of say x cells and >> the ability to have recursion to whatever level through use of memory, >> that statistically, even for aparently very recursive algorithms, an >> unusually shallow stack is *actually* needed most of the time. > > Yes. Many recursive algorithms are of the divide-and-conquer sort, > and the expected recursion depth of these algorithms is logarithmic in > the problem size. If such a problem can degenerate, one sometimes > uses techniques for avoiding the recursion in that case. E.g., for > quicksort, you can recurse into the smaller partition, and use > tail-recursion (i.e., iteration) for the larger, thus ensuring that the recursion depth does not exceed ld(n). > But as I understand it, you cannot reduce all types of recursive code to itterative versions is that right? So supposing that there are some algorithms that simply cannot be made non recursive, and since stack based machines *generally* handle recursion better than register machines, this makes a great case for the advancement of stack based machines. This makes me excited about Forth in general and stack based CPUs - but are there any modern ones besides the Green Arrays and ancestors? >> Can also remember reading that the RTX2000 had something like 256 deep >> stack, which was considered absolutely sufficient for it's space >> applications. >> So there is a nice upper limit, and they thought it sufficient enough to >> send it into space! > > Certainly. Whatever the stack size, you won't use a possibly > badly-behaved recursive algorithm in such an application; you will > probably even be quite cautious about the well-behaved ones. > >> I'm an extreme newbie here, but it sounds to me like stacks don't need >> to be very deep in order to do *most* things. > > Right. 256 stack items seems to be significantly more than enough for > the kinds of code I expect is run there. > > I don't expect it to run a parser generator, but anyway, I first ran > the parser generator Gray (recursive) on a C64, where the Forth system > had about 128 bytes of data stack and 256 bytes of return stack (with > 2-byte cells). I was worried about stack overflows, so I took stuff > off the return and data stacks in the recursive calls and put it on a > separate, larger stack (and restored the data and return stack items > from there when returning from the recursive call). So even if you > want to run such code, there are ways to do it. > Very interesting..... > - anton > - Kerneels
[toc] | [prev] | [next] | [standalone]
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web