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 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-22 15:13 +0000 |
| Message-ID | <2014Sep22.171327@mips.complang.tuwien.ac.at> |
| In reply to | #33509 |
Walter Banks <walter@bytecraft.com> writes:
>Anton Ertl wrote:
>> Can stack allocation across basic blocks be done? Sure, but can we do
>> it well? I don't see a heuristic for choosing which variables to keep
>> on the stack where spring out at me. If viewed like register
>> allocation, this is like a very small register set with irregular
>> access rules; the usual register sets are not very good at this kind
>> of thing, despite decades of research and development; that's why
>> architectures intended to be used with compilers have settled for
>> larger, regular ("general-purpose") register sets.
>
>Many of the ISA designs have larger general purpose register sets
>so that they can use open source public domain compiler tools most
>of which are using old compiler technology. Non orthogonal and
>special purpose register sets can be supported with current compiler
>technology especially those using strategy passes that process the full
>application data and control structure to plan out the actual code
>implementation.
Are there any papers on that?
In any case, I doubt that, say, Intel or IBM are designing their
architectures for "open source public domain compiler tools most of
which are using old compiler technology". They have their own
compiler teams.
>> * Forth programmers use a wide variety of techniques for dealing with
>> the limitations of stack-based programming, often very specific to
>> the program at hand, and exploiting knowledge that the Algol
>> compiler does not have (because it's not expressed in the Algol
>> source code).
>
>Do you have an example of the kind information that would be useful?
Nothing from a real program at the moment, but information about
aliases or "don't care" behaviour is something that a compiler often
cannot know, and that could be helpful in reducing the stack load
(e.g., by moving memory accesses around).
>> * Studies of Forth programs have found fewer dynamic conditional
>> branches and far more calls and returns than instruction statistics
>> for e.g., C-compiler generated programs. E.g., compare the date from
>> <http://www.complang.tuwien.ac.at/anton/euroforth/ef01/gregg01.pdf> with
>
>> <http://eslab.cse.nsysu.edu.tw/publications/paper/conference/Analysis%20o
>
>> f%20x86%20Instruction%20Set%20Usage%20for%20DOS%20Windows%20
>
>> Applications%20and%20Its%20Implication%20on%20Superscalar%20Design.pdf
>
>What is the underlying reason for lower dynamic conditionals. Is it the
>higher overall cost for using them encouraging the use of branchless
>code?
One reason is probably that in Forth branchy code requires even more
mental effort than in other languages, because you have to keep track
of the stack depth and stack item arrangement, and make sure they
agree on control flow joins. Therefore Forth programmers tend to
avoid branching when they can.
By contrast, C programs introduce additional branches with
short-circuit evaluation.
>Do you know of any papers on code reliability in Forth applications given
>that functions don't have a formal interface? (The implication is the series
>terms in the system reliably are larger than say algol languages)
You lost me in the last sentence.
Paul Bennet has written about code reliability in connection with
Forth, and is going to present a paper on that at EuroForth.
- 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-22 13:58 -0400 |
| Message-ID | <5420632F.A458FAA@bytecraft.com> |
| In reply to | #33510 |
Anton Ertl wrote:
> Walter Banks <walter@bytecraft.com> writes:
> >Anton Ertl wrote:
> >> Can stack allocation across basic blocks be done? Sure, but can we do
> >> it well? I don't see a heuristic for choosing which variables to keep
> >> on the stack where spring out at me. If viewed like register
> >> allocation, this is like a very small register set with irregular
> >> access rules; the usual register sets are not very good at this kind
> >> of thing, despite decades of research and development; that's why
> >> architectures intended to be used with compilers have settled for
> >> larger, regular ("general-purpose") register sets.
> >
> >Many of the ISA designs have larger general purpose register sets
> >so that they can use open source public domain compiler tools most
> >of which are using old compiler technology. Non orthogonal and
> >special purpose register sets can be supported with current compiler
> >technology especially those using strategy passes that process the full
> >application data and control structure to plan out the actual code
> >implementation.
>
> Are there any papers on that?
It is pretty common approach in some of the embedded systems
compilers especially for no orthogonal instruction sets. I don't know
of any publication links.. It has shown up on some of the news groups
from time to time in discussion.
>
> In any case, I doubt that, say, Intel or IBM are designing their
> architectures for "open source public domain compiler tools most of
> which are using old compiler technology". They have their own
> compiler teams.
Both IBM and Intel use GCC GNU or llvm. They have their own
very capable compiler teams. There has been some instruction set
innovation but still very mainstream .
Some of the automotive and aerospace processors are very much
non orthogonal. Automotive engine controllers eTPU families for
example) have very different instruction sets.
> >> * Forth programmers use a wide variety of techniques for dealing with
> >> the limitations of stack-based programming, often very specific to
> >> the program at hand, and exploiting knowledge that the Algol
> >> compiler does not have (because it's not expressed in the Algol
> >> source code).
> >
> >Do you have an example of the kind information that would be useful?
>
> Nothing from a real program at the moment, but information about
> aliases or "don't care" behaviour is something that a compiler often
> cannot know, and that could be helpful in reducing the stack load
> (e.g., by moving memory accesses around).
>
> >> * Studies of Forth programs have found fewer dynamic conditional
> >> branches and far more calls and returns than instruction statistics
> >> for e.g., C-compiler generated programs. E.g., compare the date from
> >> <http://www.complang.tuwien.ac.at/anton/euroforth/ef01/gregg01.pdf> with
> >
> >> <http://eslab.cse.nsysu.edu.tw/publications/paper/conference/Analysis%20o
> >
> >> f%20x86%20Instruction%20Set%20Usage%20for%20DOS%20Windows%20
> >
> >> Applications%20and%20Its%20Implication%20on%20Superscalar%20Design.pdf
> >
> >What is the underlying reason for lower dynamic conditionals. Is it the
> >higher overall cost for using them encouraging the use of branchless
> >code?
>
> One reason is probably that in Forth branchy code requires even more
> mental effort than in other languages, because you have to keep track
> of the stack depth and stack item arrangement, and make sure they
> agree on control flow joins. Therefore Forth programmers tend to
> avoid branching when they can.
>
> By contrast, C programs introduce additional branches with
> short-circuit evaluation.
>
> >Do you know of any papers on code reliability in Forth applications given
> >that functions don't have a formal interface? (The implication is the series
> >terms in the system reliably are larger than say algol languages)
>
> You lost me in the last sentence.
If you take normal reliability math and apply it to code and make
some assumption about instruction reliability and then analyse the
code you will result in a dimensionless number that can be used to
compare two implementations and it will reliably (pun:) identify
which implementation is more reliable. My experience doing this
has been that the results are consistent independent which assumption
is made about instruction reliability. The three most common
assumptions we have made has been each instruction has a
reliability of 1, reliability is equal to 1/cycles or 1/instruction_size.
Parallel terms occur when there are independent paths that
contribute to the overall result.
Series terms are broken by a clean clear entrance and exit
interface where one block may be replaced with a block
having the same interface and the results are unchanged.
What I was referring to was the lack of the component interface
and that generally increases the probability of failure.
The result is a dimensionless number but it can be computed
automatically. (We have done it from machine code so that
even the code generated tools do not need to be changed.)
The data structure of an application is similar to McCabe's
Cyclomatic Complexity.
w..
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-22 11:13 -1000 |
| Message-ID | <_OWdnfIBlttBDb3JnZ2dnUU7-QOdnZ2d@supernews.com> |
| In reply to | #33509 |
On 9/22/14 4:54 AM, Walter Banks wrote: > Anton Ertl wrote: >> Walter Banks <walter@bytecraft.com> writes: ... >> >You made a comment, "behave like hand-written Forth?" I think that >> >this is more than an off hand comment. What makes hand-written >> >forth special? and why? >> >> Many different things, in particular: >> >> * Shorter definitions than your typical Algol-family language program, >> because it's easier to add definitions, and harder to make them long >> than in Algol. >> > This can have a real impact on code size. We did a study on C optimization > and found that even bad C compilers generated reasonably good code > if the source statements were kept short. Yes. Forth takes this to an extreme, with many definitions in a typical application being 3 lines or less. The cost of calling a word in Forth is far less than in languages that manage calling sequences, because of the stack. In ITC implementations it could be as few as a couple of machine instructions each for call/return, and in modern implementations it's just call/return. Forth newbies often say, "but you have to put your arguments on the stack," but in practice there's relatively little fetching/storing, intermediate values are just *there*, passed through whatever procedures are necessary. This is one reason so many Forthwrites are down on locals. >> * Forth programmers use a wide variety of techniques for dealing with >> the limitations of stack-based programming, often very specific to >> the program at hand, and exploiting knowledge that the Algol >> compiler does not have (because it's not expressed in the Algol >> source code). > Do you have an example of the kind information that would be useful? > I think you are correct but am having a hard time coming up with an > example. I find myself a little put off by "limitations of stack-based programming." I've never found it "limiting", it's just a very different programming paradigm. >> * Studies of Forth programs have found fewer dynamic conditional >> branches and far more calls and returns than instruction statistics >> for e.g., C-compiler generated programs. E.g., compare the date from [ links snipped ] > What is the underlying reason for lower dynamic conditionals. Is it the > higher overall cost for using them encouraging the use of branchless > code? Fascinating issue. Chuck and I wrote a paper on this for an ACM (I think) conference back in the 70's. I wish I could find a copy! We were asked to rewrite a PDP-11 control application from Fortran to Forth. They were having terrible performance issues, largely due to the fact that the program was too large for the 64K memory limit in those days, and the DEC OS was doing a lot of page swapping. Our main constraint was that the behavior of our version (including the user interface) had to be identical. Our program ran is well under 64K, so no page swapping, and was an order of magnitude faster. But one of the comparisons that we focused on in the paper was that the Fortran program had nearly 400 IF statements, and the Forth version had 7. That's right, seven. There was a vector of addresses, the selection offset being calculated from a switch reading (no IF there), and multiple tasks responding to different parts of the machine. But the main difference was that the Fortran style was large subroutines that took indicators as to which path to take through, and the Forth version had just tiny words that did what they did without having to figure out what they were supposed to do. > The higher call / return metrics is understandable with the macro language > origins of Forth. > > Do you know of any papers on code reliability in Forth applications given > that functions don't have a formal interface? (The implication is the > series terms in the system reliably are larger than say algol languages) I don't understand what "don't have a formal interface" means. All Forth words have very specific expectations as to the arguments they expect and leave. 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 | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-22 21:59 -0400 |
| Message-ID | <5420D3F7.FCFBD0F9@bytecraft.com> |
| In reply to | #33516 |
"Elizabeth D. Rather" wrote: > On 9/22/14 4:54 AM, Walter Banks wrote: > > Anton Ertl wrote: > >> Walter Banks <walter@bytecraft.com> writes: > ... > >> >You made a comment, "behave like hand-written Forth?" I think that > >> >this is more than an off hand comment. What makes hand-written > >> >forth special? and why? > >> > >> Many different things, in particular: > >> > >> * Shorter definitions than your typical Algol-family language program, > >> because it's easier to add definitions, and harder to make them long > >> than in Algol. > >> > > This can have a real impact on code size. We did a study on C optimization > > and found that even bad C compilers generated reasonably good code > > if the source statements were kept short. > > Yes. Forth takes this to an extreme, with many definitions in a typical > application being 3 lines or less. The cost of calling a word in Forth > is far less than in languages that manage calling sequences, because of > the stack. In ITC implementations it could be as few as a couple of > machine instructions each for call/return, and in modern implementations > it's just call/return. Forth newbies often say, "but you have to put > your arguments on the stack," but in practice there's relatively little > fetching/storing, intermediate values are just *there*, passed through > whatever procedures are necessary. This is one reason so many > Forthwrites are down on locals. > > >> * Forth programmers use a wide variety of techniques for dealing with > >> the limitations of stack-based programming, often very specific to > >> the program at hand, and exploiting knowledge that the Algol > >> compiler does not have (because it's not expressed in the Algol > >> source code). > > Do you have an example of the kind information that would be useful? > > I think you are correct but am having a hard time coming up with an > > example. > > I find myself a little put off by "limitations of stack-based > programming." I've never found it "limiting", it's just a very different > programming paradigm. > > >> * Studies of Forth programs have found fewer dynamic conditional > >> branches and far more calls and returns than instruction statistics > >> for e.g., C-compiler generated programs. E.g., compare the date from > [ links snipped ] > > > What is the underlying reason for lower dynamic conditionals. Is it the > > higher overall cost for using them encouraging the use of branchless > > code? > > Fascinating issue. Chuck and I wrote a paper on this for an ACM (I > think) conference back in the 70's. I wish I could find a copy! We were > asked to rewrite a PDP-11 control application from Fortran to Forth. > They were having terrible performance issues, largely due to the fact > that the program was too large for the 64K memory limit in those days, > and the DEC OS was doing a lot of page swapping. Our main constraint was > that the behavior of our version (including the user interface) had to > be identical. Our program ran is well under 64K, so no page swapping, > and was an order of magnitude faster. But one of the comparisons that we > focused on in the paper was that the Fortran program had nearly 400 IF > statements, and the Forth version had 7. That's right, seven. There was > a vector of addresses, the selection offset being calculated from a > switch reading (no IF there), and multiple tasks responding to different > parts of the machine. But the main difference was that the Fortran style > was large subroutines that took indicators as to which path to take > through, and the Forth version had just tiny words that did what they > did without having to figure out what they were supposed to do. > > > The higher call / return metrics is understandable with the macro language > > origins of Forth. > > > > Do you know of any papers on code reliability in Forth applications given > > that functions don't have a formal interface? (The implication is the > > series terms in the system reliably are larger than say algol languages) > > I don't understand what "don't have a formal interface" means. All Forth > words have very specific expectations as to the arguments they expect > and leave. Not to digress to far but the difference between Forth and many other languages is the interface to words is not independently enforced. The effect is the series effects of sequential words. I once did a lot of work making real time applications work reliably, a lot of it was simply segmenting code into well defined pieces and restructuring applications to improve the reliability numbers of the application. This is the stuff of heated discussions. Interesting numbers on your PDP 11 app It suggests the real cost of conditionals. w..
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-22 16:57 -1000 |
| Message-ID | <otqdnRc41L8_fL3JnZ2dnUU7-dOdnZ2d@supernews.com> |
| In reply to | #33517 |
On 9/22/14 3:59 PM, Walter Banks wrote: > "Elizabeth D. Rather" wrote: > >> On 9/22/14 4:54 AM, Walter Banks wrote: ... >>> What is the underlying reason for lower dynamic conditionals. Is it the >>> higher overall cost for using them encouraging the use of branchless >>> code? >> >> Fascinating issue. Chuck and I wrote a paper on this for an ACM (I >> think) conference back in the 70's. I wish I could find a copy! We were >> asked to rewrite a PDP-11 control application from Fortran to Forth. >> They were having terrible performance issues, largely due to the fact >> that the program was too large for the 64K memory limit in those days, >> and the DEC OS was doing a lot of page swapping. Our main constraint was >> that the behavior of our version (including the user interface) had to >> be identical. Our program ran is well under 64K, so no page swapping, >> and was an order of magnitude faster. But one of the comparisons that we >> focused on in the paper was that the Fortran program had nearly 400 IF >> statements, and the Forth version had 7. That's right, seven. There was >> a vector of addresses, the selection offset being calculated from a >> switch reading (no IF there), and multiple tasks responding to different >> parts of the machine. But the main difference was that the Fortran style >> was large subroutines that took indicators as to which path to take >> through, and the Forth version had just tiny words that did what they >> did without having to figure out what they were supposed to do. >> >>> The higher call / return metrics is understandable with the macro language >>> origins of Forth. >>> >>> Do you know of any papers on code reliability in Forth applications given >>> that functions don't have a formal interface? (The implication is the >>> series terms in the system reliably are larger than say algol languages) >> >> I don't understand what "don't have a formal interface" means. All Forth >> words have very specific expectations as to the arguments they expect >> and leave. > > Not to digress to far but the difference between Forth and many other > languages is the interface to words is not independently enforced. The > effect is the series effects of sequential words. I once did a lot of work > making real time applications work reliably, a lot of it was simply > segmenting code into well defined pieces and restructuring applications > to improve the reliability numbers of the application. This is the stuff > of heated discussions. Yes, much depends on good application design and structure. I entirely agree with that. I'm still not clear as to what you mean by "independently enforced." Error checking is extremely important for reliable applications, but the correct place to do the checking is where data enters the system, and is most effectively done as a component of the application design. I have never seen any proof that things like data type checking at the compiler level is actually helpful. > Interesting numbers on your PDP 11 app It suggests the real cost > of conditionals. The number of conditionals is far from the whole story in the reduced memory size. A major factor is code density: Forth's many tiny, reusable definitions avoids vast numbers of repeated code sequences, for extremely high code density. Use of the stack and shared memory regions minimizes allocated data space. Etc. There's a whole host of reasons why Forth programs are way smaller than Fortran or C programs. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-23 00:59 -0400 |
| Message-ID | <lvquo9$1m9$1@dont-email.me> |
| In reply to | #33518 |
On 9/22/2014 10:57 PM, Elizabeth D. Rather wrote: > I have never seen any proof that things like > data type checking at the compiler level is actually helpful. If you want to talk about "proof" then let's find some proof about the claims people make about Forth. Sure, there is anecdotal evidence, but that is not proof. The fact that a problem in a C application was fixed by rewriting it as a Forth application doesn't mean there is inherently anything better about Forth. There are far too many variables to assign the results to any one. What manner of proof would you consider for the data type checking? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-22 19:53 -1000 |
| Message-ID | <SLKdnYBFVtl4l7zJnZ2dnUU7-ImdnZ2d@supernews.com> |
| In reply to | #33520 |
On 9/22/14 6:59 PM, rickman wrote: > On 9/22/2014 10:57 PM, Elizabeth D. Rather wrote: >> I have never seen any proof that things like >> data type checking at the compiler level is actually helpful. > > If you want to talk about "proof" then let's find some proof about the > claims people make about Forth. Sure, there is anecdotal evidence, but > that is not proof. The fact that a problem in a C application was fixed > by rewriting it as a Forth application doesn't mean there is inherently > anything better about Forth. There are far too many variables to assign > the results to any one. > > What manner of proof would you consider for the data type checking? Well, the comparison I was citing was a Fortran program, not C, though we have written parallel programs against C many times, too. I wrote a lot of Fortran programs back in the day, and was actively writing Forth applications for almost 15 years, and project managing after that. I know that Fortran compilers drove me nuts with error messages, but I don't remember many Forth errors (mine or anyone else's) that would have been caught by a type-checking compiler. So, I'm mostly speaking from experience. I have offered many times to support any Computer Science comparative study that would generate some academically respectable proof, though. 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-23 03:48 -0500 |
| Message-ID | <LIWdneZ2GsJCrrzJnZ2dnUU7-KednZ2d@supernews.com> |
| In reply to | #33522 |
Elizabeth D. Rather <erather@forth.com> wrote: > On 9/22/14 6:59 PM, rickman wrote: >> On 9/22/2014 10:57 PM, Elizabeth D. Rather wrote: >>> I have never seen any proof that things like >>> data type checking at the compiler level is actually helpful. >> >> If you want to talk about "proof" then let's find some proof about the >> claims people make about Forth. Sure, there is anecdotal evidence, but >> that is not proof. The fact that a problem in a C application was fixed >> by rewriting it as a Forth application doesn't mean there is inherently >> anything better about Forth. There are far too many variables to assign >> the results to any one. >> >> What manner of proof would you consider for the data type checking? > > Well, the comparison I was citing was a Fortran program, not C, though > we have written parallel programs against C many times, too. > > I wrote a lot of Fortran programs back in the day, and was actively > writing Forth applications for almost 15 years, and project managing > after that. I know that Fortran compilers drove me nuts with error > messages, but I don't remember many Forth errors (mine or anyone > else's) that would have been caught by a type-checking compiler. So, > I'm mostly speaking from experience. > > I have offered many times to support any Computer Science > comparative study that would generate some academically respectable > proof, though. I've worked in both worlds, and my experience is similar to yours. I'm wondering if people working with strictly type-checked languages come to depend on that type checking, so that maybe they don't think about such errors because "the compiler will detect them". Certainly most of the bugs I've had to fix were conceptual ones: algorithmic mistakes rather than treating a float as a pointer or somesuch. On the other hand, it is a relief to know that some kinds of errors (e.g. wandering of the end of an array) are impossible. Maybe programmers shouldn't always have to think about such stuff... :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-23 16:01 +0000 |
| Message-ID | <2014Sep23.180149@mips.complang.tuwien.ac.at> |
| In reply to | #33524 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I'm wondering if people working with strictly type-checked languages
>come to depend on that type checking, so that maybe they don't think
>about such errors because "the compiler will detect them".
That's certainly what Bjarne Stroustroup (a type-checking fan)
observed:
|As programmers learned C with Classes or C++, they lost the ability to
|quickly find the ``silly errors'' that creep into C programs through
|the lack of checking. Further, they failed to take the precautions
|against such silly errors that good C programmers take as a matter of
|course. After all, ``such errors don't happen in C with Classes.''
|Thus, as the frequency of run-time errors caused by uncaught argument
|type errors goes down, their seriousness and the time needed to find
|them goes up.
Bjarne Stroustroup in the HOPL-II paper on C++.
- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-23 08:07 -1000 |
| Message-ID | <Tt6dndFJvf55K7zJnZ2dnUU7-TOdnZ2d@supernews.com> |
| In reply to | #33530 |
On 9/23/14 6:01 AM, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> I'm wondering if people working with strictly type-checked languages >> come to depend on that type checking, so that maybe they don't think >> about such errors because "the compiler will detect them". > > That's certainly what Bjarne Stroustroup (a type-checking fan) > observed: > > |As programmers learned C with Classes or C++, they lost the ability to > |quickly find the ``silly errors'' that creep into C programs through > |the lack of checking. Further, they failed to take the precautions > |against such silly errors that good C programmers take as a matter of > |course. After all, ``such errors don't happen in C with Classes.'' > |Thus, as the frequency of run-time errors caused by uncaught argument > |type errors goes down, their seriousness and the time needed to find > |them goes up. > > Bjarne Stroustroup in the HOPL-II paper on C++. A number of years ago we developed a Forth to use in courses that checked all kinds of things: inappropriate fetch/store operators, bounds on arrays, incomplete structures, illegal addresses, etc. It was a lot of work, but a fun project. As a teaching tool, it was useless, though. Students still called the instructor over to help figure out what was wrong. Instructor would say, "See that message?" and the student would say, "Oh, yeah, I'm getting a lot of messages, but I just ignore them. Why doesn't this work?" 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 E Bennett <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2014-09-23 22:11 +0100 |
| Message-ID | <c8e60pFd823U1@mid.individual.net> |
| In reply to | #33533 |
Elizabeth D. Rather wrote: [%X] > A number of years ago we developed a Forth to use in courses that > checked all kinds of things: inappropriate fetch/store operators, bounds > on arrays, incomplete structures, illegal addresses, etc. It was a lot > of work, but a fun project. As a teaching tool, it was useless, though. > Students still called the instructor over to help figure out what was > wrong. Instructor would say, "See that message?" and the student would > say, "Oh, yeah, I'm getting a lot of messages, but I just ignore them. > Why doesn't this work?" For those that follow such bloggings, we have heard from Jack Ganssle, Phil Koopman and Chris Hills that the one thing you do not do is ignore warnings and error messages. These warnings and error messages should all be investigated and eliminated, usually by changing your code to behave properly. To programme properly, one has to learn to observe and see the failings of ones own codings. Forth helps enforce the self-discipline needed but remains an amplifier of the programmers skills (good or bad). -- ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-23 16:22 -0500 |
| Message-ID | <zdKdndVvA_cxebzJnZ2dnUU7-aednZ2d@supernews.com> |
| In reply to | #33536 |
Paul E Bennett <Paul_E.Bennett@topmail.co.uk> wrote: > For those that follow such bloggings, we have heard from Jack > Ganssle, Phil Koopman and Chris Hills that the one thing you do not > do is ignore warnings and error messages. These warnings and error > messages should all be investigated and eliminated, usually by > changing your code to behave properly. Well, yes, but you're rather assuming that the warning is appropriate. I have seen code broken by fixing warnings, and I have seen warnings on correct and reasonable code. In addition, some style warnings aren't inteneded by their authors to be turned on for every project. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-23 11:28 -1000 |
| Message-ID | <GcqdnQOGppmPe7zJnZ2dnUU7-bmdnZ2d@supernews.com> |
| In reply to | #33536 |
On 9/23/14 11:11 AM, Paul E Bennett wrote: > Elizabeth D. Rather wrote: > > [%X] > >> A number of years ago we developed a Forth to use in courses that >> checked all kinds of things: inappropriate fetch/store operators, bounds >> on arrays, incomplete structures, illegal addresses, etc. It was a lot >> of work, but a fun project. As a teaching tool, it was useless, though. >> Students still called the instructor over to help figure out what was >> wrong. Instructor would say, "See that message?" and the student would >> say, "Oh, yeah, I'm getting a lot of messages, but I just ignore them. >> Why doesn't this work?" > > For those that follow such bloggings, we have heard from Jack Ganssle, Phil > Koopman and Chris Hills that the one thing you do not do is ignore warnings > and error messages. These warnings and error messages should all be > investigated and eliminated, usually by changing your code to behave > properly. > > To programme properly, one has to learn to observe and see the failings of > ones own codings. Forth helps enforce the self-discipline needed but remains > an amplifier of the programmers skills (good or bad). > Of course! But, the point is that many compilers (and I'm thinking of the Fortran compilers I used to hate) issue so many error messages, a lot of them spurious (or side effects of an initial actual error) that programmers get desensitized. It's like the boy who cried, "Wolf!" Virtually all Forths will tell you about undefined words (which Fortran does not!), about stack underflows detected at the user interface, and incomplete structures (easily identifiable by the simple act of checking the stack after compiling stuff), and some do a lot more. There are a lot of useful things a Forth compiler can do for you, but type checking just isn't as valuable as a lot of people think. 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-09-24 11:56 +0000 |
| Message-ID | <5422b163$0$15834$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #33536 |
In article <c8e60pFd823U1@mid.individual.net>,
Paul E Bennett <Paul_E.Bennett@topmail.co.uk> wrote:
>Elizabeth D. Rather wrote:
>
>[%X]
>
>> A number of years ago we developed a Forth to use in courses that
>> checked all kinds of things: inappropriate fetch/store operators, bounds
>> on arrays, incomplete structures, illegal addresses, etc. It was a lot
>> of work, but a fun project. As a teaching tool, it was useless, though.
>> Students still called the instructor over to help figure out what was
>> wrong. Instructor would say, "See that message?" and the student would
>> say, "Oh, yeah, I'm getting a lot of messages, but I just ignore them.
>> Why doesn't this work?"
>
>For those that follow such bloggings, we have heard from Jack Ganssle, Phil
>Koopman and Chris Hills that the one thing you do not do is ignore warnings
>and error messages. These warnings and error messages should all be
>investigated and eliminated, usually by changing your code to behave
>properly.
I'm all with you, but there is a catch. Some employers wants to run the
code without warnings and the employees duely comply.
Now suppose we have the following in C:
"
int a;
long int b;
...
a = b;
"
The compiler gives the warning:
possible loss of precision
(which should be : possible run time overflow error)
This code is mine, and it is perfectly ligit. I needed a larger intermediate
result.
Now those douche back's are going to change that into
a = (int) b;
so that helpfully the next generation of programmers doesn't realize
there is a potential problem.
The (int) says: "compiler shut up. I know better."
But they don't know better, they just shoot the messenger.
So instead I would have the rules:
casts in c are not allowed. Exceptions must be run by the Senior Programmer
(that's me).
Warnings must be collected. A separate document explains why the code gives those.
Regression tests are run against those warning files.
(And I'm all for error numbers, and also warning numbers. If an error changes so
does its number. A message is a bad identification for an error, especially if
the compiler writer helpfully changes the message to a better understandable one,
or one that is less likely to get them into legal trouble.)
You'll see that the document with explanations is the first thing to read
when there are mysterious errors.
A a side effect I surmise that programmers will try to get rid of warnings
in the good way, to forego the trouble of documenting why the warning is
there.
Example of motivation:
b cannot overflow because x is in mm and cannot be larger than ca 5000
for a car. With an material modulus of bla bla .. precision of 32 bits
bla bla.
Now there is red light if x is going to be measured in nano meters.
(If you change a program part, then you better read the documentation
about warnings generated there about).
>
>To programme properly, one has to learn to observe and see the failings of
>ones own codings. Forth helps enforce the self-discipline needed but remains
>an amplifier of the programmers skills (good or bad).
Crashing is certainly the best way to enforce that a bug be fixed.
>
>--
>Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-24 13:52 -0700 |
| Message-ID | <905a62e7-20e8-4a3a-ac05-0a9f3ef2a903@googlegroups.com> |
| In reply to | #33541 |
On Wednesday, September 24, 2014 4:56:21 AM UTC-7, Albert van der Horst wrote: > I would have the rules: > casts in c are not allowed. Exceptions must be run by the Senior Programmer > (that's me). > > Warnings must be collected. A separate document explains why the code gives those. > Regression tests are run against those warning files. You have previously represented yourself as being a Wikipedia editor: https://groups.google.com/forum/#!topicsearchin/comp.lang.forth/lc53/comp.lang.forth/qqlp1gZnVic Now you represent yourself as being a Senior Programmer. These categories are mutually exclusive --- you can't be both a Wikipedia editor and a Senior Programmer --- Wikipedia editors are just trolls pretending to be experts on everything, whereas a Senior Programmer has to actually know something about programming. Also, I would appreciate it if you did not refer to programmers as "douche bags" on comp.lang.forth --- that is just disgusting --- go back to Wikipedia where you belong!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-24 17:00 -0400 |
| Message-ID | <lvvbee$5fp$2@dont-email.me> |
| In reply to | #33543 |
On 9/24/2014 4:52 PM, hughaguilar96@yahoo.com wrote: ...<snip>... I am ready to kill file this guy. Can someone tell me the easy way to do this in T-bird? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-24 17:04 -0400 |
| Message-ID | <lvvblb$9mn$1@dont-email.me> |
| In reply to | #33545 |
On 9/24/2014 5:00 PM, rickman wrote: > On 9/24/2014 4:52 PM, hughaguilar96@yahoo.com wrote: > > ....<snip>... > > I am ready to kill file this guy. Can someone tell me the easy way to > do this in T-bird? Never mind. I think I got it. Filters are pretty easy actually. No more Hugh... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2014-09-24 16:08 -0700 |
| Message-ID | <1ac64319-6c1f-487a-a50b-0d4f0ccf51c8@googlegroups.com> |
| In reply to | #33546 |
On Wednesday, September 24, 2014 2:04:45 PM UTC-7, rickman wrote: > > I am ready to kill file this guy. Can someone tell me the easy way to > do this in T-bird? > The best filter is the gray one sitting between your ears. I know him as "hughag..." because that's what Google groups does to his name. Once I filter out the vitriol and insults, there is almost always something of at least limited value remaining. Once in a great while, I find the remainder to be quite enlightening, and I don't simply ignore or discard it out of prejudice, as he himself would likely do. Mike
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-24 12:23 -1000 |
| Message-ID | <a-GdnY8Tofra2b7JnZ2dnUU7-XOdnZ2d@supernews.com> |
| In reply to | #33545 |
On 9/24/14 11:00 AM, rickman wrote: > On 9/24/2014 4:52 PM, hughaguilar96@yahoo.com wrote: > > ...<snip>... > > I am ready to kill file this guy. Can someone tell me the easy way to > do this in T-bird? > Tools > Message Filters > New Fill in name, select "From" and put a name or email. Easy and effective! Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-29 19:33 -0700 |
| Message-ID | <e67f01b6-06b4-49c6-bf3c-b7a05606065f@googlegroups.com> |
| In reply to | #33547 |
On Wednesday, September 24, 2014 3:23:05 PM UTC-7, Elizabeth D. Rather wrote: > On 9/24/14 11:00 AM, rickman wrote: > > On 9/24/2014 4:52 PM, hughaguilar96@yahoo.com wrote: > > ...<snip>... > > I am ready to kill file this guy. Can someone tell me the easy way to > > do this in T-bird? > > Tools > Message Filters > New > Fill in name, select "From" and put a name or email. > > Easy and effective! > > Cheers, > Elizabeth Elizabeth Rather is afraid to discuss the problems in ANS-Forth. She has been telling people to put me in their kill file since 2009. When I first arrived on C.L.F.. In this thread: https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25-false%5D I brought up the problem of ANS-Forth lacking a D/ that I needed for my continued fractions program. Elizabeth Rather said this: On Friday, November 20, 2009 12:07:12 AM UTC-7, Elizabeth D Rather wrote: > Hugh Aguilar wrote: > ... > > The problem is the ANS-Forth standard. Really, how obvious was the > > need for double-precision arithmetic? This could have been an > > extension to the language similar to floating-point. Compiler-writers > > working on small microprocessors could decline to implement it if they > > didn't want to. > > > > I am frustrated with the ANS-Forth standard because I believe that the > > bad design of the standard is the #1 reason for the failure of Forth > > to become an important language. Forth was doing pretty well in the > > 1980s, but we needed a standard. What we got was Forth-83, and then > > ANS-Forth-94, both of which were badly designed. With some more > > thoughtful leadership we could have succeeded. > > There are D+, D-, M*, M/, and M*/ (and the unsigned operators). These > were adequate in a very wide variety of projects over a 30 year period, > many of which were extremely computation-intensive and running on slow > 16-bit processors. > > Forth's design is pragmatic: it has functions that have been needed and > that have proven their usefulness *in Forth*, not necessarily those that > have been required in other languages. Generally speaking, Forth has > the most flexible set of *integer* arithmetic operators of any language. > In particular, M*/ was one of Chuck's most brilliant innovations. I'm > sure if Chuck were trying to do your continued fractions that is what he > would rely on. Yes, that sometimes requires thinking differently, like > many other things in Forth. > > Cheers, > Elizabeth This is absurd! Chuck Moore doesn't work for me, so why mention him? Also, he doesn't have any magic that turns M*/ into D/ despite his brilliance. I'm supposed to think differently? Differently from what? Reality? Later on she says: On Friday, November 20, 2009 6:12:36 PM UTC-7, Elizabeth D Rather wrote: > The major reason Forth hasn't been accepted is lack of marketing, either > in the form of adoption by major companies or organizations or papers in > various publications, meetings, etc. The vast majority of programmers > out there haven't considered Forth and rejected it for some reason > (although some have heard -- and passed on -- rumors about > unreadability, etc.), they simply never heard of it. This translates into everybody sending Forth Inc. money so Forth Inc. can become a "major company." Sending Forth Inc. money isn't going to help --- Forth Inc. screwed up the ANS-Forth standard by requiring that SwiftForth be standard without any change to SwiftForth whatsoever --- sending Forth Inc. money is going to make the situation worse rather than better. Shortly thereafter Elizabeth Rather denounced me for being homophobic and since then has relentlessly encouraged everybody to put me on their kill list. It is not really because I'm homophobic --- it is because I know how to program in Forth.
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web