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 | 10 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 12 of 12 — ← Prev page 1 … 10 11 [12]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-20 15:08 -0400 |
| Message-ID | <lvkjbi$c8n$1@dont-email.me> |
| In reply to | #33460 |
On 9/20/2014 11:25 AM, Anton Ertl wrote: > Celeros <kerneels@gmail.com> writes: >> On 2014-09-19 02:08 PM, Anton Ertl wrote: > [...] >> Need to go check out what is a "degenerated tree ". > > A tree that is far from balanced. In the extrem case each node only > has one child. > >>> 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? > > You can convert everything, but often you still need a stack for > storing data. > > But the usual way to avoid recursion is to choose algorithms and data > structures that don't need recursion. I remember learning about this in college, but that was a long time ago. Perhaps an example might help. Do you have an example of a problem that is inherently recursive that requires a stack when implemented with iteration? I think the issue of needing a stack is really a red herring as I mention in my other post to Andrew. There are many algorithms and problems that require memory that scales with the problem. But maybe I'm just not looking at it right and recursion is actually a different sort of beast. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-20 17:38 -0500 |
| Message-ID | <-IOdnQgYAeBVnIPJnZ2dnUU7-YudnZ2d@supernews.com> |
| In reply to | #33468 |
rickman <gnuarm@gmail.com> wrote: > On 9/20/2014 11:25 AM, Anton Ertl wrote: >> But the usual way to avoid recursion is to choose algorithms and data >> structures that don't need recursion. > > I remember learning about this in college, but that was a long time ago. > Perhaps an example might help. Do you have an example of a problem > that is inherently recursive that requires a stack when implemented with > iteration? I posted a binary tree walk here a while ago: that is a classic recursive algorithm, implemented without explicit recursive calls. You can always do this in Forth because of the stack. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-20 19:19 -0400 |
| Message-ID | <lvl23k$cu1$1@dont-email.me> |
| In reply to | #33474 |
On 9/20/2014 6:38 PM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> On 9/20/2014 11:25 AM, Anton Ertl wrote: >>> But the usual way to avoid recursion is to choose algorithms and data >>> structures that don't need recursion. >> >> I remember learning about this in college, but that was a long time ago. >> Perhaps an example might help. Do you have an example of a problem >> that is inherently recursive that requires a stack when implemented with >> iteration? > > I posted a binary tree walk here a while ago: that is a classic > recursive algorithm, implemented without explicit recursive calls. > You can always do this in Forth because of the stack. Yes and that is an algorithm where the amount of stack usage is related not to the total size of the tree, but to the maximum depth only. However, this does not require a stack. The tree can be converted into a doubly linked tree. Then you can always tell what needs to be done next by remembering where you were last and not every node in your decent. Am I wrong? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-21 03:35 -0500 |
| Message-ID | <pK2dndOBvIx4EIPJnZ2dnUU7-S-dnZ2d@supernews.com> |
| In reply to | #33476 |
rickman <gnuarm@gmail.com> wrote: > On 9/20/2014 6:38 PM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >>> On 9/20/2014 11:25 AM, Anton Ertl wrote: >>>> But the usual way to avoid recursion is to choose algorithms and data >>>> structures that don't need recursion. >>> >>> I remember learning about this in college, but that was a long time ago. >>> Perhaps an example might help. Do you have an example of a problem >>> that is inherently recursive that requires a stack when implemented with >>> iteration? >> >> I posted a binary tree walk here a while ago: that is a classic >> recursive algorithm, implemented without explicit recursive calls. >> You can always do this in Forth because of the stack. > > Yes and that is an algorithm where the amount of stack usage is related > not to the total size of the tree, but to the maximum depth only. > > However, this does not require a stack. The tree can be converted into > a doubly linked tree. Then it's a different problem, with a different solution. > Then you can always tell what needs to be done next by remembering > where you were last and not every node in your decent. Am I wrong? Yes. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-21 07:00 -0400 |
| Message-ID | <lvmb5u$3lb$2@dont-email.me> |
| In reply to | #33482 |
On 9/21/2014 4:35 AM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> On 9/20/2014 6:38 PM, Andrew Haley wrote: >>> rickman <gnuarm@gmail.com> wrote: >>>> On 9/20/2014 11:25 AM, Anton Ertl wrote: >>>>> But the usual way to avoid recursion is to choose algorithms and data >>>>> structures that don't need recursion. >>>> >>>> I remember learning about this in college, but that was a long time ago. >>>> Perhaps an example might help. Do you have an example of a problem >>>> that is inherently recursive that requires a stack when implemented with >>>> iteration? >>> >>> I posted a binary tree walk here a while ago: that is a classic >>> recursive algorithm, implemented without explicit recursive calls. >>> You can always do this in Forth because of the stack. >> >> Yes and that is an algorithm where the amount of stack usage is related >> not to the total size of the tree, but to the maximum depth only. >> >> However, this does not require a stack. The tree can be converted into >> a doubly linked tree. > > Then it's a different problem, with a different solution. How is that a "different" problem? Searching a tree is searching a tree. At least by using a doubly linked list the memory needed is defined. Although I suppose for a tree of any given size the maximum stack size required for a recursive search is also known. Whatever... potatoes, potatoes... uh, that doesn't seem to come out the same way in print. I guess I need some accents or something... Make that potaytoes, potahtoes :) -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Celeros <kerneels@gmail.com> |
|---|---|
| Date | 2014-09-22 08:54 +0200 |
| Message-ID | <cdWdndjocKYpWoLJnZ2dnUVZ8q6dnZ2d@saix.net> |
| In reply to | #33485 |
On 2014-09-21 01:00 PM, rickman wrote: > On 9/21/2014 4:35 AM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >>> On 9/20/2014 6:38 PM, Andrew Haley wrote: >>>> rickman <gnuarm@gmail.com> wrote: >>>>> On 9/20/2014 11:25 AM, Anton Ertl wrote: >>>>>> But the usual way to avoid recursion is to choose algorithms and data >>>>>> structures that don't need recursion. >>>>> >>>>> I remember learning about this in college, but that was a long time >>>>> ago. >>>>> Perhaps an example might help. Do you have an example of a problem >>>>> that is inherently recursive that requires a stack when implemented >>>>> with >>>>> iteration? >>>> >>>> I posted a binary tree walk here a while ago: that is a classic >>>> recursive algorithm, implemented without explicit recursive calls. >>>> You can always do this in Forth because of the stack. >>> >>> Yes and that is an algorithm where the amount of stack usage is related >>> not to the total size of the tree, but to the maximum depth only. >>> >>> However, this does not require a stack. The tree can be converted into >>> a doubly linked tree. >> >> Then it's a different problem, with a different solution. > > How is that a "different" problem? Searching a tree is searching a > tree. At least by using a doubly linked list the memory needed is > defined. Although I suppose for a tree of any given size the maximum > stack size required for a recursive search is also known. > > Whatever... potatoes, potatoes... uh, that doesn't seem to come out the > same way in print. I guess I need some accents or something... Make > that potaytoes, potahtoes :) > Interesting stuff. It is indeed true (Rickman?), that recursion and iteration are equivalent in that any algorithm expressed in the former style can be expressed in the latter, all be it with more effort, less elegant, varying efficiency in different languages and with different time and space tradeoffs. As someone else pointed out, TCO or tail call optimisation is really just recursion in disguise (or vice versa), and the other forms of recursion can either be reduced to single tail end and hence be viable for TCO, or implemented iteratively with the use of our friend, the stack :-). The wikipedia page on recursion is a nice read: http://en.wikipedia.org/wiki/Recursion_%28computer_science%29 and a lot of what is claimed in there makes intuitive sense and I'm sure all of the claims have formal proofs. So, in closing, my conclusion is that Forth and stack machines are special. On the one hand they make it possible to execute elegant recursive code faster (does not have the context switching overhead of register machines) and on the other hand you have a data stack ready to use for implementing recursion iteratively. What more do you want!? :-) To me at least recursive algorithms have always looked so clever and almost magical, but the joy quickly vanishes when it takes long or much resources to execute when coded in languages that favor iteration, or cause stack overflow. It surely seems that algorithm implementations where recursion is *ok* now and then could result in less code, and less code equals less potential bugs and simpler to produce a correctness proof for. Spot the recursion below :-) cheers: Exodus 3:13-15New English Translation (NET Bible) 13 Moses said to God, “If I go to the Israelites and tell them, ‘The God of your fathers has sent me to you,’ and they ask me, ‘What is his name?’—what should I say to them?” 14 God said to Moses, “I am that I am.” And he said, “You must say this to the Israelites, ‘I am has sent me to you.’” 15 God also said to Moses, “You must say this to the Israelites, ‘The Lord—the God of your fathers, the God of Abraham, the God of Isaac, and the God of Jacob—has sent me to you. This is my name forever, and this is my memorial from generation to generation.’ chao
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-22 03:26 -0400 |
| Message-ID | <lvoivg$60t$1@dont-email.me> |
| In reply to | #33502 |
On 9/22/2014 2:54 AM, Celeros wrote: > > Spot the recursion below :-) cheers: Not seeing it. Infinite loop maybe. > Exodus 3:13-15New English Translation (NET Bible) > > 13 Moses said to God, “If I go to the Israelites and tell them, ‘The God > of your fathers has sent me to you,’ and they ask me, ‘What is his > name?’—what > should I say to them?” > > 14 God said to Moses, “I am that I am.” And he said, “You must say this > to the Israelites, ‘I am has sent me to you.’” 15 God also said to > Moses, “You > must say this to the Israelites, ‘The Lord—the God of your fathers, the > God of Abraham, the God of Isaac, and the God of Jacob—has sent me to > you. This > is my name forever, and this is my memorial from generation to generation.’ Not to be confused with "I yam what I yam". Who said that? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Celeros <kerneels@gmail.com> |
|---|---|
| Date | 2014-09-22 10:03 +0200 |
| Message-ID | <zP2dncZxFYBxSoLJnZ2dnUVZ8qKdnZ2d@saix.net> |
| In reply to | #33503 |
On 2014-09-22 09:26 AM, rickman wrote: > On 9/22/2014 2:54 AM, Celeros wrote: >> >> Spot the recursion below :-) cheers: > > Not seeing it. Infinite loop maybe. > > >> Exodus 3:13-15New English Translation (NET Bible) >> >> 13 Moses said to God, “If I go to the Israelites and tell them, ‘The God >> of your fathers has sent me to you,’ and they ask me, ‘What is his >> name?’—what >> should I say to them?” >> >> 14 God said to Moses, “I am that I am.” And he said, “You must say this >> to the Israelites, ‘I am has sent me to you.’” 15 God also said to >> Moses, “You >> must say this to the Israelites, ‘The Lord—the God of your fathers, the >> God of Abraham, the God of Isaac, and the God of Jacob—has sent me to >> you. This >> is my name forever, and this is my memorial from generation to >> generation.’ > > Not to be confused with "I yam what I yam". Who said that? > Come on man, tail recursion at worst :D. Honestly! :-) can there be a more flippant response to (for me) probably one of the most significant versus ever! "Not to be confused with" - surely hope not, for then there is no hope: Popeye, of all things (spare me! :-). http://en.wikipedia.org/wiki/I_Yam_What_I_Yam Now I know why I never liked that strange cartoon.... Enjoy your day mate.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-22 05:29 -0400 |
| Message-ID | <lvoq6o$gq6$3@dont-email.me> |
| In reply to | #33505 |
On 9/22/2014 4:03 AM, Celeros wrote: > On 2014-09-22 09:26 AM, rickman wrote: >> On 9/22/2014 2:54 AM, Celeros wrote: >>> >>> Spot the recursion below :-) cheers: >> >> Not seeing it. Infinite loop maybe. >> >> >>> Exodus 3:13-15New English Translation (NET Bible) >>> >>> 13 Moses said to God, “If I go to the Israelites and tell them, ‘The God >>> of your fathers has sent me to you,’ and they ask me, ‘What is his >>> name?’—what >>> should I say to them?” >>> >>> 14 God said to Moses, “I am that I am.” And he said, “You must say this >>> to the Israelites, ‘I am has sent me to you.’” 15 God also said to >>> Moses, “You >>> must say this to the Israelites, ‘The Lord—the God of your fathers, the >>> God of Abraham, the God of Isaac, and the God of Jacob—has sent me to >>> you. This >>> is my name forever, and this is my memorial from generation to >>> generation.’ >> >> Not to be confused with "I yam what I yam". Who said that? >> > Come on man, tail recursion at worst :D. > > Honestly! :-) can there be a more flippant response to (for me) probably > one of the most significant versus ever! > > "Not to be confused with" - surely hope not, for then there is no hope: > Popeye, of all things (spare me! :-). > http://en.wikipedia.org/wiki/I_Yam_What_I_Yam > > Now I know why I never liked that strange cartoon.... > > Enjoy your day mate. Cheers. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2014-09-19 02:53 -0700 |
| Message-ID | <f8b53cf5-1b9b-425d-ae9f-ed1aae11cb9c@googlegroups.com> |
| In reply to | #33409 |
> We did a C code generator a few years ago for a dual stack machine > as an internal exercise and did a C to forth translation both did not > produce the results we were looking for or needed. The C to forth > had some inherent code reliability issues suitable for a long thread > of heated debate. There's a C to Forth translator (with full source code) available on the MPE web site from the downloads page. It would be interesting to update this with a couple of extra registers and taking note of Chris Bailey's UFO instructions set. Ste[hen
[toc] | [prev] | [standalone]
Page 12 of 12 — ← Prev page 1 … 10 11 [12]
Back to top | Article view | comp.lang.forth
csiph-web