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 1 of 12 [1] 2 3 … 12 Next page →
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-16 11:22 -0400 |
| Subject | Metrics on stack usage |
| Message-ID | <541855C0.2558D27D@bytecraft.com> |
I am working on a code generator for a stack processor. Who better to ask about real stack requirements than a forth group. The question is what is the expected stack requirements for a forth implementation? Is there any benchmark code that test stack usage? Many Thanks w..
[toc] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-16 11:41 -0400 |
| Message-ID | <lv9lng$4p7$1@dont-email.me> |
| In reply to | #33379 |
On 9/16/2014 11:22 AM, Walter Banks wrote: > I am working on a code generator for a stack processor. > Who better to ask about real stack requirements than a forth group. > > The question is what is the expected stack requirements for a > forth implementation? > > Is there any benchmark code that test stack usage? > > Many Thanks I can't answer your question, but I'm sure others can give you some guidance. I expect the question is a bit like, "how long is a piece of string". How much stack you will need greatly depends on what you are doing. That is it depends much more on your apps than it does Forth itself. There are many Forths that run on very limited hardware and so have a rather small stack although they are fully capable of performing many tasks. There are also Forths on PCs with huge stacks which allow deep recursion. So what sort of apps are you thinking of running? Also, do you mean you are working on a code generator which produces code for a virtual stack machine or you have a hardware implementation of a stack processor? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-16 13:20 -0400 |
| Message-ID | <5418716C.E8B0E114@bytecraft.com> |
| In reply to | #33381 |
rickman wrote: > On 9/16/2014 11:22 AM, Walter Banks wrote: > > I am working on a code generator for a stack processor. > > Who better to ask about real stack requirements than a forth group. > > > > The question is what is the expected stack requirements for a > > forth implementation? > > > > Is there any benchmark code that test stack usage? > > > > Many Thanks > > I can't answer your question, but I'm sure others can give you some > guidance. I expect the question is a bit like, "how long is a piece of > string". How much stack you will need greatly depends on what you are > doing. That is it depends much more on your apps than it does Forth > itself. There are many Forths that run on very limited hardware and so > have a rather small stack although they are fully capable of performing > many tasks. There are also Forths on PCs with huge stacks which allow > deep recursion. So what sort of apps are you thinking of running? > > Also, do you mean you are working on a code generator which produces > code for a virtual stack machine or you have a hardware implementation > of a stack processor? I agree that it is possible to create examples that can use all available stack. There are practical limits in real life code. There is a statistical distribution of stack requirements given actual application code. It is this distribution that I am interested in tapping into the knowledge of this NG. It is real hardware. I will post details when they are released. w..
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-16 13:39 -0400 |
| Message-ID | <lv9slg$rkq$1@dont-email.me> |
| In reply to | #33386 |
On 9/16/2014 1:20 PM, Walter Banks wrote: > rickman wrote: > >> On 9/16/2014 11:22 AM, Walter Banks wrote: >>> I am working on a code generator for a stack processor. >>> Who better to ask about real stack requirements than a forth group. >>> >>> The question is what is the expected stack requirements for a >>> forth implementation? >>> >>> Is there any benchmark code that test stack usage? >>> >>> Many Thanks >> >> I can't answer your question, but I'm sure others can give you some >> guidance. I expect the question is a bit like, "how long is a piece of >> string". How much stack you will need greatly depends on what you are >> doing. That is it depends much more on your apps than it does Forth >> itself. There are many Forths that run on very limited hardware and so >> have a rather small stack although they are fully capable of performing >> many tasks. There are also Forths on PCs with huge stacks which allow >> deep recursion. So what sort of apps are you thinking of running? >> >> Also, do you mean you are working on a code generator which produces >> code for a virtual stack machine or you have a hardware implementation >> of a stack processor? > > I agree that it is possible to create examples that can use all > available stack. There are practical limits in real life code. > There is a statistical distribution of stack requirements given > actual application code. It is this distribution that I am > interested in tapping into the knowledge of this NG. > > It is real hardware. I will post details when they are > released. What apps are intended for your hardware? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-16 15:11 -0400 |
| Message-ID | <54188B56.41C6FC49@bytecraft.com> |
| In reply to | #33388 |
rickman wrote: > On 9/16/2014 1:20 PM, Walter Banks wrote: > > rickman wrote: > > > >> On 9/16/2014 11:22 AM, Walter Banks wrote: > >>> I am working on a code generator for a stack processor. > >>> Who better to ask about real stack requirements than a forth group. > >>> > >>> The question is what is the expected stack requirements for a > >>> forth implementation? > >>> > >>> Is there any benchmark code that test stack usage? > >>> > >>> Many Thanks > >> > >> I can't answer your question, but I'm sure others can give you some > >> guidance. I expect the question is a bit like, "how long is a piece of > >> string". How much stack you will need greatly depends on what you are > >> doing. That is it depends much more on your apps than it does Forth > >> itself. There are many Forths that run on very limited hardware and so > >> have a rather small stack although they are fully capable of performing > >> many tasks. There are also Forths on PCs with huge stacks which allow > >> deep recursion. So what sort of apps are you thinking of running? > >> > >> Also, do you mean you are working on a code generator which produces > >> code for a virtual stack machine or you have a hardware implementation > >> of a stack processor? > > > > I agree that it is possible to create examples that can use all > > available stack. There are practical limits in real life code. > > There is a statistical distribution of stack requirements given > > actual application code. It is this distribution that I am > > interested in tapping into the knowledge of this NG. > > > > It is real hardware. I will post details when they are > > released. > > What apps are intended for your hardware? It is (yet another) non hosted embedded systems processor that will probably be used mostly for stand alone process control systems. w..
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-16 17:24 -0400 |
| Message-ID | <lva9rp$4ad$1@dont-email.me> |
| In reply to | #33392 |
On 9/16/2014 3:11 PM, Walter Banks wrote: > rickman wrote: > >> On 9/16/2014 1:20 PM, Walter Banks wrote: >>> rickman wrote: >>> >>>> On 9/16/2014 11:22 AM, Walter Banks wrote: >>>>> I am working on a code generator for a stack processor. >>>>> Who better to ask about real stack requirements than a forth group. >>>>> >>>>> The question is what is the expected stack requirements for a >>>>> forth implementation? >>>>> >>>>> Is there any benchmark code that test stack usage? >>>>> >>>>> Many Thanks >>>> >>>> I can't answer your question, but I'm sure others can give you some >>>> guidance. I expect the question is a bit like, "how long is a piece of >>>> string". How much stack you will need greatly depends on what you are >>>> doing. That is it depends much more on your apps than it does Forth >>>> itself. There are many Forths that run on very limited hardware and so >>>> have a rather small stack although they are fully capable of performing >>>> many tasks. There are also Forths on PCs with huge stacks which allow >>>> deep recursion. So what sort of apps are you thinking of running? >>>> >>>> Also, do you mean you are working on a code generator which produces >>>> code for a virtual stack machine or you have a hardware implementation >>>> of a stack processor? >>> >>> I agree that it is possible to create examples that can use all >>> available stack. There are practical limits in real life code. >>> There is a statistical distribution of stack requirements given >>> actual application code. It is this distribution that I am >>> interested in tapping into the knowledge of this NG. >>> >>> It is real hardware. I will post details when they are >>> released. >> >> What apps are intended for your hardware? > > It is (yet another) non hosted embedded systems processor > that will probably be used mostly for stand alone process > control systems. Why don't you measure *your* apps for stack usage? I would think that is what is important. I have worked on my own CPU design and when asked for advice on benchmark code here I was told to use my intended apps... makes sense to me. :) -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-17 17:58 -0400 |
| Message-ID | <541A03E8.5B9399E4@bytecraft.com> |
| In reply to | #33396 |
rickman wrote: > On 9/16/2014 3:11 PM, Walter Banks wrote: > > rickman wrote: > > > >> On 9/16/2014 1:20 PM, Walter Banks wrote: > >>> rickman wrote: > >>> > >> What apps are intended for your hardware? > > > > It is (yet another) non hosted embedded systems processor > > that will probably be used mostly for stand alone process > > control systems. > > Why don't you measure *your* apps for stack usage? I would think that > is what is important. > > I have worked on my own CPU design and when asked for advice on > benchmark code here I was told to use my intended apps... makes sense to > me. :) Intended apps are always the best measure. (get features you measure in design) I know what I am getting with my code generator now. The question is do I have a local minima or a minima. The bigger question and now in the development process is a good time test if I can the code generation approach. w..
[toc] | [prev] | [next] | [standalone]
| From | barrym95838@yahoo.com |
|---|---|
| Date | 2014-09-16 08:47 -0700 |
| Message-ID | <3a80ad9d-4b38-4db4-96c6-e3adcffefacb@googlegroups.com> |
| In reply to | #33379 |
On Tuesday, September 16, 2014 8:21:35 AM UTC-7, Walter Banks wrote: > I am working on a code generator for a stack processor. > Who better to ask about real stack requirements than a forth group. > > The question is what is the expected stack requirements for a > forth implementation? > > Is there any benchmark code that test stack usage? > > Many Thanks > > w.. The bewildering variety of possible applications makes a simple answer difficult. Perhaps the best way would be to write a simulator, initialize a large stack space with a unique bit pattern, and feed it the heaviest program you can find. A post-mortem stack dump should give you your answer. My friend Garth did that for his embedded 65802 work-bench computer, and came to the conclusion that 256 bytes was way more than enough for each of his two forth stacks, but he wasn't doing GUIs or anything fancy. http://www.mosaic-industries.com/embedded-systems/c-ide-software-development/codeblocks-gnu-c-gcc-compiler/c-library-hcs12-9s12/stack-space Mike
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-16 14:41 -0400 |
| Message-ID | <54188444.87C0B4CB@bytecraft.com> |
| In reply to | #33382 |
barrym95838@yahoo.com wrote: > On Tuesday, September 16, 2014 8:21:35 AM UTC-7, Walter Banks wrote: > > I am working on a code generator for a stack processor. > > Who better to ask about real stack requirements than a forth group. > > > > The question is what is the expected stack requirements for a > > forth implementation? > > The bewildering variety of possible applications makes a simple > answer difficult. Perhaps the best way would be to write a > simulator, initialize a large stack space with a unique bit > pattern, and feed it the heaviest program you can find. A > post-mortem stack dump should give you your answer. My friend > Garth did that for his embedded 65802 work-bench computer, and > came to the conclusion that 256 bytes was way more than enough > for each of his two forth stacks, but he wasn't doing GUIs or > anything fancy. > > http://www.mosaic-industries.com/embedded-systems/c-ide-software-development/codeblocks-gnu-c-gcc-compiler/c-library-hcs12-9s12/stack-space > The answer is going to be a statistical range at best. One number I do have for conventional embedded systems is I have seen one commercial application that had more than 14 return levels and about a half dozen that had 14 levels. The one with more than 14 levels could have been re-written to 6 levels. The question of how much stack space was needed is still statistical mix of how much actual data was on the stack. w..
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-09-16 18:55 -0400 |
| Message-ID | <op.xmaxyqt1mk81un@localhost> |
| In reply to | #33382 |
On Tue, 16 Sep 2014 11:47:20 -0400, <barrym95838@yahoo.com> wrote: > On Tuesday, September 16, 2014 8:21:35 AM UTC-7, Walter Banks wrote: >> I am working on a code generator for a stack processor. >> Who better to ask about real stack requirements than a forth group. >> >> The question is what is the expected stack requirements for a >> forth implementation? >> >> Is there any benchmark code that test stack usage? >> >> Many Thanks >> >> w.. > > The bewildering variety of possible applications makes a simple > answer difficult. Perhaps the best way would be to write a > simulator, initialize a large stack space with a unique bit > pattern, and feed it the heaviest program you can find. A > post-mortem stack dump should give you your answer. My friend > Garth did that for his embedded 65802 work-bench computer, and > came to the conclusion that 256 bytes was way more than enough > for each of his two forth stacks, but he wasn't doing GUIs or > anything fancy. > I'd like to know what a decent size is for a Forth stack too. I've asked about this in the past. I use 256 bytes for my Forth interpreter which is under development, i.e., I haven't executed any large or serious apps on it. I have run John Hayes core test without stack overflow. Also, I know that 256 bytes is way too small for recursive words in Forth. As mentioned by the person with the "rickman" monicker, you should be able to measure this. You can redefine : (colon) and ; (semicol) in Forth. Usually, this is used for a custom word, like TRACE , which shows which words are being executed as the app is executing. There are past posts in c.l.f. on this, and IIRC articles in Forth Dimensions magazine too. So, you should be able to redefine them and use DEPTH to get the stack length per word. This value can be used to determine the peak stack length and compute the average stack length per executed word. You'd just need a really representative set of apps to test. Someone else will have to propose redifinitions of : and ; for him. I'm not spending the time today. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-16 14:33 -1000 |
| Message-ID | <-L6dnUC0q8RYS4XJnZ2dnUU7-SednZ2d@supernews.com> |
| In reply to | #33397 |
On 9/16/14 12:55 PM, Rod Pemberton wrote: ... > > I'd like to know what a decent size is for a Forth stack too. > I've asked about this in the past. > > I use 256 bytes for my Forth interpreter which is under development, > i.e., I haven't executed any large or serious apps on it. I have > run John Hayes core test without stack overflow. Also, I know that > 256 bytes is way too small for recursive words in Forth. Yes, but very few Forth applications need recursion. I can only think of a couple of examples in all the applications I've worked on. As the OP mentioned, it makes a big difference whether you're on a hosted or native system, as OS calls typically use a lot more stack than Forth definitions. Also, if you're dealing with C you'll need much deeper stacks. > As mentioned by the person with the "rickman" monicker, you should > be able to measure this. You can redefine : (colon) and ; (semicol) > in Forth. Usually, this is used for a custom word, like TRACE , > which shows which words are being executed as the app is executing. > There are past posts in c.l.f. on this, and IIRC articles in Forth > Dimensions magazine too. So, you should be able to redefine them > and use DEPTH to get the stack length per word. This value can be > used to determine the peak stack length and compute the average stack > length per executed word. You'd just need a really representative > set of apps to test. > > Someone else will have to propose redifinitions of : and ; for him. > I'm not spending the time today. I doubt seriously if instrumenting : and ; is the way to go. You can learn a lot that way, but not on this particular issue. The reason is that colon definitions are not aware of usage by words they call or that call them, unless you make the instrumentation so complex it changes what you're trying to measure (and is slow as molasses to boot). 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 | barrym95838@yahoo.com |
|---|---|
| Date | 2014-09-16 18:30 -0700 |
| Message-ID | <12d77d69-36a8-465a-9a0d-cd3f13f762aa@googlegroups.com> |
| In reply to | #33399 |
On Tuesday, September 16, 2014 5:33:11 PM UTC-7, Elizabeth D. Rather wrote: > [snip] > As the OP mentioned, it makes a big difference whether you're on a > hosted or native system, as OS calls typically use a lot more stack than > Forth definitions. Also, if you're dealing with C you'll need much > deeper stacks. > I recently read somewhere that you should allow at MINIMUM of 1KB for printf() ... yikes! > [snip] > I doubt seriously if instrumenting : and ; is the way to go. You can > learn a lot that way, but not on this particular issue. The reason is > that colon definitions are not aware of usage by words they call or that > call them, unless you make the instrumentation so complex it changes > what you're trying to measure (and is slow as molasses to boot). > I believe that figForth's TRACE wedged itself into NEXT, so perhaps a simple compare of the values in the SP with a variable could be done quickly and without causing too much hassle. If the current value was lower (deeper) than the one stored in the variable(s), TRACE could simply store an updated "max depth" and proceed. The same goes for RP. Of course, this would only be a snap on a system that has an explicit NEXT routine to wedge, in the old 8-bit cpu, ITC tradition. There was also a TCOLON routine that could make note of a nesting level change, but I never used it, and I don't think that it would be particularly helpful in this particular case. Mike
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-16 15:44 +0000 |
| Message-ID | <2014Sep16.174458@mips.complang.tuwien.ac.at> |
| In reply to | #33379 |
Walter Banks <walter@bytecraft.com> writes:
>I am working on a code generator for a stack processor.
>Who better to ask about real stack requirements than a forth group.
>
>The question is what is the expected stack requirements for a
>forth implementation?
I am not sure what you are looking for, but you may find data of
interest to you in:
@InProceedings{ertl95pldi,
author = "M. Anton Ertl",
title = "Stack Caching for Interpreters",
crossref = "sigplan95",
pages = "315--327",
url = "http://www.complang.tuwien.ac.at/papers/ertl95pldi.ps.gz",
abstract = "An interpreter can spend a significant part of its
execution time on arguments of virtual machine
instructions. This paper explores two methods to
reduce this overhead for virtual stack machines by
caching top-of-stack values in (real machine)
registers. The {\em dynamic method} is based on
having, for every possible state of the cache, one
specialized version of the whole interpreter; the
execution of an instruction usually changes the
state of the cache and the next instruction is
executed in the version corresponding to the new
state. In the {\em static method} a state machine
that keeps track of the cache state is added to the
compiler. Common instructions exist in specialized
versions for several states, but it is not necessary
to have a version of every instruction for every
cache state. Stack manipulation instructions are
optimized away."
}
@Proceedings{sigplan95,
booktitle = "SIGPLAN Conference on Programming Language
Design and Implementation (PLDI'95)",
title = "SIGPLAN Conference on Programming Language
Design and Implementation (PLDI'95)",
year = "1995",
key = "PLDI '95"
}
>Is there any benchmark code that test stack usage?
<http://www.complang.tuwien.ac.at/forth/appbench-1.2.zip> is a set of
Forth applications used as benchmarks. If you want to have something
that has typical stack behaviour, you could do worse than to use these
benchmarks.
- 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 | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-16 13:22 -0400 |
| Message-ID | <541871CD.59A7FB21@bytecraft.com> |
| In reply to | #33383 |
Anton Ertl wrote:
> Walter Banks <walter@bytecraft.com> writes:
> >I am working on a code generator for a stack processor.
> >Who better to ask about real stack requirements than a forth group.
> >
> >The question is what is the expected stack requirements for a
> >forth implementation?
>
> I am not sure what you are looking for, but you may find data of
> interest to you in:
>
> @InProceedings{ertl95pldi,
> author = "M. Anton Ertl",
> title = "Stack Caching for Interpreters",
> crossref = "sigplan95",
> pages = "315--327",
> url = "http://www.complang.tuwien.ac.at/papers/ertl95pldi.ps.gz",
> abstract = "An interpreter can spend a significant part of its
> execution time on arguments of virtual machine
> instructions. This paper explores two methods to
> reduce this overhead for virtual stack machines by
> caching top-of-stack values in (real machine)
>
>
> >Is there any benchmark code that test stack usage?
>
> <http://www.complang.tuwien.ac.at/forth/appbench-1.2.zip> is a set of
> Forth applications used as benchmarks. If you want to have something
> that has typical stack behaviour, you could do worse than to use these
> benchmarks.
>
> - 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/
Thanks.
w..
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-16 09:18 -0700 |
| Message-ID | <7xmw9zletd.fsf@ruckus.brouhaha.com> |
| In reply to | #33379 |
Walter Banks <walter@bytecraft.com> writes: > I am working on a code generator for a stack processor. > Who better to ask about real stack requirements than a forth group. > The question is what is the expected stack requirements for a > forth implementation? Is your processor intended to run Forth programs written in Forth style? If not, the info you ask may not really be useful. Forth programs tend to be globally hand optimized to re-use stack slots and keep the stack traffic smooth.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-16 15:39 -0400 |
| Message-ID | <541891FE.9157C03@bytecraft.com> |
| In reply to | #33384 |
Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: > > I am working on a code generator for a stack processor. > > Who better to ask about real stack requirements than a forth group. > > The question is what is the expected stack requirements for a > > forth implementation? > > Is your processor intended to run Forth programs written in Forth style? > If not, the info you ask may not really be useful. Forth programs tend > to be globally hand optimized to re-use stack slots and keep the stack > traffic smooth. The original source is not forth. The code generator is starting with full application program data flow information and maps the code on the execution engine. The forth experience here is relevant and probably could be used in the code generator. The code generator uses a rule based expert system that can utilize and evaluate several competing strategies and select the one most appropriate for the code generation, "this time" The kind of code generation "tricks" when programmers hand code applications can be easily made part of the overall code generator. (I don't want to get dragged into a hand vs machine code efficiency argument) The stack question comes from a bigger argument about what is an appropriate stack size for a processor. Part of the discussion has been about the nature of code written for a stack machine and how it affects machine resources. w..
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-16 09:41 -1000 |
| Message-ID | <xN-dnZP1uevFD4XJnZ2dnUU7-R2dnZ2d@supernews.com> |
| In reply to | #33394 |
On 9/16/14 9:39 AM, Walter Banks wrote: > Paul Rubin wrote: > >> Walter Banks <walter@bytecraft.com> writes: >>> I am working on a code generator for a stack processor. >>> Who better to ask about real stack requirements than a forth group. >>> The question is what is the expected stack requirements for a >>> forth implementation? >> >> Is your processor intended to run Forth programs written in Forth style? >> If not, the info you ask may not really be useful. Forth programs tend >> to be globally hand optimized to re-use stack slots and keep the stack >> traffic smooth. > > The original source is not forth. The code generator is starting with full > application program data flow information and maps the code on the > execution engine. The forth experience here is relevant and probably > could be used in the code generator. The code generator uses a rule > based expert system that can utilize and evaluate several competing > strategies and select the one most appropriate for the code > generation, "this time" > > The kind of code generation "tricks" when programmers hand code > applications can be easily made part of the overall code generator. > (I don't want to get dragged into a hand vs machine code efficiency > argument) > > The stack question comes from a bigger argument about what is > an appropriate stack size for a processor. Part of the discussion > has been about the nature of code written for a stack machine and > how it affects machine resources. Then I agree with Paul that Forth data may not be useful. But the DEADBEEF trick can still get useful info. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-16 16:11 -0700 |
| Message-ID | <7xoaufyxch.fsf@ruckus.brouhaha.com> |
| In reply to | #33394 |
Walter Banks <walter@bytecraft.com> writes: > The stack question comes from a bigger argument about what is > an appropriate stack size for a processor. Part of the discussion > has been about the nature of code written for a stack machine and > how it affects machine resources. You should look up Philip Koopman's old book "Stack Machines" and related papers, if you haven't. Also the more recent work by Tikhon Jelvis about compiling for the GreenArrays processor: http://jelv.is/chlorophyll.pdf
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-17 16:34 -0400 |
| Message-ID | <5419F03F.4E836CD5@bytecraft.com> |
| In reply to | #33398 |
Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: > > The stack question comes from a bigger argument about what is > > an appropriate stack size for a processor. Part of the discussion > > has been about the nature of code written for a stack machine and > > how it affects machine resources. > > You should look up Philip Koopman's old book "Stack Machines" and > related papers, if you haven't. Also the more recent work by Tikhon > Jelvis about compiling for the GreenArrays processor: > > http://jelv.is/chlorophyll.pdf I have Koopman's book and some other papers he wrote for various forth conferences. Thanks for the other link which I had not seen my quick glance is an interesting paper. w..
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-17 17:26 -0400 |
| Message-ID | <lvcubk$tfm$1@dont-email.me> |
| In reply to | #33398 |
On 9/16/2014 7:11 PM, Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: >> The stack question comes from a bigger argument about what is >> an appropriate stack size for a processor. Part of the discussion >> has been about the nature of code written for a stack machine and >> how it affects machine resources. > > You should look up Philip Koopman's old book "Stack Machines" and > related papers, if you haven't. Also the more recent work by Tikhon > Jelvis about compiling for the GreenArrays processor: > > http://jelv.is/chlorophyll.pdf I was glancing through this paper and see they discuss a "trick" that can be used on the GA144 that won't work in most other machines. The stack is a circular file it doesn't matter if you leave data littering the bottom of the stack. In fact, that can be a "feature" if you happen to find the circular size to be convenient. But as long as your code does not get called with other parameters on the stack it can leave junk on the stack and just ignore it potentially shortening the program and running faster. This would likely not be unusual in the tiny apps that are common on the GA144 processors. Not that there are a lot of GA144 programmers here.... or anywhere else. I'm just sayin'... -- Rick
[toc] | [prev] | [next] | [standalone]
Page 1 of 12 [1] 2 3 … 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web