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 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-07 07:52 +0000 |
| Message-ID | <2014Oct7.095238@mips.complang.tuwien.ac.at> |
| In reply to | #33710 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>rickman wrote:
>> Are you saying the tool craps out on the compile, but doesn't tell you
>> where the mistake is? You can always have bad tools, that doesn't make
>> the idea poor.
>
>This is due to the very nature of concatenated code: If you specify a stack
>effect, and the code doesn't have the stack effect, an automated tool can't
>tell you where the mistake is. How should it? The parameter passing is all
>implicit, so the tool can't know.
That's the same with type inference. You are given the information
that the inferred type is not valid for some function, but the shown
inferred type may be quite different from what you intended; so there
is a mistake in some of the code that the type was inferred from, but
there is no indication, where.
- 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-09-25 00:34 -0700 |
| Message-ID | <4b0c86cf-ced5-4010-bb32-af019c149be2@googlegroups.com> |
| In reply to | #33541 |
On Wednesday, 24 September 2014 12:56:21 UTC+1, Albert van der Horst wrote: > 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. There's a very simple fix for this. It's called "commenting your code". Radical, I know, but hey... that's me...
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-01 23:26 +0200 |
| Message-ID | <m0hrik$ep8$1@online.de> |
| In reply to | #33522 |
Elizabeth D. Rather wrote: > 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. At the GNU Hacker's Meeting mid of August, I had some discussions with the students of the organizer; who are pretty much in the Haskell/Coq camp (i.e. strong typechecked functional programming languages). The obvious question as Forth programmer is "why do you want it that way", and the answer was "writing tests is soooo tedious that I want the compiler to check everything out of the code before I have to start running it". Forth does the opposite: It makes writing the first tests so easy that you don't start thinking about what the compiler could do for you. In fact, I found it not very helpful that Factor is checking the stack depth, and refusing to compile a definition when the stack effect is wrong. I would prefer a warning, and would try to run the definition to figure out why there is a stack depth mismatch between stack effect and definition. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-01 16:15 -0700 |
| Message-ID | <7xk34jjs9f.fsf@ruckus.brouhaha.com> |
| In reply to | #33611 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > pretty much in the Haskell/Coq camp (i.e. strong typechecked > functional programming languages). The obvious question as Forth > programmer is "why do you want it that way", and the answer was > "writing tests is soooo tedious that I want the compiler to check > everything out of the code before I have to start running it". > Forth does the opposite: It makes writing the first tests so easy that > you don't start thinking about what the compiler could do for you. That isn't really fair: Coq is a proof assistant that takes a ton of effort to use, so you'd only use it for research/academic purposes or for special applications where the need for high correctness assurance justifies much higher development effort than normal programming techniques would. However, we see the value of this in the absence of CompCert bugs compared to the extensive bug histories of GCC, LLVM, etc. Haskell on the other hand is quite pleasant when used as a practical tool. (Some people like to do advanced Coq-like type hackery with it, but that's more like a sport than a practical technique). Automatic type inference and checking really does find simple bugs quickly, that save you some testing effort and that sometimes finds stuff that testing misses. And the type system also makes refactoring a lot easier. Refactor a Forth program and you have to rewrite all the tests except for the lowest level ones. Refactor a Haskell program and it's as if the compiler generates new tests all by itself: it tends to take some iterations to fix newfound type errors when you compile the new program, but once the compiler stops complaining, the program is usually right. I'd be interested to hear about refactoring experiences in Forth. I know that Chuck tended not to bother. He rewrote programs completely when the specifications changed. I notice http://fossil.net2o.de/net2o/wiki?name=nsa-backdoor has a bunch of disclaimers about possible bugs in net2o. I think you might have more confidence in it if it were written in Coq. ;-)
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-01 21:57 -1000 |
| Message-ID | <NNadnRQ-lZDrmLDJnZ2dnUU7-d2dnZ2d@supernews.com> |
| In reply to | #33612 |
On 10/1/14 1:15 PM, Paul Rubin wrote: > Refactor a Forth program and you have to rewrite all the tests except > for the lowest level ones. Refactor a Haskell program and it's as if > the compiler generates new tests all by itself: it tends to take some > iterations to fix newfound type errors when you compile the new program, > but once the compiler stops complaining, the program is usually right. > > I'd be interested to hear about refactoring experiences in Forth. I > know that Chuck tended not to bother. He rewrote programs completely > when the specifications changed. If the specifications (or your understanding of them) have changed so much a rewrite is necessary, yes, you have a lot of testing to do. But my experience is that "refactoring" per se is primarily a local optimization, so in most real-world instances the effects are local and most of the tests are unchanged (though they have to be re-run). I assume you're imagining something like a variable that was a single becoming a double, since you're focusing on type. In my experience, that kind of change is relatively rare, and very easy to compensate for by searching on all instances of it. In my experience the kinds of changes that occur well into a project are more likely to involve changes in logic, not type, so type checking would be irrelevant. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-02 01:20 -0700 |
| Message-ID | <7x38b6992j.fsf@ruckus.brouhaha.com> |
| In reply to | #33631 |
"Elizabeth D. Rather" <erather@forth.com> writes: > my experience is that "refactoring" per se is primarily a local > optimization, ... > I assume you're imagining something like a variable that was a single > becoming a double More typically it means reorganizing a bunch of functions underneath some interface, adding or removing arguments to some of them, etc. Yes of course you have to test, but typechecking catches a lot of silly or trivial issues automatically, that you would otherwise have to test for or else you can get subtle bugs. That automation lets you concentrate your testing effort on less trivial things.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-02 15:59 +0200 |
| Message-ID | <m0jloq$tl$1@online.de> |
| In reply to | #33612 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> pretty much in the Haskell/Coq camp (i.e. strong typechecked >> functional programming languages). The obvious question as Forth >> programmer is "why do you want it that way", and the answer was >> "writing tests is soooo tedious that I want the compiler to check >> everything out of the code before I have to start running it". > >> Forth does the opposite: It makes writing the first tests so easy that >> you don't start thinking about what the compiler could do for you. > > That isn't really fair: Coq is a proof assistant that takes a ton of > effort to use, so you'd only use it for research/academic purposes or > for special applications where the need for high correctness assurance > justifies much higher development effort than normal programming > techniques would. However, we see the value of this in the absence of > CompCert bugs compared to the extensive bug histories of GCC, LLVM, etc. These students do academic stuff, and apparently, for them it is percieved easier to write a Coq proof than to test their stuff. I think that's partly because in computer science, a lot of proof stuff (on the blackboard) is done, while teaching them how to test their program is rare. > Haskell on the other hand is quite pleasant when used as a practical > tool. (Some people like to do advanced Coq-like type hackery with it, > but that's more like a sport than a practical technique). Automatic > type inference and checking really does find simple bugs quickly, So does the interactive testing with Forth words. You find simple bugs really, really quick. > that > save you some testing effort and that sometimes finds stuff that testing > misses. And the type system also makes refactoring a lot easier. > Refactor a Forth program and you have to rewrite all the tests except > for the lowest level ones. That's not my experience. Refactoring the API of course means that you have to change your regression tests (those are testing the exposed API), but as Elizabeth wrote, most refactoring is internals, and testing the internal stuff usually is not done with regression tests, but with a few tests on the command line. > Refactor a Haskell program and it's as if > the compiler generates new tests all by itself: it tends to take some > iterations to fix newfound type errors when you compile the new program, > but once the compiler stops complaining, the program is usually right. Yes, same experience in Forth: Refactoring means you have to run a few trivial tests on the command line, to fix newly introduced errors, and then the programm is right again. In Forth, you don't do a big session of refactoring a lot of things, you refactor step by step, keeping a working system, and you test each change individually. And by doing that, you don't have to figure out where the root cause of the not very easy to understand messages from GHC are, but you can see input/output relations and code traces of what happened. This sort of hands-on debugging is certainly different from the hands-off typechecking system. > I'd be interested to hear about refactoring experiences in Forth. I > know that Chuck tended not to bother. He rewrote programs completely > when the specifications changed. > > I notice http://fossil.net2o.de/net2o/wiki?name=nsa-backdoor has a bunch > of disclaimers about possible bugs in net2o. I think you might have > more confidence in it if it were written in Coq. ;-) Oh no, apparently you didn't get that page m(. This is a warrant canary. As long as I continue to write silly disclaimers about bugs there, the NSA didn't force me to add a backdoor. There's absolutely nothing Coq can do about that sort of malicious backdoor injected by the author of the program himself, who of course will change the assertions/tests/whatever quality control so that they pass. The only thing you have for this is inspection by third party, and this is known to not work for anything moderately complex, especially crypto, where there are only a few expertes around. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-02 19:29 -0700 |
| Message-ID | <7xsij5c2di.fsf@ruckus.brouhaha.com> |
| In reply to | #33644 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> These students do academic stuff, and apparently, for them it is percieved
> easier to write a Coq proof than to test their stuff.
If the thing is complicated, it's probably easier to write a proof than
to test enough to reach confidence that the code has zero bugs. There's
a similar situation in hardware, if you have a complicated design with
concurrency or whatever. You can run tests til you're blue in the face,
but they can never give you the assurance that a model checker can.
http://www21.in.tum.de/~traytel/papers/haskell14-teaching/teaching.pdf
has an interesting example about a homework assignment the authors had
given to beginning Haskell students. The task was to to write a
function f(x,y,z) that computes the sum of the squares of its two
largest arguments (pretty easy), using the fewest tokens possible. The
winning entry was 13 tokens (note that Haskell's backtick syntax x `f` y
is sugar for (f x y)):
max x y ^ 2 + min x y `max` z ^ 2
But does it always work? The authors write, "Here the concision was
attained at the expense of simplicity, to the point that we felt the
need to verify the solution with Isabelle."
> I think that's partly because in computer science, a lot of proof
> stuff (on the blackboard) is done, while teaching them how to test
> their program is rare.
The Haskell paper above does discuss testing to some extent. It
mentions that QuickCheck (test generation framework) is part of the
second lecture.
> Yes, same experience in Forth: Refactoring means you have to run a few
> trivial tests on the command line, to fix newly introduced errors, and
> then the programm is right again.
In order to think up those tests and run them, you have to understand
the code pretty well, not always easy if it's old complicated code
written by someone other than you. Type signatures and automatic checks
make it a lot easier to avoid mistakes.
I think the interactive approach runs out of steam once the program gets
complicated enough. And in a message a few days ago you compared your
results with your Verilog b16 implementation, vs. Chuck's F18 that he
did with his Forth tools involving a heck of a lot more effort and at
best comparable final output. That shows that big software like the
Verilog toolchain really does have its benefits. But for it to exist,
someone has to write and test and maintain it, and that means techniques
for doing such things are worthy of study.
> And by doing that, you don't have to figure out where the root cause
> of the not very easy to understand messages from GHC are,
GHC's messages are hard to understand, but they usually identify the
line number where the problem is, so you can generally look there and
figure out what is wrong.
> but you can see input/output relations and code traces of what
> Oh no, apparently you didn't get that page m(. This is a warrant canary.
> As long as I continue to write silly disclaimers about bugs there, the NSA
> didn't force me to add a backdoor.
Heh, ok. So if you announce someday that the code is now solid and
reliable, it's time to start worrying :).
> There's absolutely nothing Coq can do about that sort of malicious
> backdoor injected by the author of the program himself...
Certainly there are fewer places to hide backdoors in safe languages.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-10-03 15:03 +0000 |
| Message-ID | <542ebad0$0$6856$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #33672 |
In article <7xsij5c2di.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >Bernd Paysan <bernd.paysan@gmx.de> writes: >> These students do academic stuff, and apparently, for them it is percieved >> easier to write a Coq proof than to test their stuff. > >If the thing is complicated, it's probably easier to write a proof than >to test enough to reach confidence that the code has zero bugs. There's >a similar situation in hardware, if you have a complicated design with >concurrency or whatever. You can run tests til you're blue in the face, >but they can never give you the assurance that a model checker can. > >http://www21.in.tum.de/~traytel/papers/haskell14-teaching/teaching.pdf >has an interesting example about a homework assignment the authors had >given to beginning Haskell students. The task was to to write a >function f(x,y,z) that computes the sum of the squares of its two >largest arguments (pretty easy), using the fewest tokens possible. The >winning entry was 13 tokens (note that Haskell's backtick syntax x `f` y >is sugar for (f x y)): > > max x y ^ 2 + min x y `max` z ^ 2 > >But does it always work? The authors write, "Here the concision was >attained at the expense of simplicity, to the point that we felt the >need to verify the solution with Isabelle." > >> I think that's partly because in computer science, a lot of proof >> stuff (on the blackboard) is done, while teaching them how to test >> their program is rare. > >The Haskell paper above does discuss testing to some extent. It >mentions that QuickCheck (test generation framework) is part of the >second lecture. > >> Yes, same experience in Forth: Refactoring means you have to run a few >> trivial tests on the command line, to fix newly introduced errors, and >> then the programm is right again. > >In order to think up those tests and run them, you have to understand >the code pretty well, not always easy if it's old complicated code >written by someone other than you. Type signatures and automatic checks >make it a lot easier to avoid mistakes. No! For two reasons. First you make sure that the refactored code does exactly what it did before. There is no need to understand much of the code to eliminate dead code, or to replace a call with a control variable, by two calls to different subroutines without the control variable. Secondly. I've done maintenance on code where it was absolutely impossible to get a pretty good idea of the code. You can repair a running train! The solution is regression tests. The Dutch tax office had a program to move tax payers letters history around. After one year I didn't have the global description in order, and the 10 tome program description was intractible (and repetitive to the point that you couldn't read it for 10 minutes without falling asleep. The solution is to use one of those 2Gbyte contorted compressed message files as a regression test. If the result is exactly the same (possibly buggy) your refactoring is approved. If there are defects introduced, nobody can tell anyway, but I could solve them quicker. > >I think the interactive approach runs out of steam once the program gets >complicated enough. And in a message a few days ago you compared your >results with your Verilog b16 implementation, vs. Chuck's F18 that he >did with his Forth tools involving a heck of a lot more effort and at >best comparable final output. That shows that big software like the >Verilog toolchain really does have its benefits. But for it to exist, >someone has to write and test and maintain it, and that means techniques >for doing such things are worthy of study. I have to agree. Interactive testing in the above situation is out of the question. <SNIP> -- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-05 02:27 +0200 |
| Message-ID | <m0q39c$68s$1@online.de> |
| In reply to | #33672 |
Paul Rubin wrote: > I think the interactive approach runs out of steam once the program gets > complicated enough. And in a message a few days ago you compared your > results with your Verilog b16 implementation, vs. Chuck's F18 that he > did with his Forth tools involving a heck of a lot more effort and at > best comparable final output. That shows that big software like the > Verilog toolchain really does have its benefits. But for it to exist, > someone has to write and test and maintain it, and that means techniques > for doing such things are worthy of study. Actually, the Verilog toolchain has its checks, which are absolutely essential to find all the bugs, and the checker programs are completely separate - you do a formal comparison of the netlist vs. your original behavioral Verilog (checking if the synthesis tool did its job), you do a static timing analysis with a sign-off analysis tool (a different tool, written by someone else, even though the synthesis tool contains a static timing analysis) and you have a DRC (desing rule check)+LVS (layout vs. schematic) checker to verify that the place&route did its job. Each time! And you do that, because the complex toolchain is actually not very well debugged. And it's usually written in some lower level language, because performance matters, i.e. most of these Haskell or Coq approaches aren't even taken. Not even the Forth ones. The level of buggyness in these large tools had been pretty high; the key to make these tools actually work is usually to figure out how to make the essential core smaller, so that it just works. Example: at one point in time during my design career, I was really pissed how long the LVS took to verify one of my chips. It took hours. I started thinking about how I would do LVS. You start with two flat netlists which contains transistors, diodes, resistors, capacitors and nets to connect them. You have to check if these match. My idea was to proceed as follows: Repeatedly refine doing the following: 1. Put the nets into bins, by number of connections to different device terminals (at start, all device terminals of a particular type, e.g. a PMOS gate, are "equal"). 2. Put the devices into bins, by net type attached to them (by putting the nets into bins, you make the nets starting to become different). I've done some tests with that idea; I haven't written the complete tool, because removing devices which aren't to be checked and collapsing parallel structures would also have been part of that exercise. But the matching part ran a 100 times faster than the big expensive tool, and it really was a small program. The reason why I didn't complete that program was that we bought a fast LVS tool from some other vendor, which also ran much faster, and apparently used a similar algorithm - so this stuff had already been done, and I didn't have to do it myself. To be fair with Chuck: His OKAD is from the 1990s. And it does produce considerably better results than the big bloated tools from the 1990s - with considerably more effort, but up to a few years ago, "do it manually" was considered "the way" for high-performance CPUs. But the world has moved on, and several of these "tough" problems to do synthesis, place and route, and so on, have been solved, or at least become considerably faster and less buggy - and if you see such progress, it's usually, because someone had an idea how to make it considerably simpler. Therefore, my advice is, when you are in the situation of having some old and complicated code which you can't understand: Throw it away. Just throw it away - after you understood the problem and found a much simpler solution. It's worth the time to check if you can't do it much simpler, faster and less bug-prone, and if you are clever, you will end up with a much better solution. Without the maintenance nightmare. I think the essence of your mistake is that you assume this code *has* to be that complex, just because it actually is complex (you asume that complexity is all essential, and not, as Brooks noted, mostly accidential). And that because it is complex, it has been verified and maintained with the method you prefer: static typechecking. That's a non sequitur, it hasn't, it has been written in a language which doesn't do much typechecking. And it has been tested with a testing approach that doesn't test a lot, apart from the actual final output. And that's why it took long to develop and costs a fortune, and the maintenance team is just pushing the bugs from one side to the other, and never really fixes them (until some clever startup replaces the entire program with something considerably simpler, which fortunately happens from time to time). The magic of bug-free code is to make things simple. Especially in the Haskell context, I completely fail to understand how you can trust a huge, buggy bloatware like GHC to compile and check your program. It's not like GHC has just a few bugs, it has more than a thousand open tickets: https://ghc.haskell.org/trac/ghc/ of which nearly a thousand are bugs. And of course, that's all written in Haskell, and if I understood you correctly, the type system makes all these bugs disapear by miracle. Of course, GHC is a big pile of old, complicated code. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul E Bennett <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2014-10-05 09:22 +0100 |
| Message-ID | <c9cdenF6sfgU1@mid.individual.net> |
| In reply to | #33695 |
Bernd Paysan wrote: > Paul Rubin wrote: >> I think the interactive approach runs out of steam once the program gets >> complicated enough. And in a message a few days ago you compared your >> results with your Verilog b16 implementation, vs. Chuck's F18 that he >> did with his Forth tools involving a heck of a lot more effort and at >> best comparable final output. That shows that big software like the >> Verilog toolchain really does have its benefits. But for it to exist, >> someone has to write and test and maintain it, and that means techniques >> for doing such things are worthy of study. > > Actually, the Verilog toolchain has its checks, which are absolutely > essential to find all the bugs, and the checker programs are completely > separate - you do a formal comparison of the netlist vs. your original > behavioral Verilog (checking if the synthesis tool did its job), you do a > static timing analysis with a sign-off analysis tool (a different tool, > written by someone else, even though the synthesis tool contains a static > timing analysis) and you have a DRC (desing rule check)+LVS (layout vs. > schematic) checker to verify that the place&route did its job. Each time! > > And you do that, because the complex toolchain is actually not very well > debugged. And it's usually written in some lower level language, because > performance matters, i.e. most of these Haskell or Coq approaches aren't > even taken. Not even the Forth ones. The level of buggyness in these > large tools had been pretty high; the key to make these tools actually > work is usually to figure out how to make the essential core smaller, so > that it just works. > > Example: at one point in time during my design career, I was really pissed > how long the LVS took to verify one of my chips. It took hours. I > started > thinking about how I would do LVS. You start with two flat netlists which > contains transistors, diodes, resistors, capacitors and nets to connect > them. You have to check if these match. > > My idea was to proceed as follows: Repeatedly refine doing the following: > > 1. Put the nets into bins, by number of connections to different device > terminals (at start, all device terminals of a particular type, e.g. a > PMOS gate, are "equal"). > > 2. Put the devices into bins, by net type attached to them (by putting the > nets into bins, you make the nets starting to become different). > > I've done some tests with that idea; I haven't written the complete tool, > because removing devices which aren't to be checked and collapsing > parallel > structures would also have been part of that exercise. But the matching > part ran a 100 times faster than the big expensive tool, and it really was > a > small program. The reason why I didn't complete that program was that we > bought a fast LVS tool from some other vendor, which also ran much faster, > and apparently used a similar algorithm - so this stuff had already been > done, and I didn't have to do it myself. > > To be fair with Chuck: His OKAD is from the 1990s. And it does produce > considerably better results than the big bloated tools from the 1990s - > with considerably more effort, but up to a few years ago, "do it manually" > was > considered "the way" for high-performance CPUs. But the world has moved > on, and several of these "tough" problems to do synthesis, place and > route, and so on, have been solved, or at least become considerably faster > and less buggy - and if you see such progress, it's usually, because > someone had an idea how to make it considerably simpler. > > Therefore, my advice is, when you are in the situation of having some old > and complicated code which you can't understand: Throw it away. Just > throw it away - after you understood the problem and found a much simpler > solution. It's worth the time to check if you can't do it much simpler, > faster and less bug-prone, and if you are clever, you will end up with a > much better solution. Without the maintenance nightmare. > > I think the essence of your mistake is that you assume this code *has* to > be that complex, just because it actually is complex (you asume that > complexity > is all essential, and not, as Brooks noted, mostly accidential). And that > because it is complex, it has been verified and maintained with the method > you prefer: static typechecking. That's a non sequitur, it hasn't, it has > been written in a language which doesn't do much typechecking. And it has > been tested with a testing approach that doesn't test a lot, apart from > the > actual final output. And that's why it took long to develop and costs a > fortune, and the maintenance team is just pushing the bugs from one side > to the other, and never really fixes them (until some clever startup > replaces the entire program with something considerably simpler, which > fortunately happens from time to time). > > The magic of bug-free code is to make things simple. Especially in the > Haskell context, I completely fail to understand how you can trust a huge, > buggy bloatware like GHC to compile and check your program. It's not like > GHC has just a few bugs, it has more than a thousand open tickets: > > https://ghc.haskell.org/trac/ghc/ > > of which nearly a thousand are bugs. And of course, that's all written in > Haskell, and if I understood you correctly, the type system makes all > these bugs disapear by miracle. > > Of course, GHC is a big pile of old, complicated code. Thanks Bernd, I don't think I could have said it much better myself. For those who want to know about simplification of complex problems then I suggest a reading and understanding of the message contained in Polya's "How to Solve It" (now available on-line in pdf at <https://notendur.hi.is/hei2/teaching/Polya_HowToSolveIt.pdf>). With techniques such as this even the most complex of problems can be reduced to a set of much simpler problems. Once you can start to simplify a problem you begin to really understand it. -- ******************************************************************** 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-23 19:36 -0700 |
| Message-ID | <fc43f7e4-4f0f-4fc6-9ddc-b68a316a9869@googlegroups.com> |
| In reply to | #33516 |
On Monday, September 22, 2014 2:13:03 PM UTC-7, Elizabeth D. Rather wrote: > 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. Here is an example of source-code from SwiftForth-v2. Notice that the word R-BUF pushes its value onto the return-stack rather than the parameter-stack. Then, WID-HEADER (which is quite similar to my :NAME) accesses this value with R@ (there is no corresponding >R which is a real WTF moment for the reader). I think that Elizabeth Rather hired programmers to write SwiftForth who had zero knowledge of Forth. Most likely, the programmer who wrote R-BUF did not understand that Forth has two stacks --- the parameter-stack for data and the return-stack for return addresses. Most likely he had a background in x86 assembly-language programming and when he was told to write a word that returns a value on "the stack" he assumed that this meant the return-stack, because he had never heard of there being any other stack on the x86. SwiftForth is an extremely amateurish Forth implementation! It was written entirely by "newbies" (Elizabeth Rather's term), and there was nobody in charge of the project who knew anything about the subject either, so all of this low-quality code went straight into the production version of SwiftForth for customers such as myself to see and wonder at. LABEL R-GO-ON2 EDX PUSH EAX JMP END-CODE CODE R-BUF ( -- ) EAX POP ESP ECX MOV MAX_PATH # ESP SUB ESP EDX MOV ECX PUSH R-GO-ON2 CALL ECX POP ECX ESP MOV RET END-CODE : WID-HEADER ( c-addr u wid -- ) OVER 0= -16 ?THROW ?UNIQUE -ROT 254 MIN R-BUF R@ PLACE HERE 13 + R@ C@ + 15 AND 16 SWAP - ALLOT LOCATION , R@ COUNT ROT LINKED $FF C, 0 C, R> COUNT EMPLACE HERE 1+ HERE LAST CELL+ 2! 0 C, ;
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-24 13:40 -0700 |
| Message-ID | <943174ba-0b8d-4b79-a2f0-c3335c61247c@googlegroups.com> |
| In reply to | #33516 |
On Monday, September 22, 2014 2:13:03 PM UTC-7, Elizabeth D. Rather wrote: > 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. The word is "Forth-wright" not "Forthwrite." lol If you were 12 years old, mistakes like this would be cute. In my experience, one of the quickest ways to spot a salesperson, is that all salespeople are semi-literate and will have a poor command of the English language. A lot of salespeople are clever at memorizing snippets of code, engineering trivia and design proverbs --- and so they can fake up technical expertise for quite some time --- but their essential idiocy should be obvious to anybody with perception. The difference between salespeople and technical people, is that technical people are in the habit of rigorously checking their work. Salespeople never check their work, because their is no "correct" sales pitch --- it is all just a lot of baloney, and sometimes the customer hands over money and sometimes not, but the salesperson is never sure of what causes the money to be handed over. By comparison, there is such a thing as correct software --- that is software that does what it is supposed to do --- and a programmer will check to make sure that his or her software does what it is supposed to do before showing it to anybody. The reason why Elizabeth Rather messes up every time that she posts code to define an array or to teach us how DO works (ye olde STARS word from "Starting Forth") is because she has never had to check her work for correctness and she is not in the habit of doing any checking at all. She just memorizes these code snippets from "Starting Forth" and presents them on C.L.F. to fake up expertise, but she is too lazy to pick up the "Starting Forth" book and copy the code snippet exactly --- she tries to do it from memory, and she gets it wrong. I have never seen any code from Elizabeth Rather that didn't come straight out of the "Starting Forth" book, and she messes it up pretty much every time --- she can't even get a one-line function correct. But she is totally oblivious to the concept of correctness --- for her, presenting code is just a sales pitch, and hopefully somebody will send money to Forth Inc. --- but making sure that the code actually works, is not important to her.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-09-16 17:06 +0000 |
| Message-ID | <54186e1a$0$15882$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #33379 |
In article <541855C0.2558D27D@bytecraft.com>, Walter Banks <walter@bytecraft.com> wrote: >I am working on a code generator for a stack processor. >Who better to ask about real stack requirements than a forth group. > >The question is what is the expected stack requirements for a >forth implementation? > >Is there any benchmark code that test stack usage? Most programs get by with a smallish amount (say 16). Not so recursive algorithms. Some Forths have an humongous space for the stack, or can be configured to have so. If it is documented, a programmer may rely on it, which allows particular programs, that will not run on just any Forth. A small example. It can be pleasant to have WORDS shown the words as most recent last. This order can be reversed by pushing all words on the stack first, which may require hundreds of cells. A hosted Forth (Unix, Mac, MS-stuff) will almost certainly accommodate this. > >Many Thanks > >w.. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-16 07:43 -1000 |
| Message-ID | <lvSdnUIknLle64XJnZ2dnUU7-TmdnZ2d@supernews.com> |
| In reply to | #33379 |
On 9/16/14 5:22 AM, Walter Banks wrote: > I am working on a code generator for a stack processor. > Who better to ask about real stack requirements than a forth group. > > The question is what is the expected stack requirements for a > forth implementation? > > Is there any benchmark code that test stack usage? > > Many Thanks As others have noted, this issue obviously depends a lot on both application needs and programming style. We at FORTH, Inc. have done studies from time to time. The easiest way is to write a pattern (e.g. #DEADBEEF) all over the relevant region of memory when the program is launched, and after it has run for a while, dump the stack area and see where it has been overwritten. As I recall, our studies found that stacks rarely exceeded half a dozen items, at however many bytes/cell that took. Obviously if you're doing a lot of recursion or something like that it would be different. 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-16 15:04 -0400 |
| Message-ID | <541889C9.C49DBB52@bytecraft.com> |
| In reply to | #33389 |
"Elizabeth D. Rather" wrote: > On 9/16/14 5:22 AM, Walter Banks wrote: > > I am working on a code generator for a stack processor. > > Who better to ask about real stack requirements than a forth group. > > > > The question is what is the expected stack requirements for a > > forth implementation? > > > > Is there any benchmark code that test stack usage? > > > As others have noted, this issue obviously depends a lot on both > application needs and programming style. We at FORTH, Inc. have done > studies from time to time. The easiest way is to write a pattern (e.g. > #DEADBEEF) all over the relevant region of memory when the program is > launched, and after it has run for a while, dump the stack area and see > where it has been overwritten. > > As I recall, our studies found that stacks rarely exceeded half a dozen > items, at however many bytes/cell that took. Obviously if you're doing a > lot of recursion or something like that it would be different. For non hosted embedded systems the upper limit seems to be 14 levels and around half dozen was typical. I don't know of many cases where deep recursive algorithms cannot be generated with some form of tail end recursion by a code generator with full application data flow information. I am tracking actual stack usage in a development simulator and probably will initialize the the actual hardware with as you suggest DEADBEEF Are there ways that stack depth can be traded for reduced execution time other than the savings of intermediate values in expression evaluation? w..
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-16 09:34 -1000 |
| Message-ID | <x6edneCDfcNfDYXJnZ2dnUU7-c-dnZ2d@supernews.com> |
| In reply to | #33391 |
On 9/16/14 9:04 AM, Walter Banks wrote: > "Elizabeth D. Rather" wrote: > >> On 9/16/14 5:22 AM, Walter Banks wrote: >>> I am working on a code generator for a stack processor. >>> Who better to ask about real stack requirements than a forth group. >>> >>> The question is what is the expected stack requirements for a >>> forth implementation? >>> >>> Is there any benchmark code that test stack usage? >> >> >> As others have noted, this issue obviously depends a lot on both >> application needs and programming style. We at FORTH, Inc. have done >> studies from time to time. The easiest way is to write a pattern (e.g. >> #DEADBEEF) all over the relevant region of memory when the program is >> launched, and after it has run for a while, dump the stack area and see >> where it has been overwritten. >> >> As I recall, our studies found that stacks rarely exceeded half a dozen >> items, at however many bytes/cell that took. Obviously if you're doing a >> lot of recursion or something like that it would be different. > > For non hosted embedded systems the upper limit seems to be 14 levels > and around half dozen was typical. Yes, of course when you have to do things like Windows calls you get a lot of deep stacks. Native systems are much easier. > I don't know of many cases where deep recursive algorithms cannot be > generated with some form of tail end recursion by a code generator > with full application data flow information. > > I am tracking actual stack usage in a development simulator and probably > will initialize the the actual hardware with as you suggest DEADBEEF > > Are there ways that stack depth can be traded for reduced execution time > other than the savings of intermediate values in expression evaluation? Well, using locals always costs in performance. Otherwise, the best advice is to use variables for persistent values that need to be accessed by multiple tasks or sections of the code, and the data stack otherwise. And arrays for arrays, of course. 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-17 17:30 -0400 |
| Message-ID | <5419FD8E.D1CAEEE5@bytecraft.com> |
| In reply to | #33393 |
"Elizabeth D. Rather" wrote: > > Well, using locals always costs in performance. Otherwise, the best > advice is to use variables for persistent values that need to be > accessed by multiple tasks or sections of the code, and the data stack > otherwise. And arrays for arrays, of course. You have made two comments about locals. I am assuming the reference is to locals that kept on the stack as opposed to local variables that have local scoping and can be re-allocated by the compiler when the space is out of scope. Stack locals are computationally expensive. In generic languages scoped locals (re)using ram space not so much. w..
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-17 12:42 -1000 |
| Message-ID | <aIudncH_yb38k4fJnZ2dnUU7-R2dnZ2d@supernews.com> |
| In reply to | #33407 |
On 9/17/14 11:30 AM, Walter Banks wrote:
> "Elizabeth D. Rather" wrote:
>
>>
>> Well, using locals always costs in performance. Otherwise, the best
>> advice is to use variables for persistent values that need to be
>> accessed by multiple tasks or sections of the code, and the data stack
>> otherwise. And arrays for arrays, of course.
>
> You have made two comments about locals. I am assuming the reference
> is to locals that kept on the stack as opposed to local variables that have
> local scoping and can be re-allocated by the compiler when the space is
> out of scope.
>
> Stack locals are computationally expensive. In generic languages scoped
> locals (re)using ram space not so much.
Classical Forth does not use named "local variables." One can declare
variables (and other data structures) that are either global or
restricted to a single user (task), but generally parameters and
intermediate values are kept on the data stack, which is managed
directly by the programmer.
In recent years, a capability for named local variables ("local" meaning
accessible within a single colon definition) has been added to Forth
standards, and they are popular in some circles. Studies have indicated
that there is measurable performance overhead in using locals. Use of
the stack for parameter passing and intermediate values is extremely
efficient.
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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-18 11:33 +0000 |
| Message-ID | <2014Sep18.133306@mips.complang.tuwien.ac.at> |
| In reply to | #33411 |
"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.
- 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]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web