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 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-18 11:53 -1000 |
| Message-ID | <_-qdnUAFZpagyYbJnZ2dnUU7-eOdnZ2d@supernews.com> |
| In reply to | #33419 |
On 9/18/14 1:33 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Studies have indicated >> that there is measurable performance overhead in using locals. > > Which studies? Sure, most Forth systems currently don't implement > locals very efficiently, but on register machines that's just an > artifact of the implementation. A compiler can keep locals in > registers just as one can keep stack items in registers; and I believe > that iForth does that. Stephen reported a while back that one of his major customers rewrite an application that had used locals extensively, and it sped up significantly by minimizing locals use. FORTH, Inc. comparisons have been more limited, but there's at least the cost of setting up and taking down the locals frame. 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-09-19 01:14 -0700 |
| Message-ID | <f9cf1d44-e8f4-4fed-8c07-d0a9e47830b7@googlegroups.com> |
| In reply to | #33424 |
On Thursday, 18 September 2014 22:53:05 UTC+1, Elizabeth D. Rather wrote: > Stephen reported a while back that one of his major customers rewrite an > application that had used locals extensively, and it sped up > significantly by minimizing locals use. FORTH, Inc. comparisons have > been more limited, but there's at least the cost of setting up and > taking down the locals frame. I see that as a limitation of the compiler (perhaps placed upon it by the 32-bit X86 environment) rather than any conceptual problem with locals themselves. If you have a register based processor, with enough registers to hold a few locals then there's no real reason why locals should be so slow as not recommend their use. Is there? I imagine that this would be less of an issue on a 64-bit X86 processor that has more registers. The optimizer could take account of the additional registers and emit more efficient code as a result.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-19 03:32 -0500 |
| Message-ID | <1fydnXgT7NWNd4bJnZ2dnUU7-cednZ2d@supernews.com> |
| In reply to | #33429 |
Mark Wills <markwills1970@gmail.com> wrote: > On Thursday, 18 September 2014 22:53:05 UTC+1, Elizabeth D. Rather wrote: >> Stephen reported a while back that one of his major customers rewrite an >> application that had used locals extensively, and it sped up >> significantly by minimizing locals use. FORTH, Inc. comparisons have >> been more limited, but there's at least the cost of setting up and >> taking down the locals frame. > > I see that as a limitation of the compiler (perhaps placed upon it by > the 32-bit X86 environment) rather than any conceptual problem with > locals themselves. If you have a register based processor, with enough > registers to hold a few locals then there's no real reason why locals > should be so slow as not recommend their use. Is there? No, there's not. The problem is (I suspect) more that locals are abit of an afterthought rather than at the core of the design of an optimizer. And, of course, programmers write for the system they're using. Really efficient locals would change the way people write Forth. > I imagine that this would be less of an issue on a 64-bit X86 processor > that has more registers. The optimizer could take account of the > additional registers and emit more efficient code as a result. Yes, but 16 registers is still slightly too tight for a register allocator. 32 (ARM64,MIPS, PPC, etc.) seems to be a sweet spot. It depends on how much inlining you do. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-19 12:41 +0000 |
| Message-ID | <2014Sep19.144156@mips.complang.tuwien.ac.at> |
| In reply to | #33430 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I imagine that this would be less of an issue on a 64-bit X86 processor
>> that has more registers. The optimizer could take account of the
>> additional registers and emit more efficient code as a result.
>
>Yes, but 16 registers is still slightly too tight for a register
>allocator. 32 (ARM64,MIPS, PPC, etc.) seems to be a sweet spot. It
>depends on how much inlining you do.
Given my data on stack caching, I doubt that. There are very few
cache evictions in a 16-cell dynamic stack cache, so I think that 16
registers are fine for Forth, even with inlining, and even with locals
(ok, we might discuss whether the amount of data increases if you keep
the data in locals rather than on the stack, but that discussion is
probably better held separately). Maybe Marcel Hendrix can provide
some insights.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-19 12:14 -0500 |
| Message-ID | <saadndvaVaAM-YHJnZ2dnUU7-VednZ2d@supernews.com> |
| In reply to | #33436 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> I imagine that this would be less of an issue on a 64-bit X86 processor >>> that has more registers. The optimizer could take account of the >>> additional registers and emit more efficient code as a result. >> >>Yes, but 16 registers is still slightly too tight for a register >>allocator. 32 (ARM64,MIPS, PPC, etc.) seems to be a sweet spot. It >>depends on how much inlining you do. > > Given my data on stack caching, I doubt that. There are very few > cache evictions in a 16-cell dynamic stack cache, so I think that 16 > registers are fine for Forth, even with inlining, and even with locals > (ok, we might discuss whether the amount of data increases if you keep > the data in locals rather than on the stack, but that discussion is > probably better held separately). Maybe Marcel Hendrix can provide > some insights. Interesting. I wonder why Forth should be different from other languages in this regard. <speculating> I'd observe, though, that it must depend on how much inlining you do, and how much global register allocation you do. Surely any significant program has more than 16 live values at some point; and this must be true of all languages because it is a property of the algorithm being used, not the language. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-20 15:41 +0000 |
| Message-ID | <2014Sep20.174103@mips.complang.tuwien.ac.at> |
| In reply to | #33442 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Given my data on stack caching, I doubt that. There are very few
>> cache evictions in a 16-cell dynamic stack cache, so I think that 16
>> registers are fine for Forth, even with inlining, and even with locals
>> (ok, we might discuss whether the amount of data increases if you keep
>> the data in locals rather than on the stack, but that discussion is
>> probably better held separately). Maybe Marcel Hendrix can provide
>> some insights.
>
>Interesting. I wonder why Forth should be different from other
>languages in this regard.
Forth programmers only have access to a very few stack items, so they
organize the definitions to use only few stack items. Programs don't
do that many call levels, and don't use much more space when calling
(not that many values are kept alive across a call in the caller).
><speculating>
>I'd observe, though, that it must depend on how much inlining you do,
>and how much global register allocation you do.
Note that the data on stack caching comes from complete runs, i.e.,
corresponds to inlining every call in the program. If 16 registers
rarely overflows there, it will rarely overflow when inlining (if a
competent register allocator is at work).
> Surely any
>significant program has more than 16 live values at some point; and
>this must be true of all languages because it is a property of the
>algorithm being used, not the language.
Much of the register usage is a property of the language and it's
implementation, e.g., calling conventions. GCC on Alpha and MIPS runs
out of registers when I keep two stack items in registers, while GCC
on PowerPC does fine with 8 stack items; the difference is in the
calling convention.
- 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 | mhx@iae.nl |
|---|---|
| Date | 2014-09-19 12:31 -0700 |
| Message-ID | <cafde042-8e2d-488f-8b5c-bcb11efc4114@googlegroups.com> |
| In reply to | #33436 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes
Re: Metrics on stack usage
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> I imagine that this would be less of an issue on a 64-bit X86 processor
>>> that has more registers. The optimizer could take account of the
>>> additional registers and emit more efficient code as a result.
>>
>>Yes, but 16 registers is still slightly too tight for a register
>>allocator. 32 (ARM64,MIPS, PPC, etc.) seems to be a sweet spot. It
>>depends on how much inlining you do.
> Given my data on stack caching, I doubt that. There are very few
> cache evictions in a 16-cell dynamic stack cache, so I think that 16
> registers are fine for Forth, even with inlining, and even with locals
> (ok, we might discuss whether the amount of data increases if you keep
> the data in locals rather than on the stack, but that discussion is
> probably better held separately). Maybe Marcel Hendrix can provide
> some insights.
Not really.
Like Stephen, I have noticed that even quite good looking locals code
can be a surprisingly large amount slower than equivalent but much
busier stack code. It's on my list to find out the hardware reasons
for this. Floating-point code has no problems in this respect.
iForth 64-bit has not benefitted at all from having 16 registers to
play with. Again I suspect hardware reasons, and I hope that these
problems may disappear with successive processor upgrades.
With 32 registers I would of course use some of them to hold locals
because it stands to reason that slow memory access to stacks
is responsible for the currently slightly disappointing results.
The currently available 16 registers are barely enough for iForth.
I have never really understood the extremely negative feelings of
Forth programmers for local variables. CLF is littered with
amusing postings of people trying to prove that their local-free
code is faster and more readable than the locals equivalent.
Used with care locals make programming a lot easier and code a
lot more readable. Of course, the negative attitude is helpful
in enforcing the 'with care' part :-)
I have added a few Forth snippets using locals, together with
generated code.
-marcel
-- --------------------------------------------------------------------
#100000000 constant x
: locals ( a b c x -- q ) LOCALS| x c b a | a x * x * b x * + c + ;
: bench-locals CR ." locals : " x 0 do 1 2 3 4 locals drop loop ;
DOC
(*
FORTH> see locals
Flags: ANSI
$012282C0 : locals
$012282CA pop rbx
$012282CB lea rsi, [rsi #-16 +] qword
$012282CF mov [rsi] qword, rbx
$012282D2 pop rbx
$012282D3 lea rsi, [rsi #-16 +] qword
$012282D7 mov [rsi] qword, rbx
$012282DA pop rbx
$012282DB lea rsi, [rsi #-16 +] qword
$012282DF mov [rsi] qword, rbx
$012282E2 pop rbx
$012282E3 lea rsi, [rsi #-16 +] qword
$012282E7 mov [rsi] qword, rbx
$012282EA mov rbx, [rsi] qword
$012282ED imul rbx, [rsi #48 +] qword
$012282F2 imul rbx, [rsi #48 +] qword
$012282F7 mov rdi, [rsi #16 +] qword
$012282FB imul rdi, [rsi #48 +] qword
$01228300 lea rbx, [rbx rdi*1] qword
$01228304 add rbx, [rsi #32 +] qword
$01228308 push rbx
$01228309 add rsi, #64 b#
$0122830D ;
*)
ENDDOC
: ilocals ( a b c x -- q ) PARAMS| a b c x | a x * x * b x * + c + ;
: test 1 2 3 4 ilocals . ;
DOC
(*
FORTH> see test
Flags: ANSI
$01227080 : test
$0122708A push #27 b#
$0122708C jmp .+10 ( $0113A97A ) offset NEAR
$01227091 ;
*)
ENDDOC
: { ;
: }ack RECURSIVE ( t s -- n )
DUP 0= IF drop 1+ exit ENDIF
LOCALS| s t |
{ t IF { t 1- s }ack ELSE 1 ENDIF
s 1-
}ack ;
DOC
(*
$01226900 : }ack
$0122690A pop rbx
$0122690B cmp rbx, 0 b#
$0122690F jne $01226921 offset NEAR
$01226915 pop rbx
$01226916 lea rbx, [rbx 1 +] qword
$0122691A push rbx
$0122691B jmp $01226981 offset NEAR
$01226920 pop rbx
$01226921 lea rsi, [rsi #-16 +] qword
$01226925 mov [rsi] qword, rbx
$01226928 pop rbx
$01226929 lea rsi, [rsi #-16 +] qword
$0122692D mov [rsi] qword, rbx
$01226930 cmp [rsi] qword, 0 b#
$01226934 je $0122695B offset NEAR
$0122693A mov rax, [rsi] qword
$0122693D lea rbx, [rax -1 +] qword
$01226941 push rbx
$01226942 push [rsi #16 +] qword
$01226945 lea rbp, [rbp -8 +] qword
$01226949 mov [rbp 0 +] qword, $01226956 d#
$01226951 jmp }ack+10 ( $0122690A ) offset NEAR
$01226956 jmp $01226963 offset NEAR
$0122695B mov rbx, 1 d#
$01226962 push rbx
$01226963 mov rax, [rsi #16 +] qword
$01226967 lea rbx, [rax -1 +] qword
$0122696B push rbx
$0122696C lea rbp, [rbp -8 +] qword
$01226970 mov [rbp 0 +] qword, $0122697D d#
$01226978 jmp }ack+10 ( $0122690A ) offset NEAR
$0122697D add rsi, #32 b#
$01226981 ;
*)
ENDDOC
-- combsort -----------------
#1000000 =: MAXSIZE
MAXSIZE CELLS ALLOCATE ?ALLOCATE =: _array
: []Q ( ix -- addr ) _array []CELL ;
: /1.3 ( n -- n ) #10 #13 */ 1 MAX ;
: XCHANGE ( addr1 addr2 -- ) 2DUP @ SWAP @ ROT ! SWAP ! ;
: DESC-COMBSORT ( -- )
MAXSIZE DUP 0 LOCALS| sflag items gap |
BEGIN
gap /1.3 TO gap
1 TO sflag
items gap -
0 DO
I gap + []Q @ I []Q @
> IF I gap + []Q I []Q XCHANGE
0 TO sflag
THEN
LOOP
sflag gap 1 = AND
UNTIL ;
DOC
(*
FORTH> see DESC-COMBSORT
Flags: ANSI
$01228800 : DESC-COMBSORT
$0122880A push $000F4240 d#
$0122880F mov rcx, $000F4240 d#
$01228816 xor rbx, rbx
$01228819 lea rsi, [rsi #-16 +] qword
$0122881D mov [rsi] qword, rbx
$01228820 mov rbx, rcx
$01228823 lea rsi, [rsi #-16 +] qword
$01228827 mov [rsi] qword, rbx
$0122882A pop rbx
$0122882B lea rsi, [rsi #-16 +] qword
$0122882F mov [rsi] qword, rbx
$01228832 pop rbx
$01228833 lea rax, [rax 0 +] qword
$01228838 push rbx
$01228839 push [rsi] qword
$0122883B mov rcx, #10 d#
$01228842 mov rbx, #13 d#
$01228849 pop rax
$0122884A imul rcx
$0122884D idiv rbx
$01228850 mov rbx, rax
$01228853 push rbx
$01228854 mov rbx, 1 d#
$0122885B pop rcx
$0122885C cmp rbx, rcx
$0122885F cmovl rbx, rcx
$01228863 mov [rsi] qword, rbx
$01228866 mov [rsi #32 +] qword, 1 d#
$0122886E mov rbx, [rsi #16 +] qword
$01228872 sub rbx, [rsi] qword
$01228875 push rbx
$01228876 xor rbx, rbx
$01228879 pop rcx
$0122887A call (DO) offset NEAR
$01228884 lea rax, [rax 0 +] qword
$01228888 mov rdi, [rbp 0 +] qword
$0122888C add rdi, [rsi] qword
$0122888F mov rax, [rbp 0 +] qword
$01228893 mov rcx, [rdi*8 $0B380050 +] qword
$0122889B cmp rcx, [rax*8 $0B380050 +] qword
$012288A3 jle $012288DC offset NEAR
$012288A9 mov rdi, [rbp 0 +] qword
$012288AD add rdi, [rsi] qword
$012288B0 mov rax, [rbp 0 +] qword
$012288B4 mov rdx, [rax*8 $0B380050 +] qword
$012288BC mov r9, [rdi*8 $0B380050 +] qword
$012288C4 mov [rax*8 $0B380050 +] qword, r9
$012288CC mov [rdi*8 $0B380050 +] qword, rdx
$012288D4 mov [rsi #32 +] qword, 0 d#
$012288DC add [rbp 0 +] qword, 1 b#
$012288E1 add [rbp 8 +] qword, 1 b#
$012288E6 jno $01228888 offset NEAR
$012288EC add rbp, #24 b#
$012288F0 cmp [rsi] qword, 1 b#
$012288F4 sete cl
$012288F8 movzx rcx, cl
$012288FC neg rcx
$012288FF and rcx, [rsi #32 +] qword
$01228903 cmp rcx, 0 b#
$01228907 je $01228838 offset NEAR
$0122890D push rbx
$0122890E add rsi, #48 b#
$01228912 ;
*)
ENDDOC
( takeuchi benchmark )
: tak ( z y x -- t )
2DUP >= IF 2DROP EXIT ENDIF
LOCALS| x y z |
z y x 1- RECURSE >R
x z y 1- RECURSE >R
y x z 1- RECURSE R> R> RECURSE ;
DOC
(*
FORTH> see tak
Flags: ANSI
$01228940 : tak
$0122894A pop rbx
$0122894B pop rdi
$0122894C cmp rbx, rdi
$0122894F push rdi
$01228950 jg $0122895D offset NEAR
$01228956 pop rdi
$01228957 jmp $01228A07 offset NEAR
$0122895C pop rbx
$0122895D lea rsi, [rsi #-16 +] qword
$01228961 mov [rsi] qword, rbx
$01228964 pop rbx
$01228965 lea rsi, [rsi #-16 +] qword
$01228969 mov [rsi] qword, rbx
$0122896C pop rbx
$0122896D lea rsi, [rsi #-16 +] qword
$01228971 mov [rsi] qword, rbx
$01228974 mov rax, [rsi #32 +] qword
$01228978 push [rsi] qword
$0122897A push [rsi #16 +] qword
$0122897D lea rbx, [rax -1 +] qword
$01228981 lea rbp, [rbp -8 +] qword
$01228985 mov [rbp 0 +] qword, $01228992 d#
$0122898D jmp $0122894B offset NEAR
$01228992 pop rbx
$01228993 mov rax, [rsi #16 +] qword
$01228997 lea rbp, [rbp -8 +] qword
$0122899B mov [rbp 0 +] qword, rbx
$0122899F push [rsi #32 +] qword
$012289A2 push [rsi] qword
$012289A4 lea rbx, [rax -1 +] qword
$012289A8 lea rbp, [rbp -8 +] qword
$012289AC mov [rbp 0 +] qword, $012289B9 d#
$012289B4 jmp $0122894B offset NEAR
$012289B9 pop rbx
$012289BA mov rax, [rsi] qword
$012289BD lea rbp, [rbp -8 +] qword
$012289C1 mov [rbp 0 +] qword, rbx
$012289C5 push [rsi #16 +] qword
$012289C8 push [rsi #32 +] qword
$012289CB lea rbx, [rax -1 +] qword
$012289CF lea rbp, [rbp -8 +] qword
$012289D3 mov [rbp 0 +] qword, $012289E0 d#
$012289DB jmp $0122894B offset NEAR
$012289E0 mov rbx, [rbp 0 +] qword
$012289E4 lea rbp, [rbp 8 +] qword
$012289E8 mov rdi, [rbp 0 +] qword
$012289EC lea rbp, [rbp 8 +] qword
$012289F0 push rbx
$012289F1 push rdi
$012289F2 lea rbp, [rbp -8 +] qword
$012289F6 mov [rbp 0 +] qword, $01228A03 d#
$012289FE jmp tak+10 ( $0122894A ) offset NEAR
$01228A03 add rsi, #48 b#
$01228A07 ;
*)
ENDDOC
: { ;
: }fack RECURSIVE ( F: t s -- n )
FDUP F0= IF F2DROP 1e EXIT ENDIF
FLOCALS| s t |
{ t IF { t 1- s }fack ELSE 1e ENDIF
s F1-
}fack ;
DOC
(*
FORTH> see }fack
Flags: ANSI
$01226700 : }fack
$0122670A fld ST(0)
$0122670C fld $011BCAA0 tbyte-offset
$01226712 fcompp
$01226714 fnstsw ax
$01226716 shr rax, 8 b#
$0122671A test al, #68 b#
$0122671D mov rbx, rax
$01226720 jp $01226753 offset NEAR
$01226726 fpop,
$01226730 ffreep ST(0)
$01226732 fpop,
$0122673C ffreep ST(0)
$0122673E fld $011BCA90 tbyte-offset
$01226744 fpush,
$0122674E jmp $012267EF offset NEAR
$01226753 fpop,
$0122675D sub rsi, #16 b#
$01226761 fstp [rsi] tbyte
$01226763 fpop,
$0122676D sub rsi, #16 b#
$01226771 fstp [rsi] tbyte
$01226773 fld [rsi] tbyte
$01226775 pop rbx
$01226776 cmp rbx, 0 b#
$0122677A je $012267B3 offset NEAR
$01226780 fld [rsi] tbyte
$01226782 pop rbx
$01226783 fld [rsi #16 +] tbyte
$01226786 lea r13, [r13 #-48 +] qword
$0122678A fxch ST(3)
$0122678C fstp [r13 #32 +] tbyte
$01226790 fstp [r13 0 +] tbyte
$01226794 fstp [r13 #16 +] tbyte
$01226798 lea rbx, [rbx -1 +] qword
$0122679C push rbx
$0122679D lea rbp, [rbp -8 +] qword
$012267A1 mov [rbp 0 +] qword, $012267AE d#
$012267A9 jmp }fack+10 ( $0122670A ) offset NEAR
$012267AE jmp $012267C7 offset NEAR
$012267B3 fld $011BCA80 tbyte-offset
$012267B9 lea r13, [r13 #-32 +] qword
$012267BD fxch ST(2)
$012267BF fstp [r13 #16 +] tbyte
$012267C3 fstp [r13 0 +] tbyte
$012267C7 fld [rsi #16 +] tbyte
$012267CA fsub $01112C20 float-offset
$012267D0 fpush,
$012267DA lea rbp, [rbp -8 +] qword
$012267DE mov [rbp 0 +] qword, $012267EB d#
$012267E6 jmp }fack+10 ( $0122670A ) offset NEAR
$012267EB add rsi, #32 b#
$012267EF ;
*)
ENDDOC
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-21 12:59 +0000 |
| Message-ID | <2014Sep21.145936@mips.complang.tuwien.ac.at> |
| In reply to | #33444 |
mhx@iae.nl writes:
>Like Stephen, I have noticed that even quite good looking locals code
>can be a surprisingly large amount slower than equivalent but much
>busier stack code. It's on my list to find out the hardware reasons
>for this. Floating-point code has no problems in this respect.
>
>iForth 64-bit has not benefitted at all from having 16 registers to
>play with. Again I suspect hardware reasons, and I hope that these
>problems may disappear with successive processor upgrades.
>With 32 registers I would of course use some of them to hold locals
>because it stands to reason that slow memory access to stacks
>is responsible for the currently slightly disappointing results.
Ah, ok, I thought that iForth is using registers for locals already,
but apparently it doesn't. In that case I am not surprised that using
locals is slower on iForth. And sure, using registers is faster than
using memory. I doubt that will change.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-19 12:05 +0000 |
| Message-ID | <2014Sep19.140551@mips.complang.tuwien.ac.at> |
| In reply to | #33424 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 9/18/14 1:33 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> Studies have indicated
>>> that there is measurable performance overhead in using locals.
>>
>> Which studies? Sure, most Forth systems currently don't implement
>> locals very efficiently, but on register machines that's just an
>> artifact of the implementation. A compiler can keep locals in
>> registers just as one can keep stack items in registers; and I believe
>> that iForth does that.
>
>Stephen reported a while back that one of his major customers rewrite an
>application that had used locals extensively, and it sped up
>significantly by minimizing locals use.
I can believe that, but that reflects more on VFX's locals
implementation than on locals themselves.
>FORTH, Inc. comparisons have
>been more limited, but there's at least the cost of setting up and
>taking down the locals frame.
That reflects on your locals implementation. Such a frame is not
required for implementing locals.
- 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 | Roelf Toxopeus <rt4all@notthis.hetnet.nl> |
|---|---|
| Date | 2014-09-21 07:44 +0200 |
| Message-ID | <541e65d5$0$9941$703f8584@textnews.kpn.nl> |
| In reply to | #33419 |
On 18/09/2014 13:33, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Studies have indicated >> that there is measurable performance overhead in using locals. > > Which studies? Sure, most Forth systems currently don't implement > locals very efficiently, but on register machines that's just an > artifact of the implementation. A compiler can keep locals in > registers just as one can keep stack items in registers; and I believe > that iForth does that. The PPC native Forth systems on the Mac like PowerMacForth and PowerMops used the nonvolatile registers r23 - r31 for locals. Certainly for PMF usage of locals could speed things up. Read REGISTERS| for LOCALS|. The PowerMops compiler was much more thouroughly and made minced meat of the stack dance. The volatile registers r3-r10 where used for cached stack cells. The usage of locals had less consequences wrt speed.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2014-09-17 11:10 +0200 |
| Message-ID | <lvbje9$f3s$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #33379 |
Dear Walter, for embedded usage, keep (nested) interrupts in mind. I am not sure if you have preemptive interrupts in your CPU. The $DEADBEEF approach under heavy interrupt load is a good test. Mecrisp-Stellaris on ARM Cortex has 64 cells for data stack and 64 cells for return stack for default. So far, this has been fine, but I can only join that it depends on application. I found this by experimentation, and I am not deep into stack depth theory. Perhaps a metric for recursive usage could be having a look on common recursive algorithms and look at your total memory available. How many recursion steps in a binary tree search algorithm would scan through all of your memory filled with data ? For more practical ideas, perhaps running the 1-Wire bus device discovery algorithm could give you hints. As you are designing a new CPU, I want to point you to the idea of having two "stack fill gauge interrupts" that trigger a few cells before overflow and underflow. This will allow you to use a fast hardware stack for casual usage and fall back to slightly slower memory to save or refill for extreme cases. Matthias
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2014-09-17 14:20 -0700 |
| Message-ID | <b98c7bf8-ce57-4c13-997e-e312a17c8363@googlegroups.com> |
| In reply to | #33379 |
On Tuesday, 16 September 2014 16:21:35 UTC+1, 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? Apart from Phil Koopman's book on stack machines, Chris Bailey's work at the University of Teesside and the University of York is relevant, especially if you want to run C well on a dual stack machine. Also see my articles Modern Forth and Extreme Forth in DDJ - I'm away at the moment so can't give you all the references directly. You will find that the "pure" dual stack machine is not a good target for C. Adding 2 to 4 registers and some deeper data stack access instructions improves code density and performance greatly. The numbers are in Chris Bailey's papers. Both the Teesside and the York UFO machines were projects part-sponsored by MPE. Feel free to contact me directly if you want to. Stephen
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-17 17:41 -0400 |
| Message-ID | <5419FFEE.27412D2C@bytecraft.com> |
| In reply to | #33405 |
stephen@mpeforth.com wrote: > On Tuesday, 16 September 2014 16:21:35 UTC+1, 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? > > Apart from Phil Koopman's book on stack machines, Chris Bailey's work at the > University of Teesside and the University of York is relevant, especially if you > want to run C well on a dual stack machine. Also see my articles Modern > Forth and Extreme Forth in DDJ - I'm away at the moment so can't give > you all the references directly. > > You will find that the "pure" dual stack machine is not a good target for C. > Adding 2 to 4 registers and some deeper data stack access instructions > improves code density and performance greatly. The numbers are in > Chris Bailey's papers. Both the Teesside and the York UFO machines > were projects part-sponsored by MPE. > > Feel free to contact me directly if you want to. > > Stephen I have Phil Koopman's book Thanks for the Chris Bailey's reference. 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. This is a travel week for me as well, but I will contact you when I am back w..
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-17 16:44 -0700 |
| Message-ID | <7x8ulhzuax.fsf@ruckus.brouhaha.com> |
| In reply to | #33409 |
Walter Banks <walter@bytecraft.com> writes: > I have Phil Koopman's book Thanks for the Chris Bailey's reference. You should also look at this old Yosefk post that gets a bad rap around here: http://yosefk.com/blog/my-history-with-forth-stack-machines.html
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-09-18 10:26 +0000 |
| Message-ID | <541ab362$0$6923$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #33412 |
In article <7x8ulhzuax.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >Walter Banks <walter@bytecraft.com> writes: >> I have Phil Koopman's book Thanks for the Chris Bailey's reference. > >You should also look at this old Yosefk post that gets a bad rap around >here: > >http://yosefk.com/blog/my-history-with-forth-stack-machines.html I've read it. It is a honest report of personal experiences. I recommend it, because one can learn something from it, if only by seeing the other perspective. 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 | Celeros <kerneels@gmail.com> |
|---|---|
| Date | 2014-09-19 00:12 +0200 |
| Message-ID | <JMydnevuEedexYbJnZ2dnUVZ8mednZ2d@saix.net> |
| In reply to | #33417 |
On 2014-09-18 12:26 PM, Albert van der Horst wrote: > In article <7x8ulhzuax.fsf@ruckus.brouhaha.com>, > Paul Rubin <no.email@nospam.invalid> wrote: >> Walter Banks <walter@bytecraft.com> writes: >>> I have Phil Koopman's book Thanks for the Chris Bailey's reference. >> >> You should also look at this old Yosefk post that gets a bad rap around >> here: >> >> http://yosefk.com/blog/my-history-with-forth-stack-machines.html > > I've read it. It is a honest report of personal experiences. > I recommend it, because one can learn something from it, if only > by seeing the other perspective. > > Groetjes Albert > 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. 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. 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! 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. But, for the purposes of the original, original question, if forth-like stack-based code is going to be auto generated with some other language as input: who knows what stack depth would be sufficient. Apologies if the above is utter nonsense :-) I'm more of a C# programmer interested in Forth because of it being such polar opposites. Regards, Kerneels
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-18 19:15 -0400 |
| Message-ID | <lvfp2t$82p$1@dont-email.me> |
| In reply to | #33425 |
On 9/18/2014 6:12 PM, Celeros wrote: > On 2014-09-18 12:26 PM, Albert van der Horst wrote: >> In article <7x8ulhzuax.fsf@ruckus.brouhaha.com>, >> Paul Rubin <no.email@nospam.invalid> wrote: >>> Walter Banks <walter@bytecraft.com> writes: >>>> I have Phil Koopman's book Thanks for the Chris Bailey's reference. >>> >>> You should also look at this old Yosefk post that gets a bad rap around >>> here: >>> >>> http://yosefk.com/blog/my-history-with-forth-stack-machines.html >> >> I've read it. It is a honest report of personal experiences. >> I recommend it, because one can learn something from it, if only >> by seeing the other perspective. >> >> Groetjes Albert >> > > 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. > > 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. Recursion can be written so it is linear in that it searches a space once cell at a time returning only after it has completed its search. But that is unusual and inefficient for other reasons than just stack depth. Often recursive algorithms are exploring a tree so that the depth of the tree is what sets the stack depth. I don't know the 8 Queens problem, but chess moves can only run to a depth of some dozen to 20 levels deep (not sure of the exact number these days). The ultimate limit is the computing power to complete the search in the lifetime of the researchers. So again, only some dozen levels of stack are needed. > 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! > > 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. But, for the purposes of > the original, original question, if forth-like stack-based code is going > to be auto generated with some other language as input: who knows what > stack depth would be sufficient. > > Apologies if the above is utter nonsense :-) > I'm more of a C# programmer interested in Forth because of it being such > polar opposites. No, this is not nonsense. But even with a language that uses the stack inefficiently, like C, the order of the problem doesn't change, just the constant multiplier I think. I think the more important point is that there are very few situations where the resources are in any way a limit to having an adequate stack. There may be a few situations where there is not much memory available, such as a $1 MCU or in an older FPGA. But that means every other aspect of your design is equally constrained and the stack is not the only thing you need to consider. Heck, the $35 rPi runs gForth with a huge stack compared to what 99.999% of programs need. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-18 17:14 -0700 |
| Message-ID | <3b660984-da2e-47f9-b4d8-415e9e536258@googlegroups.com> |
| In reply to | #33425 |
On Thursday, September 18, 2014 3:12:21 PM UTC-7, Kerneels Roos wrote:
> 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.
I have the N-Queens puzzle in my novice package:
http://www.forth.org/novice.html
All of my example programs involve recursion, except this one, which is ironic because it is a textbook example of recursion.
In my experience, parameter-stack usage is heaviest during compilation of a program, not when running the program (whether the program is recursive or not). The reason is that the ANS-Forth standard has a design flaw that allows code and data to be mixed. I have found that VFX does mix code and data, which is quite amazing to me --- I would have expected Stephen Pelc to understand that this will result in cache thrashing due to having data in a code-cache line and code in a data-cache line --- apparently not though!
The reason why this results in heavy stack usage at compile time, is that when you are comma'ing data into an array, you can't also do ENUM statements for the indices into the array along with each element. My workaround is to not comma the data into the array, but just leave it on the parameter stack. I will have a 0 sentinel underneath it. Afterward, I CREATE the array, and then I use this to comma in the data:
: non-zeros, ( 0 numbers... -- )
reverse-stack
begin ?dup while , repeat ;
If there are dozens of elements in the array, this means that there are dozens of data on the parameter-stack prior to NON-ZEROS, being executed. If those elements are structs (they usually are), then there may be hundreds of data on the parameter-stack.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2014-09-19 02:59 -0700 |
| Message-ID | <ad19d305-2d0a-4e73-84e5-bda52377cb07@googlegroups.com> |
| In reply to | #33428 |
On Friday, 19 September 2014 01:14:44 UTC+1, hughag...@yahoo.com wrote: >I have found that VFX does mix code and data, which is quite amazing to >me --- I would have expected Stephen Pelc to understand that this will >result in cache thrashing due to having data in a code-cache line and code >in a data-cache line --- apparently not though! It's discussed in the manual. However, we have learned that world-class super-hero programmers such as Hugh cannot be bothered to read manuals. For a clue, see the words +IDATA and -IDATA. Stephen
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-19 12:20 -0700 |
| Message-ID | <560eaa51-4dfc-4ff4-af5b-0831f3250620@googlegroups.com> |
| In reply to | #33432 |
On Friday, September 19, 2014 2:59:35 AM UTC-7, ste...@mpeforth.com wrote:
> On Friday, 19 September 2014 01:14:44 UTC+1, hughag...@yahoo.com wrote:
> >I have found that VFX does mix code and data, which is quite amazing to
> >me --- I would have expected Stephen Pelc to understand that this will
> >result in cache thrashing due to having data in a code-cache line and code
> >in a data-cache line --- apparently not though!
>
> It's discussed in the manual. However, we have learned that world-class
> super-hero programmers such as Hugh cannot be bothered to read manuals.
> For a clue, see the words +IDATA and -IDATA.
What you are describing in your manual is totally non-compliant with ANS-Forth, and it really plays havoc with any attempt at porting a program. I think that you are trying to trap me in writing vendor-specific code so that I will become a loyal customer of MPE. Similarly, when I pointed out that there is no way to take an xt and determine what word-list it was defined in, your solution involved code (>NAME) that is not ANS-Forth. Also, when I pointed out the problem with CREATE DOES> being inefficient because DOES> typically has to load values from memory at run-time that are immutable constants known at compile-time, you first said that CREATE DOES> doesn't have this problem, but you didn't provide any code --- when you finally provided code at my insistence, your code was not ANS-Forth (you have some non-standard directives that indicate when the data comma'd after CREATE is immutable). If you are going to abandon ANS-Forth, why not go whole hog?
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? --- and that is what you are trying to induce me to do by encouraging me to use VFX-specific work-arounds for the problems in ANS-Forth.
My novice package is full of work-arounds for the problems in ANS-Forth --- but my novice package is also fully ANS-Forth compliant.
Why are you so loyal to Elizabeth Rather? Why did you let her make SwiftForth become the ANS-Forth standard? You obviously know that ANS-Forth has serious problems, because you write non-standard work-arounds for these problems after the fact (such as +IDATA and -IDATA that you are promoting here). Why didn't you insist that these problems be fixed *BEFORE* they got written in stone in the ANS-Forth standard? What was the point of being on the ANS-Forth technical committee if you were just going to be a sheep and say "baaaa" every time that your shepherd Elizabeth Rather whacked you with her stick? What is the point of being on the Forth-200x technical committee now? Why not just totally abandon ANS-Forth and Forth-200x? I did.
Who the hell needs Forth Inc.???
Stop being Elizabeth Rather's follower. Be my follower instead.
My MFX was way beyond anything that you've ever written --- that was the work of a "world-class super-hero." ;-D
[toc] | [prev] | [next] | [standalone]
Page 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web