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 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-19 07:21 -0400 |
| Message-ID | <541C11C5.5AD2C7E0@bytecraft.com> |
| In reply to | #33406 |
rickman wrote: > On 9/16/2014 7:11 PM, Paul Rubin wrote: > > Walter Banks <walter@bytecraft.com> writes: > >> The stack question comes from a bigger argument about what is > >> an appropriate stack size for a processor. Part of the discussion > >> has been about the nature of code written for a stack machine and > >> how it affects machine resources. > > > > You should look up Philip Koopman's old book "Stack Machines" and > > related papers, if you haven't. Also the more recent work by Tikhon > > Jelvis about compiling for the GreenArrays processor: > > > > http://jelv.is/chlorophyll.pdf > > I was glancing through this paper and see they discuss a "trick" that > can be used on the GA144 that won't work in most other machines. The > stack is a circular file it doesn't matter if you leave data littering > the bottom of the stack. In fact, that can be a "feature" if you happen > to find the circular size to be convenient. But as long as your code > does not get called with other parameters on the stack it can leave junk > on the stack and just ignore it potentially shortening the program and > running faster. This would likely not be unusual in the tiny apps that > are common on the GA144 processors. I hadn't seen the chlorophyll paper until you posted the link a couple days ago. Earlier in this project I specifically looked at the use of a circular stack and what the advantages it would have to just leave junk lying around and not needing to care. The answer we arrived at was not much of an advantage. We compared two code generators each optimized one for a circular stack and one not. There are differences in code generation strategy but the metrics on cycles and code size were very similar. w..
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-19 10:01 -0400 |
| Message-ID | <541C3737.EC861D30@bytecraft.com> |
| In reply to | #33433 |
Walter Banks wrote: > rickman wrote: > > > On 9/16/2014 7:11 PM, Paul Rubin wrote: > > > Walter Banks <walter@bytecraft.com> writes: > > >> The stack question comes from a bigger argument about what is > > >> an appropriate stack size for a processor. Part of the discussion > > >> has been about the nature of code written for a stack machine and > > >> how it affects machine resources. > > > > > > You should look up Philip Koopman's old book "Stack Machines" and > > > related papers, if you haven't. Also the more recent work by Tikhon > > > Jelvis about compiling for the GreenArrays processor: > > > > > > http://jelv.is/chlorophyll.pdf > > > > I was glancing through this paper and see they discuss a "trick" that > > can be used on the GA144 that won't work in most other machines. The > > stack is a circular file it doesn't matter if you leave data littering > > the bottom of the stack. In fact, that can be a "feature" if you happen > > to find the circular size to be convenient. But as long as your code > > does not get called with other parameters on the stack it can leave junk > > on the stack and just ignore it potentially shortening the program and > > running faster. This would likely not be unusual in the tiny apps that > > are common on the GA144 processors. > > I hadn't seen the chlorophyll paper until you posted the link a couple > days ago. Earlier in this project I specifically looked at the use of a > circular stack and what the advantages it would have to just leave > junk lying around and not needing to care. The answer we arrived > at was not much of an advantage. We compared two code generators > each optimized one for a circular stack and one not. There are differences > in code generation strategy but the metrics on cycles and code size > were very similar. An additional comment. The Mill project effectively does something similar to a circular stack with its moving stack. It does two things recognizes that local variables almost always has context sensitive recent scope and lets the compiler do the accounting for data offset. It for the most part is interesting reusable register allocator. w..
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-19 07:42 -0700 |
| Message-ID | <7xvbojzn7e.fsf@ruckus.brouhaha.com> |
| In reply to | #33438 |
Walter Banks <walter@bytecraft.com> writes: > An additional comment. The Mill project effectively does something > similar to a circular stack with its moving stack. I think of Mill as an unusual register machine rather than a stack machine, since the "belt" requires random access. GA-style stack machines don't have any way to access the stack interior, which simplifies the hardware (no bypass network, if I'm using the term correctly: ALU inputs are always the two registers TOS and NOS) and makes it possible to run at very high frequencies on older processes (the GA is 700 mhz on 0.18 micron cmos). The circular stack "feature" of letting you fill the stack with a constant and then have an endless supply of that constant doesn't seem so useful, but you can save a few program bytes by not having to clean up old stack debris in some situations. Chlorophyll has a fair amount of unusual compiler technology so I thought you might like the paper.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-19 14:46 +0000 |
| Message-ID | <2014Sep19.164652@mips.complang.tuwien.ac.at> |
| In reply to | #33439 |
Paul Rubin <no.email@nospam.invalid> writes:
>GA-style stack
>machines don't have any way to access the stack interior, which
>simplifies the hardware (no bypass network, if I'm using the term
>correctly: ALU inputs are always the two registers TOS and NOS) and
>makes it possible to run at very high frequencies on older processes
>(the GA is 700 mhz on 0.18 micron cmos).
These frequencies are not very high. The Intel Coppermine achieved
1100MHz, the AMD Thunderbird achieved 1400MHz, the AMD Palomino
1733MHz, and the Intel Williamette achieved 2000MHz, all in 0.18u (but
typically with stuff like domino logic). Of course, all of these used
much more power than a Greenarrays core.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-19 08:09 -0700 |
| Message-ID | <7xk34zve8o.fsf@ruckus.brouhaha.com> |
| In reply to | #33440 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > These frequencies are not very high. The Intel Coppermine achieved > 1100MHz, the AMD Thunderbird achieved 1400MHz, the AMD Palomino > 1733MHz, and the Intel Williamette achieved 2000MHz, all in 0.18u (but > typically with stuff like domino logic). Of course, all of these used > much more power than a Greenarrays core. Oh interesting. Maybe it was the GA's predecessors like the F21 that ran at much higher frequencies than conventional cpu's of their eras. I had figured that was due to the simpler architecture.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-20 03:41 -0400 |
| Message-ID | <lvjb4n$69a$1@dont-email.me> |
| In reply to | #33441 |
On 9/19/2014 11:09 AM, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> These frequencies are not very high. The Intel Coppermine achieved >> 1100MHz, the AMD Thunderbird achieved 1400MHz, the AMD Palomino >> 1733MHz, and the Intel Williamette achieved 2000MHz, all in 0.18u (but >> typically with stuff like domino logic). Of course, all of these used >> much more power than a Greenarrays core. > > Oh interesting. Maybe it was the GA's predecessors like the F21 that > ran at much higher frequencies than conventional cpu's of their eras. > I had figured that was due to the simpler architecture. Yes, the F18A is a fast processor for the process because it is so simple. Remember that it isn't pipelined, so there are no stalls... well, sort of.. The instruction fetch runs in parallel with the execution, so if you do any memory accesses (anywhere in the address space, not just to the instruction store) it has to restart the fetch with some delay. But that is it. In one of those behemoth processors they are superpipelined and superscaler so that they are constantly refilling the pipes and holding one pipe for the result from another. This gives a major hit to the theoretical performance you might get if all that circuitry were doing something useful 100% of the time. The point is comparing an x86 to an F18A is *very* much apples and oranges with little value. Try comparing it to an 8051 or as GA did, a TMS430. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-20 15:31 +0000 |
| Message-ID | <2014Sep20.173108@mips.complang.tuwien.ac.at> |
| In reply to | #33452 |
rickman <gnuarm@gmail.com> writes:
>On 9/19/2014 11:09 AM, Paul Rubin wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> These frequencies are not very high. The Intel Coppermine achieved
>>> 1100MHz, the AMD Thunderbird achieved 1400MHz, the AMD Palomino
>>> 1733MHz, and the Intel Williamette achieved 2000MHz, all in 0.18u (but
>>> typically with stuff like domino logic). Of course, all of these used
>>> much more power than a Greenarrays core.
>>
>> Oh interesting. Maybe it was the GA's predecessors like the F21 that
>> ran at much higher frequencies than conventional cpu's of their eras.
>> I had figured that was due to the simpler architecture.
...
>In one of those behemoth processors they are superpipelined and
>superscaler so that they are constantly refilling the pipes and holding
>one pipe for the result from another. This gives a major hit to the
>theoretical performance you might get if all that circuitry were doing
>something useful 100% of the time.
Sure, and the GA chips are not getting the "theoretical performance
you might get if all that circuitry were doing something useful 100%
of the time", either, because they are also waiting for some things.
That how things work. But utilization is not really the most useful
metric. Overall performance is one people care about, or performance
per watt. Utilization is a sour grapes metric.
>The point is comparing an x86 to an F18A is *very* much apples and
>oranges with little value.
Certainly. But it gives a perspective to the claim that the GA cores
are fast because of the simpler hardware. BTW, the Williamette could
do two dependent adds per cycle.
- 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-20 14:53 -0400 |
| Message-ID | <lvkif4$5rr$1@dont-email.me> |
| In reply to | #33461 |
On 9/20/2014 11:31 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> On 9/19/2014 11:09 AM, Paul Rubin wrote: >>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>>> These frequencies are not very high. The Intel Coppermine achieved >>>> 1100MHz, the AMD Thunderbird achieved 1400MHz, the AMD Palomino >>>> 1733MHz, and the Intel Williamette achieved 2000MHz, all in 0.18u (but >>>> typically with stuff like domino logic). Of course, all of these used >>>> much more power than a Greenarrays core. >>> >>> Oh interesting. Maybe it was the GA's predecessors like the F21 that >>> ran at much higher frequencies than conventional cpu's of their eras. >>> I had figured that was due to the simpler architecture. > .... >> In one of those behemoth processors they are superpipelined and >> superscaler so that they are constantly refilling the pipes and holding >> one pipe for the result from another. This gives a major hit to the >> theoretical performance you might get if all that circuitry were doing >> something useful 100% of the time. > > Sure, and the GA chips are not getting the "theoretical performance > you might get if all that circuitry were doing something useful 100% > of the time", either, because they are also waiting for some things. > That how things work. But utilization is not really the most useful > metric. Overall performance is one people care about, or performance > per watt. Utilization is a sour grapes metric. I'm not even sure what that means, "sour grapes metric". Talking about "overall performance" in the context of an x86 and the GA144 has no meaning. If it did I think the GA144 would win out because of the raw performance number of what, some 100,000 MIPS. If you want an app to base this on, I conceived of an app for tuning musical instruments. It would have used most of the GA144 processors as filters for a specific band (it could also be used as a fine grained equalizer) and used nearly all of the MIPS available. No, I never actually built is, but I did write some of the critical code sections to verify that it was practical. I estimated it would have used over 30,000 MIPS. One of the reasons I didn't pursue it was because this was a high enough number that it would not run off of a battery very long.... but I think it would have outlasted an i7 by many orders of magnitude. See how absurd this comparison is? >> The point is comparing an x86 to an F18A is *very* much apples and >> oranges with little value. > > Certainly. But it gives a perspective to the claim that the GA cores > are fast because of the simpler hardware. BTW, the Williamette could > do two dependent adds per cycle. I can't say I see your point. The comparison is exactly that the GA144 is very simple (as well as hand optimized) and can get a lot more speed than it would if it were more complex such as a conventional MCU. To get comparable speeds *much* more complexity is required as is found in the very heavily pipelined processors. So where is the perspective issue? What is the point of comparing CPUs so vastly different in all aspects, not the least of which is purpose? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-22 16:44 +0000 |
| Message-ID | <2014Sep22.184406@mips.complang.tuwien.ac.at> |
| In reply to | #33466 |
rickman <gnuarm@gmail.com> writes:
>On 9/20/2014 11:31 AM, Anton Ertl wrote:
>> Sure, and the GA chips are not getting the "theoretical performance
>> you might get if all that circuitry were doing something useful 100%
>> of the time", either, because they are also waiting for some things.
>> That how things work. But utilization is not really the most useful
>> metric. Overall performance is one people care about, or performance
>> per watt. Utilization is a sour grapes metric.
>
>I'm not even sure what that means, "sour grapes metric".
When your own stuff is not competetive on the metrics that count, you
use some other metric like utilization (which is useful for
understanding performance or efficiency, but not for measuring it).
"Sour grapes" are from the fable "The Fox and the Grapes"; if you
cannot achieve performance or efficiency, ignore it and claim that you
are king at an alternative metric; ok, the fable is not quite fitting
for this situation (then the fox would have eaten some thistle and
claimed that it is much better than grapes), but I think that the gist
should be clear.
>Talking about
>"overall performance" in the context of an x86 and the GA144 has no
>meaning. If it did I think the GA144 would win out because of the raw
>performance number of what, some 100,000 MIPS.
"Peak performance" is another such metric. It's not peak performance
people care about, but application performance.
>If you want an app to base this on, I conceived of an app for tuning
>musical instruments. It would have used most of the GA144 processors as
>filters for a specific band (it could also be used as a fine grained
>equalizer) and used nearly all of the MIPS available. No, I never
>actually built is, but I did write some of the critical code sections to
>verify that it was practical. I estimated it would have used over
>30,000 MIPS. One of the reasons I didn't pursue it was because this was
>a high enough number that it would not run off of a battery very
>long.... but I think it would have outlasted an i7 by many orders of
>magnitude.
Cool. Nice to see that someone found a way to make good use of the
GA. Would be even cooler if there was no such early showstopper.
>>> The point is comparing an x86 to an F18A is *very* much apples and
>>> oranges with little value.
>>
>> Certainly. But it gives a perspective to the claim that the GA cores
>> are fast because of the simpler hardware. BTW, the Williamette could
>> do two dependent adds per cycle.
>
>I can't say I see your point. The comparison is exactly that the GA144
>is very simple (as well as hand optimized) and can get a lot more speed
>than it would if it were more complex such as a conventional MCU. To
>get comparable speeds *much* more complexity is required as is found in
>the very heavily pipelined processors.
The point is that there are CPUs in 0.18u where the clock frequency is
a lot higher, so saying that the GA144 runs at a very high clock
frequency is just wrong. The claim was also that the simplicity
allowed this "very high frequency", while you now claim that more
complexity allows higher clock rates.
- 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-22 15:52 -0400 |
| Message-ID | <lvpun2$5be$1@dont-email.me> |
| In reply to | #33511 |
On 9/22/2014 12:44 PM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> On 9/20/2014 11:31 AM, Anton Ertl wrote: >>> Sure, and the GA chips are not getting the "theoretical performance >>> you might get if all that circuitry were doing something useful 100% >>> of the time", either, because they are also waiting for some things. >>> That how things work. But utilization is not really the most useful >>> metric. Overall performance is one people care about, or performance >>> per watt. Utilization is a sour grapes metric. >> >> I'm not even sure what that means, "sour grapes metric". > > When your own stuff is not competetive on the metrics that count, you > use some other metric like utilization (which is useful for > understanding performance or efficiency, but not for measuring it). > "Sour grapes" are from the fable "The Fox and the Grapes"; if you > cannot achieve performance or efficiency, ignore it and claim that you > are king at an alternative metric; ok, the fable is not quite fitting > for this situation (then the fox would have eaten some thistle and > claimed that it is much better than grapes), but I think that the gist > should be clear. > >> Talking about >> "overall performance" in the context of an x86 and the GA144 has no >> meaning. If it did I think the GA144 would win out because of the raw >> performance number of what, some 100,000 MIPS. > > "Peak performance" is another such metric. It's not peak performance > people care about, but application performance. > >> If you want an app to base this on, I conceived of an app for tuning >> musical instruments. It would have used most of the GA144 processors as >> filters for a specific band (it could also be used as a fine grained >> equalizer) and used nearly all of the MIPS available. No, I never >> actually built is, but I did write some of the critical code sections to >> verify that it was practical. I estimated it would have used over >> 30,000 MIPS. One of the reasons I didn't pursue it was because this was >> a high enough number that it would not run off of a battery very >> long.... but I think it would have outlasted an i7 by many orders of >> magnitude. > > Cool. Nice to see that someone found a way to make good use of the > GA. Would be even cooler if there was no such early showstopper. Showstopper??? I guess you mean that I found early on that it wouldn't suit the app because of the high power drain. In reality this was a way to do the job easily, but very inefficiently, a rather brute force approach. Bottom line is that I have *yet* to find an app the GA144 is really suited for. At one point I thought the GA144 might be a good candidate to replace the FPGA and CODEC on a board I currently sell. This job can't be done with an MCU because there is an SPI like interface that just can't be done without logic in an FPGA. MCUs just aren't fast enough. I thought the GA144 should be able to handle it though. Then I got a last time buy notification on the FPGA (normally a rare event) and looked at the GA144 a bit harder. Seems it won't do this interface any better than it does with SDRAM. So my customer bought 3,000 of the FPGAs... >>>> The point is comparing an x86 to an F18A is *very* much apples and >>>> oranges with little value. >>> >>> Certainly. But it gives a perspective to the claim that the GA cores >>> are fast because of the simpler hardware. BTW, the Williamette could >>> do two dependent adds per cycle. >> >> I can't say I see your point. The comparison is exactly that the GA144 >> is very simple (as well as hand optimized) and can get a lot more speed >> than it would if it were more complex such as a conventional MCU. To >> get comparable speeds *much* more complexity is required as is found in >> the very heavily pipelined processors. > > The point is that there are CPUs in 0.18u where the clock frequency is > a lot higher, so saying that the GA144 runs at a very high clock > frequency is just wrong. The claim was also that the simplicity > allowed this "very high frequency", while you now claim that more > complexity allows higher clock rates. I don't agree. They get a high clock frequency by heavy pipelining. They put very few transistors between the logic registers and have a *lot* of logic registers. Comparing an x86 class CPU to a GA144 in this sense is no more valid than saying the GA144 runs the ADC at 5 GHz and so it runs faster than the x86. The significance of the GA144 is in the fact that they got the speed (however fast it is) by *simplicity* rather than adding complexity. Don't focus on the numbers, focus on the meaning of the statement. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-09-30 00:08 +0200 |
| Message-ID | <m0cl95$38g$1@online.de> |
| In reply to | #33461 |
Anton Ertl wrote: > Certainly. But it gives a perspective to the claim that the GA cores > are fast because of the simpler hardware. BTW, the Williamette could > do two dependent adds per cycle. And it should be noted that the GA144 core takes two cycles for a full add (with all the carry propagation)... What we shouldn't ignore is that GA144 is using a standard TSMC process, which has significantly slower transistors than the Intel and AMD processes of the 0.18µ ara, and using special low-voltage-swing processes that explain even more performance difference. For what's it's worth: I've had a b16 in 0.18µ (it was a demonstration prototype), and this was the "small" version, where the ALU is made deliberately small instead of fast, and it was synthesized with size optimization only - speed was "don't care". The result was worst case speed was 250MHz, that means "10% less voltage, slow process, at 125°C". The "fast" version of b16 easily got two times the speed, which means 500MHz worst case. Best case typically is twice as fast as worst case, and typical (25°C, standard voltage) is geometrically in between, which would be ~700MHz. That is just Verilog and standard cells, and bloatware synthesizers. Chuck uses hand-layout, and puts a lot of work in every core, and his speed result is just about as good as mine. The SRAM from the SRAM compiler is considerable faster than Chucks memory block (I remember 4ns for worst case access). I think it's impressive what Chuck can do with his do-it-all-yourself approach, but claims that this approach is much better (in terms of results) than the bloated standard process flow are wrong. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-20 04:26 -0400 |
| Message-ID | <lvjdp1$k14$1@dont-email.me> |
| In reply to | #33439 |
On 9/19/2014 10:42 AM, Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: >> An additional comment. The Mill project effectively does something >> similar to a circular stack with its moving stack. > > I think of Mill as an unusual register machine rather than a stack > machine, since the "belt" requires random access. GA-style stack > machines don't have any way to access the stack interior, which > simplifies the hardware (no bypass network, if I'm using the term > correctly: ALU inputs are always the two registers TOS and NOS) and > makes it possible to run at very high frequencies on older processes > (the GA is 700 mhz on 0.18 micron cmos). > > The circular stack "feature" of letting you fill the stack with a > constant and then have an endless supply of that constant doesn't seem > so useful, but you can save a few program bytes by not having to clean > up old stack debris in some situations. The circular stack has similar uses in other situations. You can fill the stack with more constants than one and use them repeatedly with the stack working its way around and around. You simply have to not let any detritus make it's way into the circular part of the stack. I have written code like this for a FIR filter. The number of constants has to be a power of two to be very useful, 1, 2, 4 or 8, not just 1. Most people think of the GA144 in the same terms they do their Forth systems running on an x86. I feel the GA144 is best thought of more like hardware such as an FPGA. The nodes have too little memory to be useful for any large programs, heck, the tiniest of MCUs have more RAM than the F18 and *way* more program space. Sometimes I really just can't understand the people at GA. Instead of focusing on what developers might want in a product, they seem to put their effort into adding bandaids. I believe they have an Ethernet interface that uses some large number of nodes only does 10 Mbps and is not very complete. There are tons of $5 MCUs that provide a complete Ethernet interface running at 100 Mbps and uses relatively little of the CPU, depending on your traffic rate of course. In a way, the GA144 is like a basket of kittens. Each one is so cute you just can't resist... but who knows what to do with 144 of them? :] -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-22 10:48 -0400 |
| Message-ID | <542036A7.FFCE36C8@bytecraft.com> |
| In reply to | #33439 |
Paul Rubin wrote: > Walter Banks <walter@bytecraft.com> writes: > > An additional comment. The Mill project effectively does something > > similar to a circular stack with its moving stack. > > I think of Mill as an unusual register machine rather than a stack > machine, since the "belt" requires random access. GA-style stack > machines don't have any way to access the stack interior, which > simplifies the hardware (no bypass network, if I'm using the term > correctly: ALU inputs are always the two registers TOS and NOS) and > makes it possible to run at very high frequencies on older processes > (the GA is 700 mhz on 0.18 micron cmos). > > The circular stack "feature" of letting you fill the stack with a > constant and then have an endless supply of that constant doesn't seem > so useful, but you can save a few program bytes by not having to clean > up old stack debris in some situations. > > Chlorophyll has a fair amount of unusual compiler technology so > I thought you might like the paper. I did a quick code generator for a mill type architecture and found no real advantage over writing code for a general purpose micro. The ISA is more complex (not as bit efficient) and stack offset calculations are potentially more hardware expensive. An alternative circular stack design that stores variables in ram space and the code generator that tracks addressing does marginally better. The Chlorophyll paper was an interesting read. w..
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-22 12:26 -0500 |
| Message-ID | <2PSdnfbPXLhexr3JnZ2dnUU7-Q-dnZ2d@supernews.com> |
| In reply to | #33508 |
Walter Banks <walter@bytecraft.com> wrote: > Paul Rubin wrote: > >> Walter Banks <walter@bytecraft.com> writes: >> > An additional comment. The Mill project effectively does something >> > similar to a circular stack with its moving stack. >> >> I think of Mill as an unusual register machine rather than a stack >> machine, since the "belt" requires random access. GA-style stack >> machines don't have any way to access the stack interior, which >> simplifies the hardware (no bypass network, if I'm using the term >> correctly: ALU inputs are always the two registers TOS and NOS) and >> makes it possible to run at very high frequencies on older processes >> (the GA is 700 mhz on 0.18 micron cmos). >> > > I did a quick code generator for a mill type architecture and found > no real advantage over writing code for a general purpose micro. I thought the advantage of the Mill was that you get register renaming essentially for free, gaining superscalar preformance without needing all the complex renaming logic in a more conventional architecture. That sounds reasonable to me. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-22 17:07 -0400 |
| Message-ID | <54208F99.D6D181C4@bytecraft.com> |
| In reply to | #33512 |
Andrew Haley wrote: > Walter Banks <walter@bytecraft.com> wrote: > > Paul Rubin wrote: > > > >> Walter Banks <walter@bytecraft.com> writes: > >> > An additional comment. The Mill project effectively does something > >> > similar to a circular stack with its moving stack. > >> > >> I think of Mill as an unusual register machine rather than a stack > >> machine, since the "belt" requires random access. GA-style stack > >> machines don't have any way to access the stack interior, which > >> simplifies the hardware (no bypass network, if I'm using the term > >> correctly: ALU inputs are always the two registers TOS and NOS) and > >> makes it possible to run at very high frequencies on older processes > >> (the GA is 700 mhz on 0.18 micron cmos). > >> > > > > I did a quick code generator for a mill type architecture and found > > no real advantage over writing code for a general purpose micro. > > I thought the advantage of the Mill was that you get register renaming > essentially for free, gaining superscalar preformance without needing > all the complex renaming logic in a more conventional architecture. > That sounds reasonable to me. Partly correct. Starting from scratch the compiler code generator is much simpler for the mill but it isn't a huge win overall at least in the tests I did. They did recognize one thing and that is that most local variables have a statistically limited lifetime and they found a way to incorporate that information into their ISA. They pay a price for stack relative addressing one way or another in the implementation. One thing the mill did was to focus on alternatives for local variables and alternatives to large register sets and its impact of ISA encoding size. w..
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-17 07:20 +0000 |
| Message-ID | <2014Sep17.092044@mips.complang.tuwien.ac.at> |
| In reply to | #33394 |
Walter Banks <walter@bytecraft.com> writes:
>Paul Rubin wrote:
>
>> Walter Banks <walter@bytecraft.com> writes:
>> > I am working on a code generator for a stack processor.
>> > Who better to ask about real stack requirements than a forth group.
>> > The question is what is the expected stack requirements for a
>> > forth implementation?
>>
>> Is your processor intended to run Forth programs written in Forth style?
>> If not, the info you ask may not really be useful. Forth programs tend
>> to be globally hand optimized to re-use stack slots and keep the stack
>> traffic smooth.
>
>The original source is not forth. The code generator is starting with full
>application program data flow information and maps the code on the
>execution engine. The forth experience here is relevant and probably
>could be used in the code generator. The code generator uses a rule
>based expert system that can utilize and evaluate several competing
>strategies and select the one most appropriate for the code
>generation, "this time"
>
>The kind of code generation "tricks" when programmers hand code
>applications can be easily made part of the overall code generator.
I have my doubts about that. In particular, I have yet to see a good
stack allocation scheme across basic blocks.
Anyway, if your source language is Algol-like, I doubt very much that
the code you produce will look like and behave like hand-written Forth
code.
- 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-17 17:03 -0400 |
| Message-ID | <5419F72B.F5EC2F16@bytecraft.com> |
| In reply to | #33401 |
Anton Ertl wrote: > Walter Banks <walter@bytecraft.com> writes: > > > >The kind of code generation "tricks" when programmers hand code > >applications can be easily made part of the overall code generator. > > I have my doubts about that. In particular, I have yet to see a good > stack allocation scheme across basic blocks. > > Anyway, if your source language is Algol-like, I doubt very much that > the code you produce will look like and behave like hand-written Forth > code. I partly agree with you in the sense that forth has a somewhat unique source style and developer thought process. Past that there is potentially a lot to learn from folks who have structured their code around stack machines. (virtual and real) The reason for asking the question here was not so much to achieve a forth like result but to learn from a different thought process on utilizing an different underlying architecture. I have worked on the ISA of quite a few commercial processors and code generators to support them. Most are not orthogonal ISA's. I am less concerned at this point about implementation than creating a real implementation plan. I have a running test compiler. One thing that compilers are good at is accounting and if there is an advantage to creating a stack allocation scheme across basic blocks I think it could be done. The simple question is "why do it?" This is not a challenge but a real question. 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? I am not trying to argue about competing alternatives but the simpler if people are using forth (and it has been around for a long time) they are doing it for a reason and I am trying to understand in a deeper way, why. w..
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-18 11:40 +0000 |
| Message-ID | <2014Sep18.134054@mips.complang.tuwien.ac.at> |
| In reply to | #33404 |
Walter Banks <walter@bytecraft.com> writes:
>One thing that compilers are good at is accounting and if there is an
>advantage to creating a stack allocation scheme across basic blocks
>I think it could be done. The simple question is "why do it?" This is
>not a challenge but a real question.
Ok, let's consider a Java VM-like instruction set. Keeping a value
(or two) in a stack item within a loop can reduce the number of
(dynamically executed as well as static) instructions significantly.
E.g., it reduced the inner loop of the sieve benchmark from 11
instructions (7 of which are locals accesses) to 8 (with two locals
accesses and two stack manipulations), giving a speedup of 20% with
the JDK Java VM interpreter.
In contrast, we found that allocating locals to the stack within basic
blocks does not reduce the number of instructions and is only
profitable if you assume that a local variable access is significantly
more expensive than a stack manipulation instruction; in essence the
basic block optimization replaced a locals loads with an instruction
that corresponds to Forth's DUP or TUCK, so if the stack manipulations
cost the same as a locals load, this does not buy you anything.
This work comes from:
@InProceedings{maierhofer&ertl98,
author = "Martin Maierhofer and M. Anton Ertl",
title = "Local Stack Allocation",
crossref = "cc98",
pages = "189--203",
url = "http://www.complang.tuwien.ac.at/papers/maierhofer%26ertl98.ps.gz",
abstract = "Considering the renewed interest in stack machines
(in particular, the Java Virtual Machine), efficient
execution of Algol-family languages on this class of
hardware becomes increasingly important. Local
variable accesses in the source language should be
translated into stack accesses on the target machine
(in analogy to register allocation on register
machines).\par In this paper we explore such stack
allocation techniques for basic blocks. We present
some improvements to Phil Koopman's \emph{stack
scheduling}, add an instruction scheduler and
compare the result with an optimal stack allocation
and instruction scheduling strategy. Stack
scheduling in cooperation with depth first postorder
instruction scheduling produces results close to the
optimum. The optimizations discussed in this paper
are profitable only for stack hardware where stack
manipulation operations are faster than local
variable accesses."
}
@Proceedings{cc98,
title = "Compiler Construction (CC'98)",
booktitle = "Compiler Construction (CC'98)",
year = "1998",
key = "CC'98",
editor = "Kai Koskimies",
OPTvolume = "1383",
OPTseries = "LNCS",
publisher = "Springer LNCS~1383",
address = "Lisbon"
}
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.
>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.
* 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).
* 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%20of%20x86%20Instruction%20Set%20Usage%20for%20DOS%20Windows%20Applications%20and%20Its%20Implication%20on%20Superscalar%20Design.pdf>
- 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-19 09:56 -0400 |
| Message-ID | <541C361D.FD82D130@bytecraft.com> |
| In reply to | #33420 |
Anton Ertl wrote: Thanks for the comments and links. Food for thought on this afternoon's travel. w..
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2014-09-22 10:54 -0400 |
| Message-ID | <54203843.BD257924@bytecraft.com> |
| In reply to | #33420 |
[Multipart message — attachments visible in raw view] — view raw
Anton Ertl wrote:
> Walter Banks <walter@bytecraft.com> writes:
> >One thing that compilers are good at is accounting and if there is an
> >advantage to creating a stack allocation scheme across basic blocks
> >I think it could be done. The simple question is "why do it?" This is
> >not a challenge but a real question.
>
> Ok, let's consider a Java VM-like instruction set. Keeping a value
> (or two) in a stack item within a loop can reduce the number of
> (dynamically executed as well as static) instructions significantly.
> E.g., it reduced the inner loop of the sieve benchmark from 11
> instructions (7 of which are locals accesses) to 8 (with two locals
> accesses and two stack manipulations), giving a speedup of 20% with
> the JDK Java VM interpreter.
>
> In contrast, we found that allocating locals to the stack within basic
> blocks does not reduce the number of instructions and is only
> profitable if you assume that a local variable access is significantly
> more expensive than a stack manipulation instruction; in essence the
> basic block optimization replaced a locals loads with an instruction
> that corresponds to Forth's DUP or TUCK, so if the stack manipulations
> cost the same as a locals load, this does not buy you anything.
>
> This work comes from:
>
> url = "http://www.complang.tuwien.ac.at/papers/maierhofer%26ertl98.ps.gz",
>
>
> @Proceedings{cc98,
> title = "Compiler Construction (CC'98)",
> booktitle = "Compiler Construction (CC'98)",
>
Thanks for the links.
>
> 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.
> >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.
> * 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.
> * 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?
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)
w..
[toc] | [prev] | [next] | [standalone]
Page 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web