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 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-07 04:49 -0400 |
| Message-ID | <m109fo$2f1$1@dont-email.me> |
| In reply to | #33719 |
On 10/6/2014 1:57 PM, Bernd Paysan wrote: > rickman wrote: >>>> I don't know that I would use the opinions of students as a good metric. >>>> Their skill levels are fairly low compared to professional >>>> programmers. I expect their tastes will change as their skill levels >>>> change. >>> >>> I don't think so. Preferrences are set pretty early in education. >> >> We aren't talking about "preferences", > > You said "taste". That's a "preference", not a "skill set". Actually you quoted me saying "skill levels" just above, but whatever. The point is their work methods will grow and change. Is that better terminology? >> we are talking about skill sets. >> I know my techniques of design and debug have changed several times >> over my career. > > The problem is: if the mainstream doesn't have that option (of a Forth-like > environment), they will probably never see it. I think you are drifting now. We were talking about type checking. I'm not sure how this ties in. >> I am familiar with the Doherty threshold... lol The compile step is a >> natural change of pace in thinking, so the same issue you have in a GUI >> doesn't apply to the same extent. When changing from editing to >> compile/test the mode of thinking is different so a delay of a small >> number of seconds is much more readily accepted without impact on >> performance. > > I don't see it as that. The compile step always gets into my way of > thinking. If you see coding and testing as something separate, you already > have a mindset that doesn't allow you to get into the "flow" Forth > programmer experience. Therefore, you don't know what I'm talking about. Ok, then I freely acknowledge I don't know what is in your mind. Care to explain it in terms someone else can understand? >> There are several thresholds for this. The exact values are quoted >> differently, but anything less than about 0.3 seconds is normally not >> perceived as a delay. A delay less than about 3 seconds is tolerated >> without loosing focus, above 30 seconds is a significant disruption to >> workflow and often means the user leaves the task for another. >> >> As I said, my experience with both C compilers and VHDL compiles is that >> the delays are short enough they don't significantly impact my task >> completion time. I can't remember a compile that took anywhere near 30 >> seconds and often they are less than the 3 second attention threshold. >> Your experience may differ. > > Compiling Gforth after a make clean takes 43s on my core i7 here. That's > not a particularly large project... and the majority of the source code is > Forth. Compiling gforth.fi from the kernel + image sources takes 0.3s (that > includes relocating stuff, so actually the image sources are compiled three > times in this 0.3s). Ok, what is the relevance? You tend to throw stuff out there without explaining how it ties into the discussion. >>>>> And then you figure out that you urgently want some help from the >>>>> compiler, >>>>> because your programs all don't run. And the typecheck is giving that, >>>>> at least it is giving you the illusion of the compiler doing something >>>>> - complaining and making you change the program before you run it. >>>> >>>> I don't know about "illusion". I think the sort of problems I would >>>> have in VHDL from mismatched types can often be the sort that you spend >>>> significant debug time finding. >>> >>> Verilog is about 3 times as productive as VHDL for the same problem >>> space. >> >> I have never seen that substantiated... what do you base this on? > > John Cooley's competition was really funny: > > http://www.see.ed.ac.uk/~gerard/Teach/Verilog/manual/Example/lrgeEx2/cooley.html > > That was 90 minutes for a trivial task with 9 Verilog and 5 VHDL > participants. 5 fully functional netlists were produced, all of them from > Verilog code; the VHDL participats all failed. Two of them acutally > complained about being brought down by VHDL's type system: > > "Two of the VHDL designers, Prasad Paranjpe of LSI Logic and Jan Decaluwe of > Easics, both complained of having to deal with type conversions in VHDL. > Prasad confessed: "I can't believe I got caught on a simple typing error. I > used IEEE std_logic_arith, which requires use of unsigned & signed subtypes, > instead of std_logic_unsigned." Jan agreed and added: "I ran into a problem > with VHDL or VSS (I'm still not sure.) This case statement doesn't analyze: > "subtype two_bits is unsigned(1 downto 0); case two_bits'(up & down)..." But > what worked was: "case two_bits'(up, down)..." Finally I solved this problem > by assigning the concatenation first to a auxiliary variable."" > > There were other sources, but I forgot them. This is all early 90s stuff. Wow, I figured you would have something substantial. If this is your evidence I think it is a bit thin. I remember when this was done. I think the report you link to was a second try or maybe a third. The first try had organizational issues and I seem to recall that no one finished. Even in this trial the winning entry didn't pass the criteria. Your statement was that "Verilog is about 3 times as productive as VHDL". The evidence to say this is not true is that were it true, no one would still be using VHDL, even the US government (who often requires it on government contracts) would walk away from it. >>> The author of the code went through 5000 lines of code, to >>> replace all "+1" of these integers (he had several) with an "when 15 then >>> 0 else +1" idiom. >> >> Sounds to me like a very inexperienced newbie... > > You are repeating the standard VHDL bigot arguments John Cooley has been > collecting: If someone fails in VHDL, it's because he is a clueless newbie. No, I am saying there are right ways to write VHDL and wrong ways to write it. I made similar mistakes when I was a newbie. So I have first hand knowledge that it is a newbie mistake. I think anyone who cares to look at it objectively would understand that there were two mistakes made. The first was the coding error... the second was writing 5000 lines of code before touching the compile button... an even worse newbie mistake. Can you really claim that anyone who makes the second error isn't a newbie? > This was someone who taught VHDL to other people at Siemens HL. I feel sorry for Siemens... Ok, the guy isn't a newbie, he is just not very good at VHDL... > I'm not at > all convinced that his coding style is a good idea, and I think it's a bad > idea to teach this coding style to others. But that coding style is found > widely in the VHDL world. I've even seen people who later in their career > moved to Verilog keeping that coding style. > > Like you can write Fortran programs in any language, you can write VHDL > programs in any HDL. Ok... >> Why would anyone write >> 5000 lines of code before doing any simulation or even a test compile? > > He did. The 5000 lines compiled, and synthesized (with a warning of 500 > latches created from asynchronous processes... doh!). All those corner > cases in which the VHDL simulator throw an exception were found by the test > code I had written. He never got the counters to wrap around in his simulation??? I think it is very clear this is all cockpit error. >> How is that a problem with the language? > > Your assumptions about the reasons were all wrong, so the conclusion that it > isn't a problem of the language therefore is very likely to be wrong, too. Ok, if you say so... >> Of course no one ever has any problems learning Forth... lol > > Again: He wasn't a clueless newbie at all. No, he was just clueless.. That is obvious to anyone at all proficient in VHDL. Was this a long time ago, like the Cooley competition? >> Sounds like you are not at all familiar with VHDL. If you want a modulo >> 16 value you can use a 4 bit unsigned signal. This is easily converted >> to an integer when you use it to index an array. I believe the form for >> that is to_integer(). Not so hard - is it? > > It's not about me, I didn't make that design choice of using an integer > subtype. The actual problem you refuse to acknowledge is that in a HDL you > want an integer mod 2^n type, because that's what you use to build your > logic of. Verilog gives you that (it is the only synthesizable type it > has), VHDL denies you that. No, you didn't make the decision, but you are judging the language on what he decided and you don't know enough about the language to know the problem was all user issues, not the language in any way. I am pretty sure I learned about the wrap around thing the first time I used integers. It didn't take me 5000 lines of code to figure it out either because I simulate each of my modules in much the same way you test your forth words. >> You have your preferences based on your experiences. I believe you >> would have had a similar experience if you didn't know Forth and started >> working at a company that used Forth, but didn't really get it and >> misused it extensively. > > The problem is that it was the professionals who ought to know who misused > it extensively. The teaching material of HDL on my university was all VHDL, > and the TU Munich is one of the best universities in Germany, especially on > these electro engineering topics. I chose Verilog, because I looked at > teaching material on the internet, and the Verilog stuff all makes way more > sense. Ok, but that is your preference, not a problem with the tools. I am very proficient with VHDL when I am working with it. I don't think I would be any less proficient with Verilog if I used it much, but it has "gotchas" that I have not learned so I shy away... so far. I also like some of the features in VHDL which are useful in test benches. > I then switched an entire small company from VHDL to Verilog in a few > months, and all these VHDL coders liked Verilog. They weren't forced to, > they were convinced. And not by my arguments, we had bought a "Verilog VHDL > side by side" book to make the transition. "HDL Chip Design" by Douglas J. Smith by any chance? I have that book. I haven't used it extensively though. >> What is the incentive to write "big" modules in VHDL? I don't typically >> write large ones. > > The incentive that it is more boilerplate: You need architecture, > implementation and instantiation, which all takes way more to type in, > especially for small modules, where the implicit port passing of Verilog is > acceptable. > > Maybe we also disagree on what is "large" or "small"... Boilerplate is just that, boilerplate and doesn't take much time to deal with. I have editor macros that help me turn architecture port lists into signal declarations as well as port mappings (or back). Making changes is not as much fun, but port lists are a pita in any language... hence the stack in Forth, no? Yes, I'll acknowledge that VHDL is more verbose than Verilog, but it isn't even close to cutting productivity to a third. >> The only "incentive" I find is that I test all my >> modules with a test bench, so I have to construct that framework. I >> suppose in Forth you would manually type in the tests, but that wouldn't >> fly in a production environment where you need to document your testing, >> so each word needs a word to test it... thoroughly. > > You manually type in the tests while you develop the word. And if you then > want to have a regression test, you cut&paste the tests out of the history > file - or the command line, because there, you have the result, too. And > then wrap them up in a facility like ttester.fs - this is not a word which > tests another word. Maybe HDL and Forth is not a good comparison. I don't see manual entry as a way to test code well. Each test needs to be given enough thought that it tests the entire set of requirements. It needs to be documented so that someone following in the footsteps can understand what was being done (usually me in my case, but I don't remember what code did after two or three years). So I write my tests the same way I write my code. Sure it takes longer, but I need something I can return to later and understand. >> I mean I write the test bench the same way you would write your test >> code in Forth, it reports a pass/fail, not a number for the user to >> interpret if that was a valid response. In an HDL you need to consider >> values of signals at various times. This is very hard to do without a >> good test bench or a lot of manual examination of detailed waveforms. >> Not very much like software really. > > There's something I don't understand about many hardware designer, and that > is this "not very much like software" stuff. My stuff usually is pretty > small, and involves a microcontroller or similar microcode sequencer. This > stuff is behaving like software, it is pretty fast to develop, it is robust > and small, easy to get bug-free, doesn't consume much space on the chip, > etc. And it just works a lot better than the "not like software" big state > machines of the hardware engineers. Please reread the paragraph I wrote. I said I write test benches the *same* way you might test Forth code... not differently. > And yes, I've written fancy test benches for these big state machines of the > hardware engineers, too - I pretty well know what it takes to make them. > You know what happened with the big state machine of this coworker? The > other two people in the team, me and another VHDL guy, got fed up with > debugging this hopeless stuff, and I designed a small CPU, which my coworker > implemented. This did the same job in much less gate space, but the higher > up bosses shelfed that approach, because our rescue came too late: The > entire project had been so much out of budget that it was completely > shelfed. I then left Siemens HL (I was just a consultant, and hired for > that particular project), I think our approach was rescued a few months > later. I don't follow. Every time you find someone who is not good at their job, you blame it on the tools they use. >> But if you are testing your code in small pieces it will be pretty >> obvious where the problem is. If the tool is checking stack effects at >> compile time, it surely can tell you which work has the problem. >> Otherwise what is it checking? > > It is checking the whole definition, all words together. One of these words > doesn't have the stack effect I'm thinking it should have, and that's what > causes the problem. However, the compiler can't know what I'm thinking, > therefore, it can't tell me which particular word causes the problem. > > That's not a problem if your definition is just using one single word. But > that's the silly cornercase ;-). I don't understand. When I write code, I test in small increments. Why is this being coded in large blocks before being compiled or tested? >> You make claims about Verilog, but I would like to see some evidence >> that isn't anecdotal. That was one of my problems trying to justify >> Forth in the workplace. There isn't any real info on it's advantages, >> it is all anecdotal. > > I don't think that e.g. the stuff Paul Benett does qualifies as "anecdotal" > - he has all his certificates to proof that his high reliability stuff > really is high reliable. I think people just like to dismiss reports that > don't fit into their believe system as "anecdotal". What does that have to do with Verilog and VHDL??? > I've recently watched a presentation about getting towards scientific > analysis of software engineering, i.e. providing solid studies instead of > all the anecdotal evidence we have, and the conclusion was that solid > studies cost an awful lot (it's just like a phamaceutical trial study). But > the results of these few solid studies we actually have, all back up methods > we have used in Forth for 40 years. Dismissing them, even though several of > these methods are now backed up by solid studies is silly. I'd love to see references. >> Actually, there are a number of times the lack of type checking will get >> you into trouble in Verilog. The system makes assumptions about what >> you are trying to do and you need to be *completely* aware of those >> assumptions in all cases or it doesn't work right. > > Yes, that is true. That is true for every programming language - you always > have to be completely aware of everything. The assumptions Verilog makes > are very straight-forward and simple, which is why it doesn't take long to > learn - the "everything" space is much less than with VHDL's contrived type > system, which gives you almost everything, except the thing you actually > need. I don't even know what that means. >> So Verilog also has >> a learning curve. The difference is the VHDL issues slow you down until >> you learn to deal with them. Verilog issues create faulty code until >> you learn to deal with them. Verilog doesn't "just work". > > You need to be completely aware that all bit vectors in Verilog are mod 2^n > numbers, that bits and bit vectors can be assigned to each other, > concatenated together forming another bit vector, and you can select parts > of bit vectors, creating new bits or bit vectors (depending on the selection > style). That's all. That's a natural fit to what you want in a HDL. > VHDL's type system doesn't fit, and therefore, it always gets into your way, > newbie or expert. And the resulting code doesn't work, even though the VHDL > bigot always tells you that the compiler catches all bugs. That's, because > the VHDL bigot took a week to get his code to compile, and then is too > exhausted to run extensive tests. > > I did run these tests, and they found tons of bugs, in the code declared > bug-free by the VHDL bigot, because he finally managed to compile it > (because it took so long to make it compile! Proof by effort!). It wasn't. > The "when 15 then 0 else +1" wasn't the only type system cockup this code > had. I'm not sure which VHDL "bigot" you are talking about, but again, the guy was a poor designer... that doesn't mean the tools were bad. > Your assumption is when you make an explicit typecast, you are aware of what > you are doing. With a type system with std_logic, std_ulogic, int, subsets > of int, tuples, and whatnot, you can't get your head around all this mess. > You don't know what you are doing. You are inserting typecasts to make the > damn'd thing compile. Maybe that is what people who don't know what they are doing do... but that isn't the language. You can get yourself into trouble very quickly with Verilog or Forth if you don't know what you are doing. I will admit that VHDL is not as simple as I would like it. But it is not so hard to learn. I was confused early on by having bad teachers, likely similar to the guy you are talking about as being an "expert". But with time and experience I discovered realities and can code pretty well now. I even taught someone else to code in VHDL. > In Verilog, when you concat two bit vectors, the result is not a tuple, > which is type-incompatible to everything else, it's just another bit vector. > It just works - the default behavior fits the assumption you make about how > it should work. In VHDL, it just doesn't work. And it's not just me who > can't get his head around VHDL. I don't know what you are talking about now. I don't use bit vectors for anything. These days I usually use signed, unsigned, integers or sometimes Boolean. Once in awhile I use enumerated. I don't have any trouble concatenating values and using them for assignments or comparisons. You may have seen problems with string literals in older versions of VHDL. Back in VHDL-1987 there was a problem where the compiler couldn't tell if you meant the string literal to be this type or that type and you had to cast it. But that has been fixed for what, two decades (VHDL-1993)? > I know that a lot of people can only think complex, and can't find simple > solutions. Maybe they also don't *want* to have a simple solution. But > nonetheless, the complexity they create doesn't work. Ok. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-07 16:21 +0200 |
| Message-ID | <m10stb$fh9$1@online.de> |
| In reply to | #33726 |
rickman wrote: > Your statement was that "Verilog is about 3 times as productive as > VHDL". The evidence to say this is not true is that were it true, no > one would still be using VHDL, even the US government (who often > requires it on government contracts) would walk away from it. This is a very bad argument. People are doing all sorts of idiotic stuff, reducing their productivity all the time. Especially government contracts contain lots of silly requirements, making things way more expensive than they ought to be. > No, I am saying there are right ways to write VHDL and wrong ways to > write it. I made similar mistakes when I was a newbie. So I have first > hand knowledge that it is a newbie mistake. I think anyone who cares to > look at it objectively would understand that there were two mistakes > made. The first was the coding error... the second was writing 5000 > lines of code before touching the compile button... an even worse newbie > mistake. He didn't. He did write about a 100 lines per hitting the compile button, and he tested all his stuff with the tests he had in mind. All those "silly beginner mistakes" passed the compiler (yes, this "the typechecker will find the errors for you" compiler), even passed his tests, and were found by my tests. There was a lot of struggling, because each time my tests found a bug, he started arguing that my tests were wrong. He was quite confident of his professional status. > Can you really claim that anyone who makes the second error isn't a > newbie? No, I would completely agree with you, but you had been pulling a straw man - that's not what he did. Writing 5000 lines even with hitting the compile button regularly, and even with testing everything is still a mistake, but it's no longer a beginner mistake. It's stuff a lot of professionals do their entire life. I've been sitting next to him and watched him struggle with VHDL's type checker, and it did take a week of work to get all the compile errors out - but that means it took an hour or two every day, compiling a few hundret lines. -- 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-10-08 05:43 -0400 |
| Message-ID | <m1310n$vum$1@dont-email.me> |
| In reply to | #33728 |
On 10/7/2014 10:21 AM, Bernd Paysan wrote: > rickman wrote: >> Your statement was that "Verilog is about 3 times as productive as >> VHDL". The evidence to say this is not true is that were it true, no >> one would still be using VHDL, even the US government (who often >> requires it on government contracts) would walk away from it. > > This is a very bad argument. People are doing all sorts of idiotic stuff, > reducing their productivity all the time. Especially government contracts > contain lots of silly requirements, making things way more expensive than > they ought to be. Perhaps people don't work optimally, but I think it would be very, very obvious if there were a factor of 3 in productivity. There would also be some verifiable proof. This is a situation where the absence of proof is proof of absence. The entire world can't be totally stupid. >> No, I am saying there are right ways to write VHDL and wrong ways to >> write it. I made similar mistakes when I was a newbie. So I have first >> hand knowledge that it is a newbie mistake. I think anyone who cares to >> look at it objectively would understand that there were two mistakes >> made. The first was the coding error... the second was writing 5000 >> lines of code before touching the compile button... an even worse newbie >> mistake. > > He didn't. He did write about a 100 lines per hitting the compile button, > and he tested all his stuff with the tests he had in mind. All those "silly > beginner mistakes" passed the compiler (yes, this "the typechecker will find > the errors for you" compiler), even passed his tests, and were found by my > tests. > > There was a lot of struggling, because each time my tests found a bug, he > started arguing that my tests were wrong. He was quite confident of his > professional status. Ok, so he is an idiot. That explains why his mistakes were not detected by the compiler and why he didn't find the error until he had written 5000 lines of code. What does this have to do with VHDL or any other language? >> Can you really claim that anyone who makes the second error isn't a >> newbie? > > No, I would completely agree with you, but you had been pulling a straw man > - that's not what he did. Writing 5000 lines even with hitting the compile > button regularly, and even with testing everything is still a mistake, but > it's no longer a beginner mistake. It's stuff a lot of professionals do > their entire life. Why do you keep talking about compiling the code? His mistake was not a syntax error or anything else the compiler can find. His mistake was in misusing the functionality. There is no ambiguity in how integers behave. > I've been sitting next to him and watched him struggle with VHDL's type > checker, and it did take a week of work to get all the compile errors out - > but that means it took an hour or two every day, compiling a few hundret > lines. The fact that he was struggling with the type checker that says the guy did *not* know how to code VHDL. duh! If nothing else, VHDL users *quickly* learn to use a subset of VHDL that works for them. I don't know why you can't see the difference between the poor user and a poor language. I can understand if it doesn't suit your style of working, but to condemn the language as if it were the problem is wrong. You have shown nothing about the language that causes poor productivity. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-09 02:35 +0200 |
| Message-ID | <m14l8m$fr9$1@online.de> |
| In reply to | #33749 |
rickman wrote: > Ok, so he is an idiot. That explains why his mistakes were not detected > by the compiler and why he didn't find the error until he had written > 5000 lines of code. What does this have to do with VHDL or any other > language? Because the entire argument about this typechecking nonsense is that the compiler will find the errors in the program. Fact is: It won't even find silly errors, but introduce *more* errors. Of course, and that's the standard bigot argument, only when abused by idiots. The clever people never make those mistakes. BTW: all the really clever people I know off create hardware by writing their own EDA system and then they directly produce the GDSII without HDL in between. But the whole point about a typesafe language *is* that it helps to find all the idiotic mistakes people make, by simply compiling the source. And yes, all my other coworkers did struggle with the typechecker of VHDL, as did I. I'm therefore for sure not in the league of intelligence to use VHDL properly, so I gave up and used Verilog instead (I gave up pretty soon). It worked rather well for me and for my coworkers at Mikron, who did the switch some time after I arrived there (already existing projects still in VHDL). One annoying thing about VHDL back then was that after you had synthesized it, you had a Verilog netlist, and to test your synthesized code, you needed a Verilog testbench, while to test your pre-synthesized code, you needed a VHDL testbench (cosimulation of Verilog+VHDL was so much of a PITA that you didn't want to do it; it took days to set up, was very fragile, took ages to compile, etc.). Good luck to have the two testbenches match, and of course, that also contributed to the additional effort of using VHDL. Verilog is also easier to learn, which means all those idiots out there (me included) will get it, while they will fail at VHDL. Seriously: Being easy to learn is a very important feature of a language, something Forth seems to be failing at, too. Verilog is pretty poor as testbench for complex systems, which is why SystemVerilog was introduced. But actually, most people use MatLab, C++, Python, or other languages (I used Forth and C++) for this purpose; these are much better, even though the integration into the simulator is worse (usually either run the program beforehand to generate test patterns, or afterwards to analyze the resuts of the run). However, Verilog excels at low-level stuff, where you operate with transistor primitives, drive strengths and such. I found that quite useful to model somewhat more complex IO pads, and VHDL simply can't do that stuff. Same issue as with gate level models: VHDL just doesn't go down to the low-level stuff. When I worked for Siemens HL (now Infineon), they used VHDL exclusively. When I search for digital design jobs there now, they still want VHDL knowledge, but also Verilog and SystemVerilog. Similar for other companies which had used VHDL exclusively in the past. The switch has been done, the requirement to know VHDL is usually, because maintaining legacy projects is part of your job. Or some government contract still requires you to use VHDL. The industry in Europe used to be pretty much VHDL only, when Cooley was doing his shootouts, but that's no longer the case. In any case, dismissing the "most Verilog participants did get a result that passed the test bench after 90 minutes, but none of the VHDL participants did" is still strong. There is a significant difference in programmer productivity, we all know that there are slow and fast programmers, the difference is significant. If there wasn't a big difference in VHDL and Verilog productivity, we would have had at least one of the VHDL participants to finish in time, or we wouldn't have so many Verilog participants to finish. The fact that the winning entry passed the testbench, but didn't meet the spec is a straw man: The criteria for winning was to pass the testbench. Not passing the spec. All hardware projects are like this: you tape out when you pass the testbench, because that's a doable job; passing the spec is impossible, because there's no formal method to proof that you did. Of course the elegant explanation why the VHDL programmers all didn't get a result is that they were idiots. I'm happy with that (choosing VHDL for such a contest shows you are an idiot), and you are happy with that (VHDL would have won if they weren't idiots). It's just like the usefulness of the typechecker: It's only useful for non-idiots (idiots will screw it up), but it is there to prevent idiots from making mistakes - as you said, you need to be more cunning to make a Verilog program to work, because there, no typechecker helps you. > I don't know why you can't see the difference between the poor user and a > poor language. That's victim blaming for me. You simply can't accept that the same people who had a lot of problems with VHDL did quite fine with Verilog, which shows that they, as people, weren't the problem. It was the language. If VHDL was an amplifier like Forth, i.e. a programming language which makes idiots perform worse, and cunning people perform better, then you wouldn't see the picture we have seen. You would have those 5 VHDL participants of Cooleys shootout win hands down, because they were the 5 cunning guys who use VHDL to beat the average Verilog people hands down, while these average people had chosen Verilog, because they can't do VHDL. We had seen that picture with those embedded programming shootouts, where the Forth teams won, and won, and won again, until the competition finally stopped being interesting, because they were more cunning, and their language of choice supported them - and the average programmer just didn't get the language. It might be that Verilog is an amplifier; however, given how much easier people perceive it is to learn, I much doubt it. -- 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-10-08 21:48 -0400 |
| Message-ID | <m14pio$2fq$1@dont-email.me> |
| In reply to | #33778 |
On 10/8/2014 8:35 PM, Bernd Paysan wrote: > rickman wrote: > >> Ok, so he is an idiot. That explains why his mistakes were not detected >> by the compiler and why he didn't find the error until he had written >> 5000 lines of code. What does this have to do with VHDL or any other >> language? > > Because the entire argument about this typechecking nonsense is that the > compiler will find the errors in the program. Yes, it will find type errors. > Fact is: It won't even find > silly errors, but introduce *more* errors. Hmmm... ok if you say so. Most of your arguments on this topic are statements without substantiation. You seem to be convinced of their accuracy regardless. I doubt there is much anyone can say to change your mind. > Of course, and that's the > standard bigot argument, only when abused by idiots. The clever people > never make those mistakes. BTW: all the really clever people I know off > create hardware by writing their own EDA system and then they directly > produce the GDSII without HDL in between. > > But the whole point about a typesafe language *is* that it helps to find all > the idiotic mistakes people make, by simply compiling the source. No, I don't recall anyone saying it will catch "all mistakes". > And yes, all my other coworkers did struggle with the typechecker of VHDL, > as did I. I'm sure that is a problem easily solved by a bit of education. I get the impression your use of VHDL was some time ago. If it was before numeric_std was in widespread usage then yes, you would have found the process of type conversion to be harder. Std_logic_vectors were not supported at all for math. Signed and unsigned types are much easier to use. But with more recent additions to the language even std_logic_vectors are math friendly. > I'm therefore for sure not in the league of intelligence to use > VHDL properly, so I gave up and used Verilog instead (I gave up pretty > soon). It worked rather well for me and for my coworkers at Mikron, who did > the switch some time after I arrived there (already existing projects still > in VHDL). One annoying thing about VHDL back then was that after you had > synthesized it, you had a Verilog netlist, and to test your synthesized > code, you needed a Verilog testbench, while to test your pre-synthesized > code, you needed a VHDL testbench (cosimulation of Verilog+VHDL was so much > of a PITA that you didn't want to do it; it took days to set up, was very > fragile, took ages to compile, etc.). Good luck to have the two testbenches > match, and of course, that also contributed to the additional effort of > using VHDL. Again, this is not a problem with the language, this is a problem with a crappy tool. This must have been a *very* long time ago. I have used VHDL since around 1995 and I have never used tools that required any use of Verilog. Bizarre. What tools were these? > Verilog is also easier to learn, which means all those idiots out there (me > included) will get it, while they will fail at VHDL. Seriously: Being easy > to learn is a very important feature of a language, something Forth seems to > be failing at, too. You are fond of working with very limited data sets, so here is one to disprove your postulate. I have learned VHDL well and yet have not learned to use Verilog to the point I would prefer to use my code in a product. So 100% of my sample indicates Verilog is harder to learn. As I have mentioned before, Verilog has a set of aspects you need to learn about or you can produce buggy designs without realizing it. I don't recall the details and in fact I have never learned them all. You have acknowledged these aspects exist. Do you have a list written down somewhere? How did you teach your coworkers to use Verilog if you don't have this list? How did they learn about these issues? > Verilog is pretty poor as testbench for complex systems, which is why > SystemVerilog was introduced. But actually, most people use MatLab, C++, > Python, or other languages (I used Forth and C++) for this purpose; these > are much better, even though the integration into the simulator is worse > (usually either run the program beforehand to generate test patterns, or > afterwards to analyze the resuts of the run). However, Verilog excels at > low-level stuff, where you operate with transistor primitives, drive > strengths and such. I found that quite useful to model somewhat more > complex IO pads, and VHDL simply can't do that stuff. Same issue as with > gate level models: VHDL just doesn't go down to the low-level stuff. I wasn't aware that the Verilog standard covers things like drive strengths and transistor models. Can you refer me to info on this? Is this capability good enough to replace Spice? > When I worked for Siemens HL (now Infineon), they used VHDL exclusively. > When I search for digital design jobs there now, they still want VHDL > knowledge, but also Verilog and SystemVerilog. Similar for other companies > which had used VHDL exclusively in the past. The switch has been done, the > requirement to know VHDL is usually, because maintaining legacy projects is > part of your job. Or some government contract still requires you to use > VHDL. The industry in Europe used to be pretty much VHDL only, when Cooley > was doing his shootouts, but that's no longer the case. You are gleaning a large conclusion from very little information. I don't accept your conclusion that "the switch has been done". How many of these companies have said "all new designs are in Verilog?" > In any case, dismissing the "most Verilog participants did get a result that > passed the test bench after 90 minutes, but none of the VHDL participants > did" is still strong. There is a significant difference in programmer > productivity, we all know that there are slow and fast programmers, the > difference is significant. If there wasn't a big difference in VHDL and > Verilog productivity, we would have had at least one of the VHDL > participants to finish in time, or we wouldn't have so many Verilog > participants to finish. The fact that the winning entry passed the > testbench, but didn't meet the spec is a straw man: The criteria for winning > was to pass the testbench. Not passing the spec. All hardware projects are > like this: you tape out when you pass the testbench, because that's a doable > job; passing the spec is impossible, because there's no formal method to > proof that you did. I don't think the Cooley test was very useful or well controlled. Your statement was "Verilog is about 3 times as productive as VHDL". How many of the Verilog programmers finished in 30 minutes? I don't feel a need to continue to debate the Cooley test. If you wish to treat it as "proof" that "Verilog is about 3 times as productive as VHDL", then that is your opinion. > Of course the elegant explanation why the VHDL programmers all didn't get a > result is that they were idiots. I'm happy with that (choosing VHDL for > such a contest shows you are an idiot), and you are happy with that (VHDL > would have won if they weren't idiots). It's just like the usefulness of > the typechecker: It's only useful for non-idiots (idiots will screw it up), > but it is there to prevent idiots from making mistakes - as you said, you > need to be more cunning to make a Verilog program to work, because there, no > typechecker helps you. Judging from the comments made by a couple of them I think they were not professional programmers in the sense of banging out code every day. Anyone who has problems with type conversions in VHDL is not up to speed and should not be in anything remotely like the Cooley race. >> I don't know why you can't see the difference between the poor user and a >> poor language. > > That's victim blaming for me. You simply can't accept that the same people > who had a lot of problems with VHDL did quite fine with Verilog, which shows > that they, as people, weren't the problem. It was the language. Or the training. I assume now you are talking about the people you worked with who never figured out how to do type conversion or how to avoid needing type conversion. I could explain that topic in 15 minutes of instruction. > If VHDL was an amplifier like Forth, i.e. a programming language which makes > idiots perform worse, and cunning people perform better, then you wouldn't > see the picture we have seen. You would have those 5 VHDL participants of > Cooleys shootout win hands down, because they were the 5 cunning guys who > use VHDL to beat the average Verilog people hands down, while these average > people had chosen Verilog, because they can't do VHDL. We had seen that > picture with those embedded programming shootouts, where the Forth teams > won, and won, and won again, until the competition finally stopped being > interesting, because they were more cunning, and their language of choice > supported them - and the average programmer just didn't get the language. I remember the first time I heard the amplifier statement about Forth. I have often wondered if it is so much an amplifier as it is a filter. If you are a great programmer then you can deal with the various issues of Forth just as you could deal with the various issues of any other language... except maybe VHDL which seems to be a fatal blow to some. If you are a lesser programmer I think the issues of Forth drag you down. Heck, you like statistical evidence so much, Forth has always been a back water language in terms of popularity and it has dropped off over the years. Does that mean it is a poor choice of language? There seem to be a huge number of people who try it and simply drop it out of pure frustration. So Verilog is like C and VHDL is like Ada^H^H^H Forth? > It might be that Verilog is an amplifier; however, given how much easier > people perceive it is to learn, I much doubt it. I won't argue that Verilog is not quicker to learn. I just think most of your bias against VHDL is based on ancient experiences using poor tools. I won't recommend that you try it again because I think it is just against your grain no matter how well others are able to use it. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-10 05:03 +0200 |
| Message-ID | <m17i9k$fue$1@online.de> |
| In reply to | #33779 |
rickman wrote:
> On 10/8/2014 8:35 PM, Bernd Paysan wrote:
>> rickman wrote:
>>
>>> Ok, so he is an idiot. That explains why his mistakes were not detected
>>> by the compiler and why he didn't find the error until he had written
>>> 5000 lines of code. What does this have to do with VHDL or any other
>>> language?
>>
>> Because the entire argument about this typechecking nonsense is that the
>> compiler will find the errors in the program.
>
> Yes, it will find type errors.
The actual question is if that is useful or not. You dodge this question.
>> Fact is: It won't even find
>> silly errors, but introduce *more* errors.
>
> Hmmm... ok if you say so. Most of your arguments on this topic are
> statements without substantiation. You seem to be convinced of their
> accuracy regardless. I doubt there is much anyone can say to change
> your mind.
Or *your* mind. I gave an example: You want a 4 bit index into an array
(register file). In Verilog, it's easy:
reg [3:0] index;
This is pretty much the only way you can do this 4 bit index stuff, but it
works: it does wrap around, it can index the array, and it has 4 bits.
In VHDL, well, an index ought to be an integer, so the idea was to specify a
0..15 subset of the integer. Works well, unless you increment it and it
should wrap around. The wraparound is a corner-case.
Of course, VHDL's type system allows you to define this in many different
ways, but there's no single way which satisfies all requirements: should
wrap around, should be 4 bits, and should allow to index an array without
further typecast.
This sort of "you don't get what you need" inevitable leads to *more* errors
in the code.
>> But the whole point about a typesafe language *is* that it helps to find
>> all the idiotic mistakes people make, by simply compiling the source.
>
> No, I don't recall anyone saying it will catch "all mistakes".
But of course you said it was quite helpful, and that Verilog's inexistent
type-checking is causing lots of problems, without stating even one example.
And I gave one example (out of several observations), and it's dismissed.
That sort of argument isn't very convincing. Except that it convinces me
that arguing with you is a waste of time.
>> And yes, all my other coworkers did struggle with the typechecker of
>> VHDL, as did I.
>
> I'm sure that is a problem easily solved by a bit of education.
So you agree with me that VHDL is difficult to learn. My point is that you
don't have to learn all the tricks to get around the cliffs of VHDL: Just
take the few weeks to learn Verilog.
> I get
> the impression your use of VHDL was some time ago. If it was before
> numeric_std was in widespread usage then yes, you would have found the
> process of type conversion to be harder.
No, we had numeric_std. Of course you always had to remember to add this
package to the boiler plate, or nothing would work.
In Verilog, this sort of stuff simply works out of the box. All these
little annoyances in VHDL add up, and create the feeling of a very badly
designed language.
> Std_logic_vectors were not
> supported at all for math. Signed and unsigned types are much easier to
> use. But with more recent additions to the language even
> std_logic_vectors are math friendly.
Can you now index an array using std_logic_vectors? AFAIK that's still not
possible.
> Again, this is not a problem with the language, this is a problem with a
> crappy tool. This must have been a *very* long time ago. I have used
> VHDL since around 1995 and I have never used tools that required any use
> of Verilog. Bizarre. What tools were these?
This is far from bizarre. The ASIC vendor we had (AMS and Xfab, back then
called Thesis) had only Verilog simulation libraries of their cells, and
that is still quite common. The simulator did offer a VHDL+Verilog
cosimulation, and it was Modelsim, not something weird. Mikron did make the
switch from VHDL to Verilog in 1999.
> You are fond of working with very limited data sets, so here is one to
> disprove your postulate. I have learned VHDL well and yet have not
> learned to use Verilog to the point I would prefer to use my code in a
> product. So 100% of my sample indicates Verilog is harder to learn.
Ok, so you have 1 sample point, which opposes my sample points. I've met
about 30 engineers which had at one or another point in time switched from
VHDL to Verilog, and none of them found Verilog difficult to learn.
> As I have mentioned before, Verilog has a set of aspects you need to
> learn about or you can produce buggy designs without realizing it. I
> don't recall the details and in fact I have never learned them all. You
> have acknowledged these aspects exist. Do you have a list written down
> somewhere? How did you teach your coworkers to use Verilog if you don't
> have this list? How did they learn about these issues?
We had a "Verilog and VHDL side by side" book, and they read it. Some
typical thing you need to know:
All assignments in always @(signal list) asynchrnous blocks have to be
blocking (i.e. with the variable = assignment syntax); in Verilog 2001, you
have always @*, and you shall use it when Verilog 2001 is an option
(otherwise, forgetting a signal in the sensitivity list leads to
inconsistent results between simulation and synthesis).
All assignments in always @(posedge/negedge signal list) blocks have to be
non-blocking (with the variable <= assignment syntax); the synchronous
blocks shall have one clock and one reset input only.
You can't mix @(signal or posedge signal), i.e. either a block is
synchronous or asynchronous.
A process with asynchronous nreset (active low) and clock looks like that:
always @(posedge clk or negedge nreset)
if(!nreset) begin
<initiatization code>
end else begin
<clock triggered code>
end
Declare all variables in blocks with "reg", declare all variables in
continuous assignments with "wire". IOs are wires by default, unless
declared as reg (works only for outputs of course, and is Verilog 2001).
All variables in an async process must be assigned in all possible cases,
otherwise they will create a latch (identical rule in VHDL).
Some stuff is "style guide"; these rules apply independent of the language.
With tools for the last 15 years, having an asynchronous process to do the
calculations, and a synchronous process only for register updates is no
longer necessary, so don't split these things up - the two variable names
clutter the namespace, and cause endless amounts of confusion - use just one
name, and do all calculation and update synchonous. The synthesis tool is
perfect at separating variables, too, so no need to manually split processes
up. You should not have negedge clock tasks, as they break ATPG (if you
need to sample at negative clock edges, you have to create a separate clock
signal that is fed from the inverted clock in normal mode, but from the test
clock in ATPG mode).
Some people who converted from VHDL to Verilog thought that the left and
right shift operators in Verilog had the same problems as in VHDL, and
therefore avoided them. They don't, they work fine and are straight-forward
unsigned shifts.
There's no signed data type in Verilog; if you need signed multiplication,
make sure you deal with the sign yourself. Signed shifts are easy, by just
replicating the top bit, e.g.
wire [15:0] shifted_a = {(16){a[15]}, a} >> shift;
> I wasn't aware that the Verilog standard covers things like drive
> strengths and transistor models. Can you refer me to info on this? Is
> this capability good enough to replace Spice?
No way. It's good enough to model IOs and wired-and busses like I²C.
You'll find a section about that in any reasonable Verilog book, or when you
google for "Verilog transistor primitives":
http://electrosofts.com/verilog/primitives.html
> You are gleaning a large conclusion from very little information. I
> don't accept your conclusion that "the switch has been done". How many
> of these companies have said "all new designs are in Verilog?"
There are certainly too many semiconductor companies around Munich to give a
definitive answer ;-). The companies I know of have all made the switch,
and that includes the by far biggest one.
> I don't think the Cooley test was very useful or well controlled. Your
> statement was "Verilog is about 3 times as productive as VHDL". How
> many of the Verilog programmers finished in 30 minutes?
Well, none of the VHDL programmer did finish in 90 minutes. The 3x figure
comes from the observation, that VHDL for the same job typically has a 3x
line count as Verilog, while the LoCs per day are the same for both
languages (and indeed the LoCs per day doesn't vary much between different
languages).
> Judging from the comments made by a couple of them I think they were not
> professional programmers in the sense of banging out code every day.
> Anyone who has problems with type conversions in VHDL is not up to speed
> and should not be in anything remotely like the Cooley race.
However, that observation coincides with my observation that all VHDL
designers had problems with the typing system, and were banging out code
every day. You assume a level of VHDL knowledge that I've never seen.
> Or the training. I assume now you are talking about the people you
> worked with who never figured out how to do type conversion or how to
> avoid needing type conversion. I could explain that topic in 15 minutes
> of instruction.
So please explain how to index an array with std_logic and avoiding type
conversion.
> I remember the first time I heard the amplifier statement about Forth.
> I have often wondered if it is so much an amplifier as it is a filter.
> If you are a great programmer then you can deal with the various issues
> of Forth just as you could deal with the various issues of any other
> language... except maybe VHDL which seems to be a fatal blow to some.
VHDL's issues certainly drag me down: It's overly complex and therefore
takes more time to learn, the type system is worse than useless, and not
designed for creating circuits (I wonder what it was designed for), and some
parts of the language standards have simply been wrong (like the shift
operators in numeric_std, which were added as aftertought and misspecified).
> If you are a lesser programmer I think the issues of Forth drag you down.
Yes. But to call them "issues" implies that good programmers work around
them, it doesn't help them to gain speed, it just doesn't drag them down a
lot. I don't think the problematic parts of Forth for lesser programmers
are real issues for the good programmers.
> Heck, you like statistical evidence so much, Forth has always been a
> back water language in terms of popularity and it has dropped off over
> the years. Does that mean it is a poor choice of language? There seem
> to be a huge number of people who try it and simply drop it out of pure
> frustration. So Verilog is like C and VHDL is like Ada^H^H^H Forth?
VHDL is certainly like Ada, and nowhere like Forth. Verilog is like C, I'm
fine with that description. I'd love to see a HDL which is based on Forth,
and works like Forth - simple, stack-based, implicit where possible (e.g.
most modules have a single clock and a single reset - no need to name
those), with tools optimized for the 90% you need.
Ada and Forth are certainly two very opposite directions of programming
languages for the same job (low-level control stuff).
>> It might be that Verilog is an amplifier; however, given how much easier
>> people perceive it is to learn, I much doubt it.
>
> I won't argue that Verilog is not quicker to learn. I just think most
> of your bias against VHDL is based on ancient experiences using poor
> tools. I won't recommend that you try it again because I think it is
> just against your grain no matter how well others are able to use it.
It wasn't that ancient; the tools are of course better now (I hope the tools
always get better), but yes, VHDL certainly is not for me, so I won't
reconsidder it. I don't think it has anything of value to offer.
We had switched tools from a VHDL-oriented vendor (Mentor Graphics) to
Cadence after we did the VHDL-Verilog switch at Mikron; that switch was
driven by fab support, but the tools from Cadence support Verilog better
than VHDL. However, the Siemens HL experience before was with Synopsys,
which has even better tools than Cadence - they had the best tools for VHDL
available at that time, so if it was a tools issue, I would be rather
surprised.
Verilog has fixed several issues it had 15 years ago, as well. The most
important is IMHO the "always @*" for asynchronous blocks in Verilog 2001.
VHDL copied that in VHDL-2008, with a "process(all)" statement.
--
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-10-10 01:07 -0400 |
| Message-ID | <m17pik$dqa$1@dont-email.me> |
| In reply to | #33799 |
On 10/9/2014 11:03 PM, Bernd Paysan wrote:
> rickman wrote:
>
>> On 10/8/2014 8:35 PM, Bernd Paysan wrote:
>>> rickman wrote:
>>>
>>>> Ok, so he is an idiot. That explains why his mistakes were not detected
>>>> by the compiler and why he didn't find the error until he had written
>>>> 5000 lines of code. What does this have to do with VHDL or any other
>>>> language?
>>>
>>> Because the entire argument about this typechecking nonsense is that the
>>> compiler will find the errors in the program.
>>
>> Yes, it will find type errors.
>
> The actual question is if that is useful or not. You dodge this question.
I think I have been clear on this. Type error checking can find errors
that can otherwise go undetected in unit test and require more extensive
debugging in system test. Even if they are uncovered in unit test, it
is still more productive to find them at compile time.
The problem is you keep bringing in irrelevant examples of
inefficiencies that have *nothing* to do with type checking but rather
are crappy coders making stupid mistakes.
>>> Fact is: It won't even find
>>> silly errors, but introduce *more* errors.
>>
>> Hmmm... ok if you say so. Most of your arguments on this topic are
>> statements without substantiation. You seem to be convinced of their
>> accuracy regardless. I doubt there is much anyone can say to change
>> your mind.
>
> Or *your* mind. I gave an example: You want a 4 bit index into an array
> (register file). In Verilog, it's easy:
>
> reg [3:0] index;
>
> This is pretty much the only way you can do this 4 bit index stuff, but it
> works: it does wrap around, it can index the array, and it has 4 bits.
>
> In VHDL, well, an index ought to be an integer, so the idea was to specify a
> 0..15 subset of the integer. Works well, unless you increment it and it
> should wrap around. The wraparound is a corner-case.
>
> Of course, VHDL's type system allows you to define this in many different
> ways, but there's no single way which satisfies all requirements: should
> wrap around, should be 4 bits, and should allow to index an array without
> further typecast.
>
> This sort of "you don't get what you need" inevitable leads to *more* errors
> in the code.
From some actual code I wrote, I only changed the range of the unsigned.
Signal declaration...
signal WriteCntr : unsigned (3 downto 0);
Signal usage...
FIFORam(to_integer(WriteCntr)) <= DataWr;
Yes, that is extremely complex. I can see why Verilog is such a better
language. I guess the idea that VHDL is not the spawn of the devil is
all in my mind.
>>> But the whole point about a typesafe language *is* that it helps to find
>>> all the idiotic mistakes people make, by simply compiling the source.
>>
>> No, I don't recall anyone saying it will catch "all mistakes".
>
> But of course you said it was quite helpful, and that Verilog's inexistent
> type-checking is causing lots of problems, without stating even one example.
> And I gave one example (out of several observations), and it's dismissed.
I don't think I said much if any of that. But I will say now that there
are problems that happen from mismatched data types. Maybe it was in a
different newsgroup, but someone just posted an example where a function
was called to return a value and it was used as if it were an integer
while it was actually a boolean. His lament was that this was not
caught in a code review because he works alone and has no code reviews.
I seem to recall that he also mentioned that it should have been
flagged by the C compiler but wasn't.
> That sort of argument isn't very convincing. Except that it convinces me
> that arguing with you is a waste of time.
But you persist.
>>> And yes, all my other coworkers did struggle with the typechecker of
>>> VHDL, as did I.
>>
>> I'm sure that is a problem easily solved by a bit of education.
>
> So you agree with me that VHDL is difficult to learn. My point is that you
> don't have to learn all the tricks to get around the cliffs of VHDL: Just
> take the few weeks to learn Verilog.
I would agree that VHDL is *harder* to learn than Verilog if I had
actually learned Verilog to the same proficiency as VHDL, but I have
not, partly because I have asked a number of times for recommendations
for *good* Verilog books and I am repeatedly told there are *none* that
qualify as good.
I think I said that I intended to learn Verilog better, but I keep
finding that I have no reason. If I could find one reference text that
covers all the gotchas I'd go for it.
>> I get
>> the impression your use of VHDL was some time ago. If it was before
>> numeric_std was in widespread usage then yes, you would have found the
>> process of type conversion to be harder.
>
> No, we had numeric_std. Of course you always had to remember to add this
> package to the boiler plate, or nothing would work.
Uh, why wasn't it *in* your boilerplate? Don't you copy the boilerplate
from a template or an existing file to the next? Is that *really* a
complaint that you had to add a library reference???
> In Verilog, this sort of stuff simply works out of the box. All these
> little annoyances in VHDL add up, and create the feeling of a very badly
> designed language.
Now you are in troll land. If you can't handle two or three library
references, how do you ever work in Forth? You don't use any libraries?
>> Std_logic_vectors were not
>> supported at all for math. Signed and unsigned types are much easier to
>> use. But with more recent additions to the language even
>> std_logic_vectors are math friendly.
>
> Can you now index an array using std_logic_vectors? AFAIK that's still not
> possible.
My example above does that for unsigned types. I believe that is also
now defined for std_logic_vectors. I'm not really current with the 2008
updates actually. It takes two or three years for the new standards to
find their way into the tools and I haven't done a major project since
then so I've not really used the newer features.
>> Again, this is not a problem with the language, this is a problem with a
>> crappy tool. This must have been a *very* long time ago. I have used
>> VHDL since around 1995 and I have never used tools that required any use
>> of Verilog. Bizarre. What tools were these?
>
> This is far from bizarre. The ASIC vendor we had (AMS and Xfab, back then
> called Thesis) had only Verilog simulation libraries of their cells, and
> that is still quite common. The simulator did offer a VHDL+Verilog
> cosimulation, and it was Modelsim, not something weird. Mikron did make the
> switch from VHDL to Verilog in 1999.
I believe the ASIC community is one where Verilog is dominant, likewise
the telecom suppliers. Much of Europe is VHDL as it the defense
community here in the US. The last I heard the rest of the engineering
world was split. The area around Washington DC is split between defense
and telecom so I have done work with both languages.
Funny, when I worked at a telecom company we were working in Verilog,
but I seem to remember writing test benches in VHDL. Maybe I was
designing them with VHDL then converted them to Verilog. It involved
reading in a custom command file which had to be interpreted to control
the test fixture. I think it was for bus reads and writes to emulate a
processor interface. Is that easy to do in Verilog?
>> You are fond of working with very limited data sets, so here is one to
>> disprove your postulate. I have learned VHDL well and yet have not
>> learned to use Verilog to the point I would prefer to use my code in a
>> product. So 100% of my sample indicates Verilog is harder to learn.
>
> Ok, so you have 1 sample point, which opposes my sample points. I've met
> about 30 engineers which had at one or another point in time switched from
> VHDL to Verilog, and none of them found Verilog difficult to learn.
My point is that your sample set is rather small. So I gave you a
contrary example which is also small. Neither is convincing, eh?
>> As I have mentioned before, Verilog has a set of aspects you need to
>> learn about or you can produce buggy designs without realizing it. I
>> don't recall the details and in fact I have never learned them all. You
>> have acknowledged these aspects exist. Do you have a list written down
>> somewhere? How did you teach your coworkers to use Verilog if you don't
>> have this list? How did they learn about these issues?
>
> We had a "Verilog and VHDL side by side" book, and they read it. Some
> typical thing you need to know:
>
> All assignments in always @(signal list) asynchrnous blocks have to be
> blocking (i.e. with the variable = assignment syntax); in Verilog 2001, you
> have always @*, and you shall use it when Verilog 2001 is an option
> (otherwise, forgetting a signal in the sensitivity list leads to
> inconsistent results between simulation and synthesis).
I have heard about the blocking vs. non-blocking thing, but I can never
remember which is which by name. I seem to recall the idea is to create
the equivalent of signal assignments in VHDL which are not assigned
until the process waits (usually the end for a clocked process). They
both use the same assignment operator <= no?
In VHDL variables are assigned with := which operates immediately just
as assignments in a C program. So <= is non-blocking and = is blocking?
Now that I have my head straight on this, why are blocking assignments
required in async blocks? Does it not synthesize correctly and create a
register or something odd if you use a non-blocking assignment?
> All assignments in always @(posedge/negedge signal list) blocks have to be
> non-blocking (with the variable <= assignment syntax); the synchronous
> blocks shall have one clock and one reset input only.
Yeah, that is the one I remember.
> You can't mix @(signal or posedge signal), i.e. either a block is
> synchronous or asynchronous.
>
> A process with asynchronous nreset (active low) and clock looks like that:
>
> always @(posedge clk or negedge nreset)
> if(!nreset) begin
> <initiatization code>
> end else begin
> <clock triggered code>
> end
>
> Declare all variables in blocks with "reg", declare all variables in
> continuous assignments with "wire". IOs are wires by default, unless
> declared as reg (works only for outputs of course, and is Verilog 2001).
> All variables in an async process must be assigned in all possible cases,
> otherwise they will create a latch (identical rule in VHDL).
>
> Some stuff is "style guide"; these rules apply independent of the language.
> With tools for the last 15 years, having an asynchronous process to do the
> calculations, and a synchronous process only for register updates is no
> longer necessary, so don't split these things up - the two variable names
> clutter the namespace, and cause endless amounts of confusion - use just one
> name, and do all calculation and update synchonous. The synthesis tool is
> perfect at separating variables, too, so no need to manually split processes
> up. You should not have negedge clock tasks, as they break ATPG (if you
> need to sample at negative clock edges, you have to create a separate clock
> signal that is fed from the inverted clock in normal mode, but from the test
> clock in ATPG mode).
>
> Some people who converted from VHDL to Verilog thought that the left and
> right shift operators in Verilog had the same problems as in VHDL, and
> therefore avoided them. They don't, they work fine and are straight-forward
> unsigned shifts.
What's wrong with the shift operators in VHDL? I have to say I don't
use them much as they simply save some typing and I hate having to
remember the details of how they are used. I just do my own shifting
with an aggregate.
> There's no signed data type in Verilog; if you need signed multiplication,
> make sure you deal with the sign yourself. Signed shifts are easy, by just
> replicating the top bit, e.g.
>
> wire [15:0] shifted_a = {(16){a[15]}, a} >> shift;
>
>> I wasn't aware that the Verilog standard covers things like drive
>> strengths and transistor models. Can you refer me to info on this? Is
>> this capability good enough to replace Spice?
>
> No way. It's good enough to model IOs and wired-and busses like I²C.
> You'll find a section about that in any reasonable Verilog book, or when you
> google for "Verilog transistor primitives":
>
> http://electrosofts.com/verilog/primitives.html
I'm pretty sure you can model an I2C bus in VHDL.
>> You are gleaning a large conclusion from very little information. I
>> don't accept your conclusion that "the switch has been done". How many
>> of these companies have said "all new designs are in Verilog?"
>
> There are certainly too many semiconductor companies around Munich to give a
> definitive answer ;-). The companies I know of have all made the switch,
> and that includes the by far biggest one.
But you don't actually say how you know they have "made the switch".
You say they are hiring both Verilog and VHDL people, that's not proof
of "making the switch". When they stop offering VHDL models of memory
or other parts, or you can offer some real evidence like an employee
saying they don't use VHDL anymore... then I'll believe.
>> I don't think the Cooley test was very useful or well controlled. Your
>> statement was "Verilog is about 3 times as productive as VHDL". How
>> many of the Verilog programmers finished in 30 minutes?
>
> Well, none of the VHDL programmer did finish in 90 minutes. The 3x figure
> comes from the observation, that VHDL for the same job typically has a 3x
> line count as Verilog, while the LoCs per day are the same for both
> languages (and indeed the LoCs per day doesn't vary much between different
> languages).
Again, where can you point me to for this info?
>> Judging from the comments made by a couple of them I think they were not
>> professional programmers in the sense of banging out code every day.
>> Anyone who has problems with type conversions in VHDL is not up to speed
>> and should not be in anything remotely like the Cooley race.
>
> However, that observation coincides with my observation that all VHDL
> designers had problems with the typing system, and were banging out code
> every day. You assume a level of VHDL knowledge that I've never seen.
Your observation from what, 15 years ago? Using what tools, I think
they were officially certified crappy, no? I'm assuming the level of
experience with VHDL that anyone who has used it for more than a month
should have.
Read the code I gave you above. Tell me how long it would take you to
learn that... It would have saved your coworker how many hours?
>> Or the training. I assume now you are talking about the people you
>> worked with who never figured out how to do type conversion or how to
>> avoid needing type conversion. I could explain that topic in 15 minutes
>> of instruction.
>
> So please explain how to index an array with std_logic and avoiding type
> conversion.
Why do you have to avoid type conversion??? Is it too hard to type
"to_integer"? Also, few VHDL people use std_logic_vector anymore unless
it is required for I/O. Unsigned and signed are much better types.
>> I remember the first time I heard the amplifier statement about Forth.
>> I have often wondered if it is so much an amplifier as it is a filter.
>> If you are a great programmer then you can deal with the various issues
>> of Forth just as you could deal with the various issues of any other
>> language... except maybe VHDL which seems to be a fatal blow to some.
>
> VHDL's issues certainly drag me down: It's overly complex and therefore
> takes more time to learn, the type system is worse than useless, and not
> designed for creating circuits (I wonder what it was designed for), and some
> parts of the language standards have simply been wrong (like the shift
> operators in numeric_std, which were added as aftertought and misspecified).
I'd like to know details of the shift operator problems.
>> If you are a lesser programmer I think the issues of Forth drag you down.
>
> Yes. But to call them "issues" implies that good programmers work around
> them, it doesn't help them to gain speed, it just doesn't drag them down a
> lot. I don't think the problematic parts of Forth for lesser programmers
> are real issues for the good programmers.
No, because you took the time to learn how to deal with the language and
worked with the limitations while exploiting the unique features.
Something you failed to do with VHDL which may not be your fault. It
sounds like you had some really bad tools and it may have been before
they smoothed off some of the rough edges of VHDL.
>> Heck, you like statistical evidence so much, Forth has always been a
>> back water language in terms of popularity and it has dropped off over
>> the years. Does that mean it is a poor choice of language? There seem
>> to be a huge number of people who try it and simply drop it out of pure
>> frustration. So Verilog is like C and VHDL is like Ada^H^H^H Forth?
>
> VHDL is certainly like Ada, and nowhere like Forth. Verilog is like C, I'm
> fine with that description. I'd love to see a HDL which is based on Forth,
> and works like Forth - simple, stack-based, implicit where possible (e.g.
> most modules have a single clock and a single reset - no need to name
> those), with tools optimized for the 90% you need.
>
> Ada and Forth are certainly two very opposite directions of programming
> languages for the same job (low-level control stuff).
There are different ways of being similar. Both are archane, both are
not very popular and both are not so easy to learn to use proficiently.
One difference is I don't think usage of Ada has fallen off much over
the years but I may be mistaken.
>>> It might be that Verilog is an amplifier; however, given how much easier
>>> people perceive it is to learn, I much doubt it.
>>
>> I won't argue that Verilog is not quicker to learn. I just think most
>> of your bias against VHDL is based on ancient experiences using poor
>> tools. I won't recommend that you try it again because I think it is
>> just against your grain no matter how well others are able to use it.
>
> It wasn't that ancient; the tools are of course better now (I hope the tools
> always get better), but yes, VHDL certainly is not for me, so I won't
> reconsidder it. I don't think it has anything of value to offer.
>
> We had switched tools from a VHDL-oriented vendor (Mentor Graphics) to
> Cadence after we did the VHDL-Verilog switch at Mikron; that switch was
> driven by fab support, but the tools from Cadence support Verilog better
> than VHDL. However, the Siemens HL experience before was with Synopsys,
> which has even better tools than Cadence - they had the best tools for VHDL
> available at that time, so if it was a tools issue, I would be rather
> surprised.
Didn't you tell me you had to write your test benches in both languages?
Was that because of your ASIC vendor and not the tools?
I have not seen any of the absurd tool related problems you reported. I
work with FPGAs though, not ASICs. I have seen plenty of problems, but
was when I first was learning VHDL back in 1995 nearly 20 years ago.
> Verilog has fixed several issues it had 15 years ago, as well. The most
> important is IMHO the "always @*" for asynchronous blocks in Verilog 2001.
> VHDL copied that in VHDL-2008, with a "process(all)" statement.
Yep!
BTW, none of the things you list above were any of the issues with
Verilog I recall being told to worry about. They were more subtle
things like what happens when you assign an 8 bit vector to a 9 bit
vector (or is it the other way around?) VHDL requires you to tell it
what you want to happen. I believe Verilog makes assumptions without
even a warning. There are some others having to do with simulations but
I just don't recall.
--
Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-10 21:27 +0200 |
| Message-ID | <m19bug$eia$1@online.de> |
| In reply to | #33802 |
rickman wrote: > But you persist. Ok, *plonk*. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-11 00:01 +0200 |
| Message-ID | <m19kvg$u1h$1@online.de> |
| In reply to | #33802 |
rickman wrote: > Now you are in troll land. If you can't handle two or three library > references, how do you ever work in Forth? You don't use any libraries? Actually, Forth has this great feature of allowing to save the image (even though that is not mentioned in a standard, all good Forth systems can do that). I just load in the libraries I need, save a new image, and then use that to write my programs in. This is really very helpful. No need to boilerplate every single program with all the 100 libraries you use all the time, or to recompile all those 100 libraries each time you change your program. If I wanted to program boilerplates, I would be doing Java. And, in any case, if you say, VHDL is better now: Verilog advanced, too, very significantly. Especially SystemVerilog is addressing the missing high-level part, which isn't necessary to write synthesizable code, but can be very helpful for testbenching (I've used e.g. SystemVerilog's assertions to create self-checking testbenches). At least I can say one thing definitely: I'm in Europe, and while it was pretty much VHDL dominated 15 years ago, it certainly no longer is. There's still the military industrial complex, but well, as pacifist I'm happy that they use VHDL to produce non-functional weapons (there's an ongoing evaluation, and the result so far is that a lot of high-tech weapons made in Germany are overpriced and can't be used ;-). > I work with FPGAs though, not ASICs. That might explain why you don't have those tool problems. FPGA stuff is a lot easier, you have a one-stop tool, which does everything for you: Synthesis, place&route, timing checks. This is not how it works in the ASIC world: You have your HDL source, you have a gate library (you either buy that or it comes from the fab), you have a synthesis tool, a place&route tool (can be from a different vendor), a timing analysis tool, a formal verification tool, hand-layout tools, check tools like DRC and LVS. As Verilog is much better for gate-level simulation, people use it for that purpose, no matter what the HDL stuff was in. Cosimulation of Verilog and VHDL together is not that easy, it used to be a lot harder. VHDL might not be "the devil itself", but all the annoying things add up to a bad feeling, this "wading waste-deep through mud". This "to_integer" for all array accesses drags me down a bit, that "netlist simulations are done in Verilog" drags me down a bit, the fact that you have to boilerplate every single module drags me down a bit (and you need to specify architecture and implementation, i.e. the same thing twice, to define the interface). My recommendation to learn Verilog as VHDL expert is that you might want to use a "side-by-side" book, because there, you recognize the VHDL stuff you already know, and see how you would be doing that in Verilog. E.g. "Digital Design with RTL Design, VHDL, and Verilog" (expensive, likely not worth the price), or (somewhat cheaper) "HDL Programming Fundamentals: VHDL and Verilog". However, I've read neither of them, and the Verilog/VHDL side-by- side book we had used 15 years ago of course is no longer in print. Essentially, everybody seems to agree that there are no good books on Verilog (haha, this is a running gag), but if you want a cheap book that addresses just the stuff you need to know as FPGA programmer, try "Verilog by Example: A Concise Introduction for FPGA Design". I don't know if it is good (probably not, because it's a book on Verilog ;-), but it's certainly worth the small price, and the time you'll need to read it (it *is* concise). -- 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-10-10 19:59 -0400 |
| Message-ID | <m19rta$vua$1@dont-email.me> |
| In reply to | #33825 |
On 10/10/2014 6:01 PM, Bernd Paysan wrote: > rickman wrote: > >> Now you are in troll land. If you can't handle two or three library >> references, how do you ever work in Forth? You don't use any libraries? > > Actually, Forth has this great feature of allowing to save the image (even > though that is not mentioned in a standard, all good Forth systems can do > that). I just load in the libraries I need, save a new image, and then use > that to write my programs in. This is really very helpful. > > No need to boilerplate every single program with all the 100 libraries you > use all the time, or to recompile all those 100 libraries each time you > change your program. > > If I wanted to program boilerplates, I would be doing Java. You can use hyperbole if you want, but I'd like to be clear on this. If you need to add two or three libraries to the boilerplate of your code, you consider that to be a problem??? > And, in any case, if you say, VHDL is better now: Verilog advanced, too, > very significantly. Especially SystemVerilog is addressing the missing > high-level part, which isn't necessary to write synthesizable code, but can > be very helpful for testbenching (I've used e.g. SystemVerilog's assertions > to create self-checking testbenches). > > At least I can say one thing definitely: I'm in Europe, and while it was > pretty much VHDL dominated 15 years ago, it certainly no longer is. There's > still the military industrial complex, but well, as pacifist I'm happy that > they use VHDL to produce non-functional weapons (there's an ongoing > evaluation, and the result so far is that a lot of high-tech weapons made in > Germany are overpriced and can't be used ;-). Ok, but you keep backing away from your initial statements and don't actually provide any real evidence of the ones you do make. >> I work with FPGAs though, not ASICs. > > That might explain why you don't have those tool problems. FPGA stuff is a > lot easier, you have a one-stop tool, which does everything for you: > Synthesis, place&route, timing checks. This is not how it works in the ASIC > world: You have your HDL source, you have a gate library (you either buy > that or it comes from the fab), you have a synthesis tool, a place&route > tool (can be from a different vendor), a timing analysis tool, a formal > verification tool, hand-layout tools, check tools like DRC and LVS. > > As Verilog is much better for gate-level simulation, people use it for that > purpose, no matter what the HDL stuff was in. Cosimulation of Verilog and > VHDL together is not that easy, it used to be a lot harder. I'm not sure why you say Verilog is better for gate level simulation. You continue to make unsubstantiated claims, then extrapolate from those claims. > VHDL might not be "the devil itself", but all the annoying things add up to > a bad feeling, this "wading waste-deep through mud". This "to_integer" for > all array accesses drags me down a bit, that "netlist simulations are done > in Verilog" drags me down a bit, the fact that you have to boilerplate every > single module drags me down a bit (and you need to specify architecture and > implementation, i.e. the same thing twice, to define the interface). I have no idea what you are talking about with netlist simulations in Verilog. You are talking about a tool problem. Get a decent tool! Are you saying you don't use any boilerplate? The architecture doesn't specify interface, the entity declaration does. I have no idea what you are talking about. > My recommendation to learn Verilog as VHDL expert is that you might want to > use a "side-by-side" book, because there, you recognize the VHDL stuff you > already know, and see how you would be doing that in Verilog. E.g. "Digital > Design with RTL Design, VHDL, and Verilog" (expensive, likely not worth the > price), or (somewhat cheaper) "HDL Programming Fundamentals: VHDL and > Verilog". However, I've read neither of them, and the Verilog/VHDL side-by- > side book we had used 15 years ago of course is no longer in print. BTW, you never answered my question about which "side by side" book you have. > Essentially, everybody seems to agree that there are no good books on > Verilog (haha, this is a running gag), but if you want a cheap book that > addresses just the stuff you need to know as FPGA programmer, try "Verilog > by Example: A Concise Introduction for FPGA Design". I don't know if it is > good (probably not, because it's a book on Verilog ;-), but it's certainly > worth the small price, and the time you'll need to read it (it *is* > concise). I might just do that. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-11 03:33 +0200 |
| Message-ID | <m1a1cr$vpo$1@online.de> |
| In reply to | #33832 |
rickman wrote:
>> If I wanted to program boilerplates, I would be doing Java.
>
> You can use hyperbole if you want, but I'd like to be clear on this. If
> you need to add two or three libraries to the boilerplate of your code,
> you consider that to be a problem???
It's as simple as that: Boilerplating is a problem. The more boilerplate
you need, the more of a problem. If you can remove boilerplate, it's good.
Verilog had this K&R-style C module declarations, where you put the names of
the parameters in the parenthesis after the module name, and then again
declared them as input or output with size afterwards. Verilog 2001 added a
ANSI C style declaration, where you can state input/output inside the
parenthesis, and therefore, the duplication of the names goes away, the
overall declaration is shorter, and more concise.
This is an improvement.
If you think that conciseness doesn't matter, you are heading in the wrong
direction. And yes, heading in the wrong direction is the root of all
problems. Each individual problem is not big, but together, they make a
mountain, if you don't think that they are problems and should be solved.
> Ok, but you keep backing away from your initial statements and don't
> actually provide any real evidence of the ones you do make.
Well, you were right that I should have just plonked you. This sort of "ah,
a proof. I now require that you make it harder. And if you do, I require
that you make it yet even harder. Each time, I do so, you will have to
remove some parts of your analysis, because it doesn't meet the required
standards, and finally, there's nothing left."
But if you would have to proof that Infineon is still a VHDL-only shop as it
was 15 years ago, when it was called Siemens HL, there would be ample
evidence against your claim. Your position is way weaker than mine.
> I'm not sure why you say Verilog is better for gate level simulation.
> You continue to make unsubstantiated claims, then extrapolate from those
> claims.
No. You keep ignoring reality, you don't do any own research, and you don't
want to listen. You might just look into the VHDL FAQ to verify that my
gatelevel simulation claim is not unsubstantiated:
https://www.doulos.com/knowhow/faq/vhdl_faq/
"You don't need to change your VHDL netlist; your ASIC vendor needs to have
a VITAL compliant library though, in order for you to take advantage of the
simulation speed up. Thus the ASIC vendor's library elements need to be
implemented entirely in VITAL primitives. Note that many companies use
Verilog for gate-level simulations as it is still faster than VHDL, even
with the improvemens from VITAL. The reason is that Verilog was designed
from the start as a gate-level simulation langauge."
Yes, Verilog was designed right from start to do it right, while VHDL had
gate level simulation as an afterthought, did improve its poor performance
with VITAL, but still is worse than Verilog (netlist simulation is slow, so
you want the fastest netlist simulator you can get - and then you want a
faster one). VITAL is modeled after Verilog's UDP primitive, so it offers
similar capabilities. As the netlist has only VITAL types, it may have
severy type compatibility issues with the RTL netlist.
And that's why you won't get VITAL models from many gate library suppliers:
The Verilog library is a must-have, you go out of business if you don't have
them. They not only contain information for gate-level simulation, but also
for timing analysis and fault analysis - and this means other tools depend
on them, as well. The VITAL models are not really vital at all. In fact,
my boss 15 years ago kept nagging fabs about VITAL models, and they all said
"nay, use Verilog". And I haven't seen any standard cell libraries with
VITAL models to download - you get GDS, you get Verilog, you get abstracts,
you get timing, you get design compiler models, but no VITAL.
This sort of thing is not a language issue as such, but a competition issue:
If there's some other language out there who does the thing better, the
situation of the language which does it worse will get even worse.
> I have no idea what you are talking about with netlist simulations in
> Verilog. You are talking about a tool problem. Get a decent tool!
You don't get the VITAL models from the standard cell library vendor.
That's not a tool issue. Setting up a VHDL-Verilog mixed simulation is a
lot of work, even if you use the best tools you can get (and it has a lot of
issues). Setting up a Verilog-only simulation is much easier. Of course,
in Verilog, it's "the entire project in one file", but you are allowed to
use `include, and `ifdef, and you can set variables when invoking the
simulator. So a typical test bench wrapper looks like
`ifdef NETLIST
`include "stdcell-lib.v"
`include "gate-level.v"
`else
`include "rtl.v"
`endif
and somewhere a
`ifdef NETLIST
initial
$sdf_annotate("gate-level.sdf", top.dut);
`endif
> Are you saying you don't use any boilerplate?
I'm saying that boilerplate is a problem, not a solution. If I can get away
without any boilerplate, then I do.
Seems to be a pretty alien concept to you.
Like Forth, Verilog hasn't had separate compilation at start (modern tools
support it, but they also support to recognize unchanged modules on
reinvocation, so it's a non-issue). So you had one file, and other files
could be loaded with `include "filename". So if you use a library, you
specify it in the loader file, once for the entire project. That's what you
do with Forth projects, too.
If you write a Java project, every class has to reside in a file of its own.
All the common libraries you use in the entire project go to the
boilerplate, instead of going into the loader file. You can keep every
class (or whatever conceptual unit you have) in one file in your Forth
project, as well, but since it's just loaded from the loader file, all
common libraries don't have to be specified in each file.
People who are used to boilerplates are used to cut&paste, and what I've
often seen is that they copy a big portion of their previous code to change
it to their next code. A significant portion of the 5000 VHDL lines I had
mentioned were created by cut&paste, and then when a bug was discovered in
one copy, you had to go through all other copies to fix those bugs, too.
You might think you get more LoCs per hour out with cut&paste style
programming, but in the end, you don't.
> BTW, you never answered my question about which "side by side" book you
> have.
I actually haven't, Mikron had. The book has long been lost (we pruned our
libriaries when we moved, and either one of the designers took it with him
or we sold it on e-Bay; after some time every new hire already had "Verilog"
in his CV, so we didn't need it anymore), and I don't know the exact title.
Don't ask me too many details about stuff more than a decade ago, I have a
good memory, but I'm not an elephant.
You are just setting way too high standards to every argument so that you
can claim you won by me not meeting the standards you require. Since you
have double standards (your own arguments are ok if they apply to sample
size 1, which is you yourself, and don't require any proof), it is of course
impossible to win any arguments with you.
--
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-10-10 22:30 -0400 |
| Message-ID | <m1a4oq$8uf$1@dont-email.me> |
| In reply to | #33835 |
On 10/10/2014 9:33 PM, Bernd Paysan wrote:
> rickman wrote:
>>> If I wanted to program boilerplates, I would be doing Java.
>>
>> You can use hyperbole if you want, but I'd like to be clear on this. If
>> you need to add two or three libraries to the boilerplate of your code,
>> you consider that to be a problem???
>
> It's as simple as that: Boilerplating is a problem. The more boilerplate
> you need, the more of a problem. If you can remove boilerplate, it's good.
Yes, code is a problem. If you can avoid coding it is good. I think
you are trying to make a mountain out of a molehill...
>> Ok, but you keep backing away from your initial statements and don't
>> actually provide any real evidence of the ones you do make.
>
> Well, you were right that I should have just plonked you. This sort of "ah,
> a proof. I now require that you make it harder. And if you do, I require
> that you make it yet even harder. Each time, I do so, you will have to
> remove some parts of your analysis, because it doesn't meet the required
> standards, and finally, there's nothing left."
>
> But if you would have to proof that Infineon is still a VHDL-only shop as it
> was 15 years ago, when it was called Siemens HL, there would be ample
> evidence against your claim. Your position is way weaker than mine.
I'm not making such claims. My point is your evidence is *far* from
anything remotely convincing.
>> I'm not sure why you say Verilog is better for gate level simulation.
>> You continue to make unsubstantiated claims, then extrapolate from those
>> claims.
>
> No. You keep ignoring reality, you don't do any own research, and you don't
> want to listen. You might just look into the VHDL FAQ to verify that my
> gatelevel simulation claim is not unsubstantiated:
>
> https://www.doulos.com/knowhow/faq/vhdl_faq/
So you are talking about *speed*. I suppose that is why the netlist
simulations are done with Verilog. But does that require a Verilog test
bench? Can't the tool do mixed language simulation? If it is the gate
level simulation that is slow in VHDL that should not affect a test bench.
>> I have no idea what you are talking about with netlist simulations in
>> Verilog. You are talking about a tool problem. Get a decent tool!
>
> You don't get the VITAL models from the standard cell library vendor.
> That's not a tool issue. Setting up a VHDL-Verilog mixed simulation is a
> lot of work, even if you use the best tools you can get (and it has a lot of
> issues). Setting up a Verilog-only simulation is much easier. Of course,
> in Verilog, it's "the entire project in one file", but you are allowed to
> use `include, and `ifdef, and you can set variables when invoking the
> simulator. So a typical test bench wrapper looks like
>
> `ifdef NETLIST
> `include "stdcell-lib.v"
> `include "gate-level.v"
> `else
> `include "rtl.v"
> `endif
>
> and somewhere a
>
> `ifdef NETLIST
> initial
> $sdf_annotate("gate-level.sdf", top.dut);
> `endif
Too bad you can't use the advantages of VHDL in writing test benches.
>> Are you saying you don't use any boilerplate?
>
> I'm saying that boilerplate is a problem, not a solution. If I can get away
> without any boilerplate, then I do.
>
> Seems to be a pretty alien concept to you.
Yes, the alien part is seeing problems where they don't exist. I don't
treat trivial things as problems just because they exist.
> People who are used to boilerplates are used to cut&paste, and what I've
> often seen is that they copy a big portion of their previous code to change
> it to their next code. A significant portion of the 5000 VHDL lines I had
> mentioned were created by cut&paste, and then when a bug was discovered in
> one copy, you had to go through all other copies to fix those bugs, too.
>
> You might think you get more LoCs per hour out with cut&paste style
> programming, but in the end, you don't.
Your logic does not follow to the conclusion. Firstly, using a
boilerplate when starting a new file does not imply copying 100's of
lines of code. I can't think of a time I have done that unless I was
writing an alternative version of a file. When I say boilerplate I mean
just that, just the sections of a file which change little from one file
to the next. Mostly this is the documentation text at the beginning of
a file, but it also includes the library invocations and often the first
few lines of the entity declaration.
If the 5000 lines you mention were produced by writing it all by hand it
would not have produced code that worked any better. Would the designer
reinvent the wheel every time an array was used? The problem was he had
not been taught correctly or had taught himself incorrectly.
I also use a form of boilerplate for much of my coding, but this does
not include copying from different files. When I code a clocked process
I use the exact same style every time and I often do copy within a file.
I use the same name for my primary clock in every file unless there is
some reason to differ. But my design style is to make the entire chip
run from one clock other than the peripheral edges where I interface to
signals from other clock domains. I don't use multiple clocks in large
sections unless it is truly required.
The point is that I know coding styles that work well and I reuse them.
It creates no problems I am aware of. My biggest problems are
completely outside the coding domain and I see these issues as largely
trivial.
>> BTW, you never answered my question about which "side by side" book you
>> have.
>
> I actually haven't, Mikron had. The book has long been lost (we pruned our
> libriaries when we moved, and either one of the designers took it with him
> or we sold it on e-Bay; after some time every new hire already had "Verilog"
> in his CV, so we didn't need it anymore), and I don't know the exact title.
> Don't ask me too many details about stuff more than a decade ago, I have a
> good memory, but I'm not an elephant.
>
> You are just setting way too high standards to every argument so that you
> can claim you won by me not meeting the standards you require. Since you
> have double standards (your own arguments are ok if they apply to sample
> size 1, which is you yourself, and don't require any proof), it is of course
> impossible to win any arguments with you.
I feel that extraordinary claims require at least ordinary proof.
Saying that major semi companies are hiring Verilog designers proves
they are dropping VHDL makes no sense. Claiming that Verilog is three
times more productive than VHDL is an extraordinary claim which needs to
be supported by more than a single trial with a small number of
programmers and some personal anecdotes.
I'm am happy to end this discussion. I don't think you have any
questions of me, so I expect we are done.
--
Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-11 15:22 -0700 |
| Message-ID | <5e54dd0b-67d3-4ab5-b7b7-b1a0f5960666@googlegroups.com> |
| In reply to | #33835 |
On Friday, October 10, 2014 6:33:19 PM UTC-7, Bernd Paysan wrote: > rickman wrote: > >> If I wanted to program boilerplates, I would be doing Java. > > > You can use hyperbole if you want, but I'd like to be clear on this. If > > you need to add two or three libraries to the boilerplate of your code, > > you consider that to be a problem??? > > It's as simple as that: Boilerplating is a problem. The more boilerplate > you need, the more of a problem. If you can remove boilerplate, it's good. > ... > > Are you saying you don't use any boilerplate? > > I'm saying that boilerplate is a problem, not a solution. If I can get away > without any boilerplate, then I do. > > Seems to be a pretty alien concept to you. > > Like Forth, Verilog hasn't had separate compilation at start (modern tools > support it, but they also support to recognize unchanged modules on > reinvocation, so it's a non-issue). So you had one file, and other files > could be loaded with `include "filename". So if you use a library, you > specify it in the loader file, once for the entire project. That's what you > do with Forth projects, too. > > If you write a Java project, every class has to reside in a file of its own. > All the common libraries you use in the entire project go to the > boilerplate, instead of going into the loader file. You can keep every > class (or whatever conceptual unit you have) in one file in your Forth > project, as well, but since it's just loaded from the loader file, all > common libraries don't have to be specified in each file. > > People who are used to boilerplates are used to cut&paste, and what I've > often seen is that they copy a big portion of their previous code to change > it to their next code. A significant portion of the 5000 VHDL lines I had > mentioned were created by cut&paste, and then when a bug was discovered in > one copy, you had to go through all other copies to fix those bugs, too. > > You might think you get more LoCs per hour out with cut&paste style > programming, but in the end, you don't. I agree with all of this. Boiler-plate programming is for script-kiddies who paste other people's code into their programs without understanding it --- most or all are college graduates who learned to do this in Java class --- few or none will ever write a program of their own, or ever show the tiniest flicker of creativity. I'm convinced --- if I ever delve into HDL it will be Verilog rather than VHDL --- rather unlikely that I ever will get into hardware as I don't even know how to solder at this time, but it is possible.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-11 22:24 -0400 |
| Message-ID | <m1copc$7h3$1@dont-email.me> |
| In reply to | #33848 |
On 10/11/2014 6:22 PM, hughaguilar96@yahoo.com wrote: > > I agree with all of this. Boiler-plate programming is for script-kiddies who paste other people's code into their programs without understanding it --- most or all are college graduates who learned to do this in Java class --- few or none will ever write a program of their own, or ever show the tiniest flicker of creativity. What about using your own boilerplate? Does that make you a script kiddie too? > I'm convinced --- if I ever delve into HDL it will be Verilog rather than VHDL --- rather unlikely that I ever will get into hardware as I don't even know how to solder at this time, but it is possible. When it comes to most programmable logic, soldering is not only unneeded, it is nearly impossible unless you have either great skills or surface mount equipment. Just buy a board with the chips on it and go to town! Heck, to get started you don't even need a board. If you follow a few simple rules and work from templates (notice I didn't say boilerplate) once your code passes simulation you are very unlikely to have a problem with it in synthesis... other than timing possibly. The big mistake programmers make is thinking they are "programming" hardware. In any HDL you are *describing* hardware or the hardware actions. Templates are the best way to get started. If you try to get creative you will learn a lot about what doesn't synthesize or doesn't synthesize well. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-11 09:23 +0000 |
| Subject | Loading libraries (was: Metrics on stack usage) |
| Message-ID | <2014Oct11.112320@mips.complang.tuwien.ac.at> |
| In reply to | #33825 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>rickman wrote:
>
>> Now you are in troll land. If you can't handle two or three library
>> references, how do you ever work in Forth? You don't use any libraries?
>
>Actually, Forth has this great feature of allowing to save the image (even
>though that is not mentioned in a standard, all good Forth systems can do
>that). I just load in the libraries I need, save a new image, and then use
>that to write my programs in. This is really very helpful.
>
>No need to boilerplate every single program with all the 100 libraries you
>use all the time, or to recompile all those 100 libraries each time you
>change your program.
I like my programs to have self-contained source, so my source code
contains the REQUIREs of the libraries it needs. I normally don't do
images, because the compiler compiles the source code fast enough, but
if I did an image with the usual libraries loaded, I would not change
the source code. REQUIRE would just notice that the library is
already loaded and skip the file.
If the library code resides in 100 source files, that does not add 100
INCLUDEs to my main program, but instead there are REQUIREs of the
libaries that the main program needs in the main program (typically
very few), and REQUIREs of the files that the libraries themselves
need in the libraries. That's one reason why I prefer REQUIRE over
the load-screen approach (one FILE with lots of INCLUDEs) advocated by
some: every file is self-contained and loads the libraries it needs by
itself.
The REQUIREs in the main program are not boilerplate code, otherwise
there would be just one "REQUIRE boilerplate.fs" in the main program,
and boilerplate.fs would contain the REQUIREs of the libraries.
- 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-10 16:11 -0700 |
| Message-ID | <4ad0e157-349c-4752-ba20-50e6c856cc0b@googlegroups.com> |
| In reply to | #33799 |
On Thursday, October 9, 2014 8:03:20 PM UTC-7, Bernd Paysan wrote: > VHDL is certainly like Ada, and nowhere like Forth. Verilog is like C, I'm > fine with that description. I'd love to see a HDL which is based on Forth, > and works like Forth - simple, stack-based, implicit where possible (e.g. > most modules have a single clock and a single reset - no need to name > those), with tools optimized for the 90% you need. > > Ada and Forth are certainly two very opposite directions of programming > languages for the same job (low-level control stuff). At Testra, they had their own HDL that they wrote in UR/Forth --- this is what was used to get the MiniForth running on the Lattice isp1048 PLD. Routing is an intractable problem. There is no algorithm for doing this optimally (at least, not one that will finish within the lifetime of the universe). Routing is all done by guess and by golly, with a few heuristics. Testra's HDL did a better job at this than any commercial HDL (including Lattice's own), which is why they were able to fit the MiniForth on the isp1048 --- those PLDs are normally just used for glue logic --- getting a 16-bit micro-processor on a PLD was quite a feat in 1994. The MiniForth has since been ported over to an FPGA. PLDs don't exist anymore (they do exist, but they are actually FPGAs internally). Testra is no longer able to use their HDL because the FPGA manufacturers don't provide enough information regarding the internal workings of their chip for people to write their own HDL. Testra had to switch over to a commercial HDL (I don't know if it was Verilog or VHDL). I was told that the commercial HDL doesn't do a very good job of routing, and so a bigger FPGA is needed than would be needed if the routing was more efficient. There are big FPGAs available though, so people just put up with the inefficiency. > It wasn't that ancient; the tools are of course better now (I hope the tools > always get better), but yes, VHDL certainly is not for me, so I won't > reconsidder it. I don't think it has anything of value to offer. Why are you arguing with Rick? Perhaps you expect him to say: "You're right! I should switch from VHDL to Verilog --- why didn't you tell me sooner?" The internet is full of arguments like this. In the handgun world, there is the debate between the 9mm and the .45-ACP. These arguments are pointless. If a person has invested $600-$1200 on his handgun, how likely is it that he is going to admit that he made a mistake and bought the wrong kind? Also, both of them do the job perfectly well, and there is no scientific way to compare them (nobody is volunteering to be on the receiving end of either). Posting messages on the internet arguing about which is better, is just a waste of bytes ------ bytes that could have been used to hold actual information. I don't think that either one of you know very much about HDL, because neither of you have never written an HDL. Too late now though, because the modern FPGA manufacturers don't provide enough information about the internal workings of their chips for people to write their own HDL --- they want you to be "users" --- both of you are users, and you are each very loyal to the commercial product that you use.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-10-10 16:36 -0700 |
| Message-ID | <0be8c1c3-54b5-419c-b9ef-597df07c95ca@googlegroups.com> |
| In reply to | #33828 |
On Friday, October 10, 2014 4:11:34 PM UTC-7, hughag...@yahoo.com wrote: > I don't think that either one of you know very much about HDL, because neither of you have never written an HDL. This was a typo. I meant to say: "neither of you have not never written an HDL." ;-)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-10 22:38 -0400 |
| Message-ID | <m1a58s$95d$1@dont-email.me> |
| In reply to | #33828 |
On 10/10/2014 7:11 PM, hughaguilar96@yahoo.com wrote: > On Thursday, October 9, 2014 8:03:20 PM UTC-7, Bernd Paysan wrote: >> VHDL is certainly like Ada, and nowhere like Forth. Verilog is like C, I'm >> fine with that description. I'd love to see a HDL which is based on Forth, >> and works like Forth - simple, stack-based, implicit where possible (e.g. >> most modules have a single clock and a single reset - no need to name >> those), with tools optimized for the 90% you need. >> >> Ada and Forth are certainly two very opposite directions of programming >> languages for the same job (low-level control stuff). > > At Testra, they had their own HDL that they wrote in UR/Forth --- this is what was used to get the MiniForth running on the Lattice isp1048 PLD. > > Routing is an intractable problem. There is no algorithm for doing this optimally (at least, not one that will finish within the lifetime of the universe). Routing is all done by guess and by golly, with a few heuristics. Testra's HDL did a better job at this than any commercial HDL (including Lattice's own), which is why they were able to fit the MiniForth on the isp1048 --- those PLDs are normally just used for glue logic --- getting a 16-bit micro-processor on a PLD was quite a feat in 1994. Routing is not done by the HDL and is normally completely independent of the language used if a language is used at all (remember schematics?) In PLDs and FPGAs the design description is converted to a netlist. This netlist is in open formats. The tool that processes the netlist is typically called Place and Route (although they are really two separate tools that run sequentially). They produce another form of netlist that is typically proprietary although it has been reverse engineered without difficulty. The final step is to produce a bit stream specifying the state of all the configuration control points. This step is tightly controlled and the output format is very much proprietary and confidential. > The MiniForth has since been ported over to an FPGA. PLDs don't exist anymore (they do exist, but they are actually FPGAs internally). Testra is no longer able to use their HDL because the FPGA manufacturers don't provide enough information regarding the internal workings of their chip for people to write their own HDL. Testra had to switch over to a commercial HDL (I don't know if it was Verilog or VHDL). I was told that the commercial HDL doesn't do a very good job of routing, and so a bigger FPGA is needed than would be needed if the routing was more efficient. There are big FPGAs available though, so people just put up with the inefficiency. If there was still utility to using the proprietary HDL it could be done easily. It merely needs to produce a EDIF netlist which can then be processed by the FPGA vendor's tools to produce a bitstream. I expect they have abandoned their own HDL because it provides no advantage. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-10-17 23:39 -0400 |
| Message-ID | <op.xnwpslkomk81un@localhost> |
| In reply to | #33828 |
On Fri, 10 Oct 2014 19:11:33 -0400, <hughaguilar96@yahoo.com> wrote: > In the handgun world, there is the debate between the 9mm and the > .45-ACP. These arguments are > pointless. If a person has invested $600-$1200 on his handgun, how > likely is it that he is going to admit that he made a mistake and bought > the wrong kind? Also, both of them do the job perfectly well, and there > is no scientific way to compare them (nobody is volunteering to be on > the receiving end of either). Wrong. The .45-ACP was proven more effective by U.S. military tests. The .45-ACP and 9mm along with other common rounds were tested on human cadavers, live steers, and live horses by the U.S. military in 1904. The British also fired into human cadavers and live animals during their ammo tests in the 1920's. The .45-ACP and other rounds (not including 9mm) was tested on human cadavers and live pigs by the U.S. military in 1928, with and without body armor on each. > Posting messages on the internet arguing > about which is better, is just a waste of bytes ------ bytes that > could have been used to hold actual information. Ironic. Mr. Rant himself says other people are wasting bytes ... Personally, I find it quite funny that "rickman" and Bernd are in a discussion together. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Paul E Bennett <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2014-10-11 12:25 +0100 |
| Message-ID | <c9sid1Fd2qqU1@mid.individual.net> |
| In reply to | #33713 |
rickman wrote: [%X] > We aren't talking about "preferences", we are talking about skill sets. > I know my techniques of design and debug have changed several times > over my career. That is something I find quite interesting. Having been in Engineering for more than 40 years, I adopted my own Development Process and have been using it since 1982. I have introduced it to a few other companies also. My developments have ranged from small embedded systems through to quite large PLC based SCADA systems and the basic techniques have remained quite similar on all of those systems in all of that time. Many of my systems have to meet SIL3 and SIL4 levels of Safety Assurity. My development process model was shared at this years EuroForth and an overview can be found in the presentation slides which will be on the EuroForth web-site as soon as Anton manages to update it. >>> I'm not sure the "fast turnaround time" is that big an advantage. I >>> seem to recall the last time I used a C compiler that it produced >>> results in a small number of seconds. But then I suppose that depends >>> on the size of the program. >> >> Sure. And maybe you underestimate the effect of "a few seconds": The >> flow >> of thinking is definitely broken if you insert a pause of 3 seconds. >> That is some sort of "upper limit" of time you can wait for, but it's >> much better >> if you have a delay no more than 0.3 seconds. You should listen to >> people who do GUIs and do the actual measurements about how >> non-responsive functions cause problems; this sort of "instant feedback" >> you get from Forth is really important. > > I am familiar with the Doherty threshold... lol The compile step is a > natural change of pace in thinking, so the same issue you have in a GUI > doesn't apply to the same extent. When changing from editing to > compile/test the mode of thinking is different so a delay of a small > number of seconds is much more readily accepted without impact on > performance. Interestingly, I am not so disturbed by the delays in the edit/compile cycle as that allows some reflection time for considering the rightness of what you were doing and the tests that you need to apply to ensure you have complied with the intent of your requirements. My developments tend to be more measured in pace but then I do spend nearly 60% of the project effort in getting the requirements specification correct and confirmable. I think there is more opportunity for technical review within my development process than most. However, when you are playing (experimenting with methods), as part of the specification nail-down, minimising the time between edit/compile/test is really valuable. Response time of systems is also very important. Trying to respond to interrupts created by the operator pressing a button several times in succession and at high rate might cause some systems never to initiate the action it was meant to be doing from that command. All because there was no obvious change of state reported back to the operator in reasonable time. Consider a touch-button on a GUI HMI screen that, when clicked on or touched, will change the state of a pump in the system. One touch will start the pump and a second touch will stop the pump (I know it is a poor GUI HMI design issue, but I have seen this in practice). The button is supposed to change colour to signify the state of the pump. Knowing that they were not about to re-design the GUI layout it became important to flash a different colour of the button to indicate that the press had been registered as soon as the touch button press released (the standard edge detect being used). This simple colour change helped the operator know the system had seen his command and was dealing with it (there were alarms if the comms between the HMI and the plant were not operating correctly). The final colour indicated the true state of the plant. Plant operators can get very concerned if they have a system that is slow in responding to what they have just done. You have to give them some indication that the system has seen their requests and is doing something about it. Software Engineering is a much wider topic than just bashing out some code. -- ******************************************************************** 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]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web