Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #57698 > unrolled thread
| Started by | JUERGEN <epldfpga@aol.com> |
|---|---|
| First post | 2017-04-21 00:49 -0700 |
| Last post | 2017-04-26 01:38 -0400 |
| Articles | 20 on this page of 195 — 20 participants |
Back to article view | Back to comp.lang.forth
Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-21 00:49 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-21 01:17 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-21 01:47 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-21 18:55 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Clive Arthur <cliveta@nowaytoday.co.uk> - 2017-04-22 19:48 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-22 14:50 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 00:23 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-23 11:13 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 16:14 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-23 19:34 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 21:52 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-23 21:59 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 02:20 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 04:04 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 13:40 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 14:41 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 18:22 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 15:28 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 18:44 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 19:34 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 16:41 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 20:36 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 04:44 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 12:41 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 10:03 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 12:20 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 14:12 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 15:13 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 16:59 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 14:35 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 17:19 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 15:36 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-25 01:26 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 11:21 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 09:50 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 12:37 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 14:11 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 13:51 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 15:14 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 14:15 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 11:34 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 11:38 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 11:39 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 14:00 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 15:15 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 12:27 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 16:04 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 13:36 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 17:03 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 12:42 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 12:55 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 15:16 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 14:22 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 15:51 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 13:27 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 13:19 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 11:38 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 13:59 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 12:36 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 14:49 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 14:29 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 16:30 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 15:57 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 17:11 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 14:12 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 17:38 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 16:41 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 15:11 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 17:32 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-26 03:33 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 11:33 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-26 14:05 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 17:24 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-26 14:51 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 18:29 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-26 16:18 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 21:07 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-27 01:52 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-27 02:10 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-27 02:22 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:10 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:25 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:08 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Alex <alex@rivadpm.com> - 2017-04-27 16:14 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Alex <alex@rivadpm.com> - 2017-04-27 16:17 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:46 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-27 14:07 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 17:58 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-26 20:34 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 01:07 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-27 21:21 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-28 08:54 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-28 10:46 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-27 10:46 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-27 12:05 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:50 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-28 11:23 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started john <anon@example.com> - 2017-04-27 11:43 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:57 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:21 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 11:58 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-28 07:53 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-28 22:31 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-28 20:14 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-30 16:08 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-29 13:48 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-29 10:45 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-27 15:49 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-29 00:27 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-28 20:28 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-29 14:15 +0000
Stack processor address regs . was Ting's EP32 32 Bit Processor Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-05-01 13:45 +0100
Re: Stack processor address regs . was Ting's EP32 32 Bit Processor anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-02 13:15 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started jim.brakefield@ieee.org - 2017-04-28 18:20 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Coos Haak <htrofhc@gmail.com> - 2017-04-29 13:00 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-29 11:47 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Coos Haak <htrofhc@gmail.com> - 2017-04-29 15:02 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started jim.brakefield@ieee.org - 2017-04-30 18:32 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-26 20:40 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 01:21 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-26 21:14 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-27 02:17 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-27 05:05 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started john <anon@example.com> - 2017-04-27 13:35 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-27 05:42 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Alex <alex@rivadpm.com> - 2017-04-27 14:00 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-27 06:04 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Alex <alex@rivadpm.com> - 2017-04-27 15:31 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 12:26 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Julian Fondren <julian.fondren@gmail.com> - 2017-04-29 08:04 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started john <anon@example.com> - 2017-04-27 10:30 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 12:32 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started john <anon@example.com> - 2017-04-28 12:01 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-26 21:34 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-27 01:26 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-27 21:25 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-28 02:50 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started pahihu <pahihu@gmail.com> - 2017-04-28 00:23 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-28 07:46 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Mark Wills <markwills1970@gmail.com> - 2017-04-28 02:25 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-28 05:35 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Walter Banks <walter@bytecraft.com> - 2017-04-28 14:55 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 13:58 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-26 04:11 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-25 19:54 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 14:32 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-25 23:25 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 14:40 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-23 14:27 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 20:35 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-23 19:09 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Clive Arthur <cliveta@nowaytoday.co.uk> - 2017-04-25 15:33 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Walter Banks <walter@bytecraft.com> - 2017-04-25 13:20 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 14:00 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Walter Banks <walter@bytecraft.com> - 2017-04-26 14:27 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 13:58 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-25 20:15 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 15:07 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-25 21:37 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-26 14:28 +0000
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 12:17 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Clive Arthur <cliveta@nowaytoday.co.uk> - 2017-04-26 18:48 +0100
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-26 21:15 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Paul Rubin <no.email@nospam.invalid> - 2017-04-25 18:39 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 00:25 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-26 09:58 +0200
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 17:43 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 13:10 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 16:42 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 16:06 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 14:25 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 17:52 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-23 00:18 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-22 13:28 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-23 05:06 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-23 06:38 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-23 11:24 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-23 12:17 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-23 23:43 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 04:16 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started JUERGEN <epldfpga@aol.com> - 2017-04-24 06:18 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 14:28 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 17:00 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 15:10 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 17:43 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 16:40 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-24 21:16 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-25 09:42 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Cecil Bayona <cbayona@cbayona.com> - 2017-04-25 12:22 -0500
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-24 14:28 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-24 15:03 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 15:39 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-25 20:44 -0400
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started hughaguilar96@gmail.com - 2017-04-25 22:25 -0700
Re: Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started rickman <gnuarm@gmail.com> - 2017-04-26 01:38 -0400
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-25 14:29 -0500 |
| Message-ID | <odo7sl$ero$1@dont-email.me> |
| In reply to | #58119 |
On 4/25/2017 1:49 PM, rickman wrote: > On 4/25/2017 2:19 PM, Cecil Bayona wrote: >> >> An example in my life was writing complex software in C, it became a >> major problem in C finding bugs that crashed the system. I was going >> insane trying to find the bugs, there was a lot of pressure as the >> client was using the software and demanded stability. I bit the bullet >> and wrote a program to translate the C code into Borland Pascal, after a >> weekend of getting the translator to work right I had a working version >> of the software in Borland Pascal, I then turned on all the safety >> features in the Borland compiler on and re-compiled the code, within >> less than an hour the Borland run code started complaining about >> problems, mostly uninitialized pointers, after fixing them the customer >> mentioned that in over a week the system had not crashed or glitched >> once, this was a big life lesson. > > What was the underlying cause of these problems? It wasn't the C compiler. Not the compiler but the language is like the Wild West anything goes so if one is not careful you can have mistakes that are difficult to find. Pascal and Go are languages that are restricted and check for dumb issues. > > >> After that experience I stopped using C for projects, Borland Pascal's >> compile and run-time checks would catch all sorts of dumb mistakes that >> I would have missed using C. It didn't take long to get used to Pascals >> wordier way of writing code, and the requirement of explicit casting, in >> the end I could write code in my sleep in Borland Pascal and did not get >> nasty surprises, it was worth the effort. > > Did you consider the idea of not writing bad code in the first place? > That's where you are with Forth. It has very little in the way of > compiler checks. You have to avoid mistakes by not writing them. > > Personally I find it interesting that I use VHDL and Forth. I don't > think you can find two more opposite languages in terms of error checking. Ah now you are getting to the root cause, writing bad code is too easy, and if you are in a hurry you can miss things that will burn you later. But like you I like Forth which has no checks for anything so what is the difference? C is usually written top down with a lot of code being written before one can test anything, this leads to more bugs, one is building on a foundation of untested code. Forth also is like the Wild West but one writes code in a totally different way. One writes Forth mostly bottom up, writing small routines that are easily tested before using them elsewhere, the result is relatively error free code. C on the hand with its lengthy edit, compile, then test way of doing things encourages one to add a lot of untested code to a program which then tends to have more bugs. One of the reasons for looking at Go is it's lightning fast compiler which makes it more similar to Forth than to C but still Forth is wonderful for testing software as you go by it interactive nature and it's culture of writing small procedures that are easily tested, that is possible because the low overhead in calling small procedures. So they could be opposite but the both can work out well. > > >> The moral learned was pay now pay later, later bring interest payments >> with it so it's far better to pay now. This indecision between Verilog >> and VHDL seems a lot similar to my issues between C and Borland Pascal >> so maybe that experience applies here too. > > I have made a lot of money by paying later. I bought two houses on > mortgages and both are paid off now with values higher than the cost of > the loans. By paying cash I would barely be buying the first one now, > if that! Not applicable here. > > >> When I first wanted to start this software project I dug out my old >> copies of Borland Pascal but the problem is that they would not install >> or run with Windows 10 so that reliable and efficient software was out >> of the picture since a new copy is out of reach due to it's cost of over >> $1400 for the professional version, that is why I started looking at Go, >> efficient yet full of checks to keep you out of trouble. > > Oh, so you don't use Forth much then? Is that just a hobby thing with you? > For a long time large applications were written in Delphi, smaller tools were written in Forth, that worked out well as large applications needed a lot of libraries not available in Forth. Small tools specially if they interfaced to hardware were a lot easier to write and debug in Forth so it was a tool to be used when the purpose suited it, when it does then it's a wonderful language where one can write error free code like no other. Actually Forth can be good for large applications but one needs libraries to accomplish some complicated task, according to people here it's to be avoided. For Delphi I wrote some B Tree Database routines that were incredibly fast but it took a while to debug them and the code was fairly large some here insist that it be written for each application, that is insane so for large applications I had all sorts of libraries in Delphi that were tested and made my life much easier. > I just don't end up adding bugs to my code so much. With Forth the > small unit testing works very well. With VHDL I spend a lot of time > thinking about how the code will work together, then simulation finds > the bugs much more easily than running in the chip. > > I seriously think it was an epiphany for me when Jeff Fox wrote that > stack errors just mean the programmer can't count. Avoiding stack > errors is literally that simple, count the parameters added and removed > from the stack. A compiler isn't needed to find those errors, just as, > in my opinion, a compiler isn't needed to find uninitialized pointers. > Heck, we had to perform requirements traceability analysis which was all > done by hand. Why can't uninitialized pointers be found as you code? > In C one can write a lot of code before anything is tested and somewhere along the line a pointer might not have been initialized, it's easy to miss sometimes. With Forth that is not much of an issue all routines are small so you can see what you are doing. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-25 16:30 -0400 |
| Message-ID | <odobfr$r8b$1@dont-email.me> |
| In reply to | #58128 |
On 4/25/2017 3:29 PM, Cecil Bayona wrote: > On 4/25/2017 1:49 PM, rickman wrote: >> On 4/25/2017 2:19 PM, Cecil Bayona wrote: >>> >>> An example in my life was writing complex software in C, it became a >>> major problem in C finding bugs that crashed the system. I was going >>> insane trying to find the bugs, there was a lot of pressure as the >>> client was using the software and demanded stability. I bit the bullet >>> and wrote a program to translate the C code into Borland Pascal, after a >>> weekend of getting the translator to work right I had a working version >>> of the software in Borland Pascal, I then turned on all the safety >>> features in the Borland compiler on and re-compiled the code, within >>> less than an hour the Borland run code started complaining about >>> problems, mostly uninitialized pointers, after fixing them the customer >>> mentioned that in over a week the system had not crashed or glitched >>> once, this was a big life lesson. >> >> What was the underlying cause of these problems? It wasn't the C >> compiler. > > Not the compiler but the language is like the Wild West anything goes so > if one is not careful you can have mistakes that are difficult to find. > Pascal and Go are languages that are restricted and check for dumb issues. The problem isn't the tool. I may not be the world's best expert in anything, but one thing I have learned is that mistakes are made by people and only people can prevent them. One of the most rigorous processes for avoiding mistakes is that used to design and build nuclear reactors and yet nuclear reactors have problems and even accidents. I'm not suggesting that we should build nuclear reactors without processes to minimize mistakes. I'm saying that for software development you can do a very decent job by using the sorts of methods we use in programming in Forth which is to simplify the problems in ways that make the mistakes easier to avoid. You said it yourself, "if one is not careful you can have mistakes"... So program with intent and test early and often. I guess I have very seldom seen a compiler prevent me from making a mistake that was, "difficult to find". Those mistakes require a human. ;) >>> After that experience I stopped using C for projects, Borland Pascal's >>> compile and run-time checks would catch all sorts of dumb mistakes that >>> I would have missed using C. It didn't take long to get used to Pascals >>> wordier way of writing code, and the requirement of explicit casting, in >>> the end I could write code in my sleep in Borland Pascal and did not get >>> nasty surprises, it was worth the effort. >> >> Did you consider the idea of not writing bad code in the first place? >> That's where you are with Forth. It has very little in the way of >> compiler checks. You have to avoid mistakes by not writing them. >> >> Personally I find it interesting that I use VHDL and Forth. I don't >> think you can find two more opposite languages in terms of error >> checking. > > Ah now you are getting to the root cause, writing bad code is too easy, > and if you are in a hurry you can miss things that will burn you later. Huh? Not sure what I said about that. But don't be in a hurry. It has been documented many, many times that spending time up front on analysis and proper design methods will get you to a finished product faster than rushing. The hurrier I go, the behinder I get. > But like you I like Forth which has no checks for anything so what is > the difference? The difference is a huge amount of work you spend in VHDL coding and the huge amount of work you spend in Forth with low level testing. I would prefer that testing were easier in VHDL. The issue is not so much the effort required to design a test bench. For me it is the tools which require you to set up a project and designate folders and all manner of initialization to begin a simulation. The tool providers seem to be very focused on the "BIG" picture and not the little ones, so the little efforts are hard. > C is usually written top down with a lot of code being written before > one can test anything, this leads to more bugs, one is building on a > foundation of untested code. Nonesense. Forth is often written top down with testing by using stubs. Or C can be *designed* top down and written/tested bottom up. > Forth also is like the Wild West but one writes code in a totally > different way. One writes Forth mostly bottom up, writing small > routines that are easily tested before using them elsewhere, the result > is relatively error free code. C on the hand with its lengthy edit, > compile, then test way of doing things encourages one to add a lot of > untested code to a program which then tends to have more bugs. Don't confuse writing code with design. Sounds to me like you aren't used to performing design separate from coding. > One of the reasons for looking at Go is it's lightning fast compiler > which makes it more similar to Forth than to C but still Forth is > wonderful for testing software as you go by it interactive nature and > it's culture of writing small procedures that are easily tested, that is > possible because the low overhead in calling small procedures. > > So they could be opposite but the both can work out well. > >> >> >>> The moral learned was pay now pay later, later bring interest payments >>> with it so it's far better to pay now. This indecision between Verilog >>> and VHDL seems a lot similar to my issues between C and Borland Pascal >>> so maybe that experience applies here too. >> >> I have made a lot of money by paying later. I bought two houses on >> mortgages and both are paid off now with values higher than the cost >> of the loans. By paying cash I would barely be buying the first one >> now, if that! > > Not applicable here. It was your analogy... ;) >>> When I first wanted to start this software project I dug out my old >>> copies of Borland Pascal but the problem is that they would not install >>> or run with Windows 10 so that reliable and efficient software was out >>> of the picture since a new copy is out of reach due to it's cost of over >>> $1400 for the professional version, that is why I started looking at Go, >>> efficient yet full of checks to keep you out of trouble. >> >> Oh, so you don't use Forth much then? Is that just a hobby thing with >> you? >> > > For a long time large applications were written in Delphi, smaller tools > were written in Forth, that worked out well as large applications needed > a lot of libraries not available in Forth. Small tools specially if they > interfaced to hardware were a lot easier to write and debug in Forth so > it was a tool to be used when the purpose suited it, when it does then > it's a wonderful language where one can write error free code like no > other. > > Actually Forth can be good for large applications but one needs > libraries to accomplish some complicated task, according to people here > it's to be avoided. What's to be avoided??? Using libraries or accomplishign complicated tasks? > For Delphi I wrote some B Tree Database routines > that were incredibly fast but it took a while to debug them and the code > was fairly large some here insist that it be written for each > application, that is insane so for large applications I had all sorts of > libraries in Delphi that were tested and made my life much easier. > >> I just don't end up adding bugs to my code so much. With Forth the >> small unit testing works very well. With VHDL I spend a lot of time >> thinking about how the code will work together, then simulation finds >> the bugs much more easily than running in the chip. >> >> I seriously think it was an epiphany for me when Jeff Fox wrote that >> stack errors just mean the programmer can't count. Avoiding stack >> errors is literally that simple, count the parameters added and >> removed from the stack. A compiler isn't needed to find those errors, >> just as, in my opinion, a compiler isn't needed to find uninitialized >> pointers. Heck, we had to perform requirements traceability analysis >> which was all done by hand. Why can't uninitialized pointers be found >> as you code? >> > > In C one can write a lot of code before anything is tested and somewhere > along the line a pointer might not have been initialized, it's easy to > miss sometimes. That is not at all related to the language. You can do stupid things in any language. > With Forth that is not much of an issue all routines are small so you > can see what you are doing. They are only small if you write them small. In VHDL I try to keep my modules small although that has a different meaning than in Forth. I want to try coding the bulk of my work in procedures sometime. I know people who do that, but I don't see how what they are doing is very useful. One in particular would separate the three sections of a sequential process. One was initialization but I can't think what the other two were. Anyway, he would code the three sections as procedures which sounds nice from a Forth perspective, but there is no way to test a procedure in VHDL without the supporting code. He thought it provided more organized code, but I didn't see the difference since the three sections are all very apparent when coded inline. They are all dealing with the same signals and variables, so I just didn't see the advantage in splitting them up. So while I think most aspects of design, coding and testing we have talked about are language agnostic, Forth does lend itself to smaller module sizes. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-25 15:57 -0500 |
| Message-ID | <odod1e$1aa$1@dont-email.me> |
| In reply to | #58138 |
On 4/25/2017 3:30 PM, rickman wrote: > On 4/25/2017 3:29 PM, Cecil Bayona wrote: >> On 4/25/2017 1:49 PM, rickman wrote: >>> On 4/25/2017 2:19 PM, Cecil Bayona wrote: >>>> >>>> An example in my life was writing complex software in C, it became a >>>> major problem in C finding bugs that crashed the system. I was going >>>> insane trying to find the bugs, there was a lot of pressure as the >>>> client was using the software and demanded stability. I bit the bullet >>>> and wrote a program to translate the C code into Borland Pascal, >>>> after a >>>> weekend of getting the translator to work right I had a working version >>>> of the software in Borland Pascal, I then turned on all the safety >>>> features in the Borland compiler on and re-compiled the code, within >>>> less than an hour the Borland run code started complaining about >>>> problems, mostly uninitialized pointers, after fixing them the customer >>>> mentioned that in over a week the system had not crashed or glitched >>>> once, this was a big life lesson. >>> >>> What was the underlying cause of these problems? It wasn't the C >>> compiler. >> >> Not the compiler but the language is like the Wild West anything goes so >> if one is not careful you can have mistakes that are difficult to find. >> Pascal and Go are languages that are restricted and check for dumb >> issues. > > The problem isn't the tool. I may not be the world's best expert in > anything, but one thing I have learned is that mistakes are made by > people and only people can prevent them. > > One of the most rigorous processes for avoiding mistakes is that used to > design and build nuclear reactors and yet nuclear reactors have problems > and even accidents. > > I'm not suggesting that we should build nuclear reactors without > processes to minimize mistakes. I'm saying that for software > development you can do a very decent job by using the sorts of methods > we use in programming in Forth which is to simplify the problems in ways > that make the mistakes easier to avoid. > > You said it yourself, "if one is not careful you can have mistakes"... > So program with intent and test early and often. > > I guess I have very seldom seen a compiler prevent me from making a > mistake that was, "difficult to find". Those mistakes require a human. ;) > > >>>> After that experience I stopped using C for projects, Borland Pascal's >>>> compile and run-time checks would catch all sorts of dumb mistakes that >>>> I would have missed using C. It didn't take long to get used to Pascals >>>> wordier way of writing code, and the requirement of explicit >>>> casting, in >>>> the end I could write code in my sleep in Borland Pascal and did not >>>> get >>>> nasty surprises, it was worth the effort. >>> >>> Did you consider the idea of not writing bad code in the first place? >>> That's where you are with Forth. It has very little in the way of >>> compiler checks. You have to avoid mistakes by not writing them. >>> >>> Personally I find it interesting that I use VHDL and Forth. I don't >>> think you can find two more opposite languages in terms of error >>> checking. >> >> Ah now you are getting to the root cause, writing bad code is too easy, >> and if you are in a hurry you can miss things that will burn you later. > > Huh? Not sure what I said about that. But don't be in a hurry. It has > been documented many, many times that spending time up front on analysis > and proper design methods will get you to a finished product faster than > rushing. The hurrier I go, the behinder I get. > > >> But like you I like Forth which has no checks for anything so what is >> the difference? > > The difference is a huge amount of work you spend in VHDL coding and the > huge amount of work you spend in Forth with low level testing. I would > prefer that testing were easier in VHDL. The issue is not so much the > effort required to design a test bench. For me it is the tools which > require you to set up a project and designate folders and all manner of > initialization to begin a simulation. The tool providers seem to be > very focused on the "BIG" picture and not the little ones, so the little > efforts are hard. > > >> C is usually written top down with a lot of code being written before >> one can test anything, this leads to more bugs, one is building on a >> foundation of untested code. > > Nonesense. Forth is often written top down with testing by using stubs. > Or C can be *designed* top down and written/tested bottom up. > > >> Forth also is like the Wild West but one writes code in a totally >> different way. One writes Forth mostly bottom up, writing small >> routines that are easily tested before using them elsewhere, the result >> is relatively error free code. C on the hand with its lengthy edit, >> compile, then test way of doing things encourages one to add a lot of >> untested code to a program which then tends to have more bugs. > > Don't confuse writing code with design. Sounds to me like you aren't > used to performing design separate from coding. > > >> One of the reasons for looking at Go is it's lightning fast compiler >> which makes it more similar to Forth than to C but still Forth is >> wonderful for testing software as you go by it interactive nature and >> it's culture of writing small procedures that are easily tested, that is >> possible because the low overhead in calling small procedures. >> >> So they could be opposite but the both can work out well. >> >>> >>> >>>> The moral learned was pay now pay later, later bring interest payments >>>> with it so it's far better to pay now. This indecision between Verilog >>>> and VHDL seems a lot similar to my issues between C and Borland Pascal >>>> so maybe that experience applies here too. >>> >>> I have made a lot of money by paying later. I bought two houses on >>> mortgages and both are paid off now with values higher than the cost >>> of the loans. By paying cash I would barely be buying the first one >>> now, if that! >> >> Not applicable here. > > It was your analogy... ;) > > >>>> When I first wanted to start this software project I dug out my old >>>> copies of Borland Pascal but the problem is that they would not install >>>> or run with Windows 10 so that reliable and efficient software was out >>>> of the picture since a new copy is out of reach due to it's cost of >>>> over >>>> $1400 for the professional version, that is why I started looking at >>>> Go, >>>> efficient yet full of checks to keep you out of trouble. >>> >>> Oh, so you don't use Forth much then? Is that just a hobby thing with >>> you? >>> >> >> For a long time large applications were written in Delphi, smaller tools >> were written in Forth, that worked out well as large applications needed >> a lot of libraries not available in Forth. Small tools specially if they >> interfaced to hardware were a lot easier to write and debug in Forth so >> it was a tool to be used when the purpose suited it, when it does then >> it's a wonderful language where one can write error free code like no >> other. >> >> Actually Forth can be good for large applications but one needs >> libraries to accomplish some complicated task, according to people here >> it's to be avoided. > > What's to be avoided??? Using libraries or accomplishign complicated > tasks? > > >> For Delphi I wrote some B Tree Database routines >> that were incredibly fast but it took a while to debug them and the code >> was fairly large some here insist that it be written for each >> application, that is insane so for large applications I had all sorts of >> libraries in Delphi that were tested and made my life much easier. >> >>> I just don't end up adding bugs to my code so much. With Forth the >>> small unit testing works very well. With VHDL I spend a lot of time >>> thinking about how the code will work together, then simulation finds >>> the bugs much more easily than running in the chip. >>> >>> I seriously think it was an epiphany for me when Jeff Fox wrote that >>> stack errors just mean the programmer can't count. Avoiding stack >>> errors is literally that simple, count the parameters added and >>> removed from the stack. A compiler isn't needed to find those errors, >>> just as, in my opinion, a compiler isn't needed to find uninitialized >>> pointers. Heck, we had to perform requirements traceability analysis >>> which was all done by hand. Why can't uninitialized pointers be found >>> as you code? >>> >> >> In C one can write a lot of code before anything is tested and somewhere >> along the line a pointer might not have been initialized, it's easy to >> miss sometimes. > > That is not at all related to the language. You can do stupid things in > any language. > > >> With Forth that is not much of an issue all routines are small so you >> can see what you are doing. > > They are only small if you write them small. In VHDL I try to keep my > modules small although that has a different meaning than in Forth. I > want to try coding the bulk of my work in procedures sometime. I know > people who do that, but I don't see how what they are doing is very > useful. One in particular would separate the three sections of a > sequential process. One was initialization but I can't think what the > other two were. Anyway, he would code the three sections as procedures > which sounds nice from a Forth perspective, but there is no way to test > a procedure in VHDL without the supporting code. He thought it provided > more organized code, but I didn't see the difference since the three > sections are all very apparent when coded inline. They are all dealing > with the same signals and variables, so I just didn't see the advantage > in splitting them up. > > So while I think most aspects of design, coding and testing we have > talked about are language agnostic, Forth does lend itself to smaller > module sizes. > One cannot write every detail of the software writing process in a email or news post, if I did I would have a book, picking at little details because it was not mentioned does not mean I'm not aware of them. Remember that, it makes for a more pleasant conversation. I have mentioned it here before when I write software I even have a notebook with all the software requirements, all the details of the software methodology including flowcharts and UML charts, I use State Diagrams when needed to document program/data triggers, and the source is well documented so I do plan the software well, but we are humans and we can make mistakes with the best of intentions. Some languages are more prone than others to allow mistakes to slip by, C is well known for that. I always write my Forth applications bottom up because Forth allows me to, I prefer writing software bottom up when it's practical because it eliminates a lot of low level mistakes and actually works quite well doing so. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-25 17:11 -0400 |
| Message-ID | <ododsi$3tn$1@dont-email.me> |
| In reply to | #58141 |
On 4/25/2017 4:57 PM, Cecil Bayona wrote: > > One cannot write every detail of the software writing process in a email > or news post, if I did I would have a book, picking at little details > because it was not mentioned does not mean I'm not aware of them. > Remember that, it makes for a more pleasant conversation. I can only read what you write. This is a great example. You seem to be addressing something I wrote, but you have not indicated what it was. So I have no idea what you are referring to and can only speculate. > I have mentioned it here before when I write software I even have a > notebook with all the software requirements, all the details of the > software methodology including flowcharts and UML charts, I use State > Diagrams when needed to document program/data triggers, and the source > is well documented so I do plan the software well, but we are humans and > we can make mistakes with the best of intentions. That's great. But we were discussing methods, not necessarily *your* methods. If you talk about coding from the top down interfering with testing that is the issue I respond to without knowing anything of how you design. > Some languages are more prone than others to allow mistakes to slip by, > C is well known for that. I always write my Forth applications bottom up > because Forth allows me to, I prefer writing software bottom up when > it's practical because it eliminates a lot of low level mistakes and > actually works quite well doing so. You can code C from the bottom up. The mistakes people make when coding C have to do with the people. C does not force you to make mistakes. There are methods of avoiding mistakes in C just as there are in any language. I think Forth leaves the doors wide open in that regard so why isn't Forth a language where you are prone to making uninitialized pointer mistakes? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-25 14:12 -0700 |
| Message-ID | <1fc05b7b-e81c-4d33-861c-609dce6b75b2@googlegroups.com> |
| In reply to | #58141 |
On Tuesday, April 25, 2017 at 1:57:18 PM UTC-7, Cecil - k5nwa wrote: > On 4/25/2017 3:30 PM, rickman wrote: > > On 4/25/2017 3:29 PM, Cecil Bayona wrote: > >> On 4/25/2017 1:49 PM, rickman wrote: > >>> On 4/25/2017 2:19 PM, Cecil Bayona wrote: > >>>> > >>>> An example in my life was writing complex software in C, it became a > >>>> major problem in C finding bugs that crashed the system. I was going > >>>> insane trying to find the bugs, there was a lot of pressure as the > >>>> client was using the software and demanded stability. I bit the bullet > >>>> and wrote a program to translate the C code into Borland Pascal, > >>>> after a > >>>> weekend of getting the translator to work right I had a working version > >>>> of the software in Borland Pascal, I then turned on all the safety > >>>> features in the Borland compiler on and re-compiled the code, within > >>>> less than an hour the Borland run code started complaining about > >>>> problems, mostly uninitialized pointers, after fixing them the customer > >>>> mentioned that in over a week the system had not crashed or glitched > >>>> once, this was a big life lesson. > >>> > >>> What was the underlying cause of these problems? It wasn't the C > >>> compiler. > >> > >> Not the compiler but the language is like the Wild West anything goes so > >> if one is not careful you can have mistakes that are difficult to find. > >> Pascal and Go are languages that are restricted and check for dumb > >> issues. > > > > The problem isn't the tool. I may not be the world's best expert in > > anything, but one thing I have learned is that mistakes are made by > > people and only people can prevent them. > > > > One of the most rigorous processes for avoiding mistakes is that used to > > design and build nuclear reactors and yet nuclear reactors have problems > > and even accidents. > > > > I'm not suggesting that we should build nuclear reactors without > > processes to minimize mistakes. I'm saying that for software > > development you can do a very decent job by using the sorts of methods > > we use in programming in Forth which is to simplify the problems in ways > > that make the mistakes easier to avoid. > > > > You said it yourself, "if one is not careful you can have mistakes"... > > So program with intent and test early and often. > > > > I guess I have very seldom seen a compiler prevent me from making a > > mistake that was, "difficult to find". Those mistakes require a human. ;) > > > > > >>>> After that experience I stopped using C for projects, Borland Pascal's > >>>> compile and run-time checks would catch all sorts of dumb mistakes that > >>>> I would have missed using C. It didn't take long to get used to Pascals > >>>> wordier way of writing code, and the requirement of explicit > >>>> casting, in > >>>> the end I could write code in my sleep in Borland Pascal and did not > >>>> get > >>>> nasty surprises, it was worth the effort. > >>> > >>> Did you consider the idea of not writing bad code in the first place? > >>> That's where you are with Forth. It has very little in the way of > >>> compiler checks. You have to avoid mistakes by not writing them. > >>> > >>> Personally I find it interesting that I use VHDL and Forth. I don't > >>> think you can find two more opposite languages in terms of error > >>> checking. > >> > >> Ah now you are getting to the root cause, writing bad code is too easy, > >> and if you are in a hurry you can miss things that will burn you later. > > > > Huh? Not sure what I said about that. But don't be in a hurry. It has > > been documented many, many times that spending time up front on analysis > > and proper design methods will get you to a finished product faster than > > rushing. The hurrier I go, the behinder I get. > > > > > >> But like you I like Forth which has no checks for anything so what is > >> the difference? > > > > The difference is a huge amount of work you spend in VHDL coding and the > > huge amount of work you spend in Forth with low level testing. I would > > prefer that testing were easier in VHDL. The issue is not so much the > > effort required to design a test bench. For me it is the tools which > > require you to set up a project and designate folders and all manner of > > initialization to begin a simulation. The tool providers seem to be > > very focused on the "BIG" picture and not the little ones, so the little > > efforts are hard. > > > > > >> C is usually written top down with a lot of code being written before > >> one can test anything, this leads to more bugs, one is building on a > >> foundation of untested code. > > > > Nonesense. Forth is often written top down with testing by using stubs. > > Or C can be *designed* top down and written/tested bottom up. > > > > > >> Forth also is like the Wild West but one writes code in a totally > >> different way. One writes Forth mostly bottom up, writing small > >> routines that are easily tested before using them elsewhere, the result > >> is relatively error free code. C on the hand with its lengthy edit, > >> compile, then test way of doing things encourages one to add a lot of > >> untested code to a program which then tends to have more bugs. > > > > Don't confuse writing code with design. Sounds to me like you aren't > > used to performing design separate from coding. > > > > > >> One of the reasons for looking at Go is it's lightning fast compiler > >> which makes it more similar to Forth than to C but still Forth is > >> wonderful for testing software as you go by it interactive nature and > >> it's culture of writing small procedures that are easily tested, that is > >> possible because the low overhead in calling small procedures. > >> > >> So they could be opposite but the both can work out well. > >> > >>> > >>> > >>>> The moral learned was pay now pay later, later bring interest payments > >>>> with it so it's far better to pay now. This indecision between Verilog > >>>> and VHDL seems a lot similar to my issues between C and Borland Pascal > >>>> so maybe that experience applies here too. > >>> > >>> I have made a lot of money by paying later. I bought two houses on > >>> mortgages and both are paid off now with values higher than the cost > >>> of the loans. By paying cash I would barely be buying the first one > >>> now, if that! > >> > >> Not applicable here. > > > > It was your analogy... ;) > > > > > >>>> When I first wanted to start this software project I dug out my old > >>>> copies of Borland Pascal but the problem is that they would not install > >>>> or run with Windows 10 so that reliable and efficient software was out > >>>> of the picture since a new copy is out of reach due to it's cost of > >>>> over > >>>> $1400 for the professional version, that is why I started looking at > >>>> Go, > >>>> efficient yet full of checks to keep you out of trouble. > >>> > >>> Oh, so you don't use Forth much then? Is that just a hobby thing with > >>> you? > >>> > >> > >> For a long time large applications were written in Delphi, smaller tools > >> were written in Forth, that worked out well as large applications needed > >> a lot of libraries not available in Forth. Small tools specially if they > >> interfaced to hardware were a lot easier to write and debug in Forth so > >> it was a tool to be used when the purpose suited it, when it does then > >> it's a wonderful language where one can write error free code like no > >> other. > >> > >> Actually Forth can be good for large applications but one needs > >> libraries to accomplish some complicated task, according to people here > >> it's to be avoided. > > > > What's to be avoided??? Using libraries or accomplishign complicated > > tasks? > > > > > >> For Delphi I wrote some B Tree Database routines > >> that were incredibly fast but it took a while to debug them and the code > >> was fairly large some here insist that it be written for each > >> application, that is insane so for large applications I had all sorts of > >> libraries in Delphi that were tested and made my life much easier. > >> > >>> I just don't end up adding bugs to my code so much. With Forth the > >>> small unit testing works very well. With VHDL I spend a lot of time > >>> thinking about how the code will work together, then simulation finds > >>> the bugs much more easily than running in the chip. > >>> > >>> I seriously think it was an epiphany for me when Jeff Fox wrote that > >>> stack errors just mean the programmer can't count. Avoiding stack > >>> errors is literally that simple, count the parameters added and > >>> removed from the stack. A compiler isn't needed to find those errors, > >>> just as, in my opinion, a compiler isn't needed to find uninitialized > >>> pointers. Heck, we had to perform requirements traceability analysis > >>> which was all done by hand. Why can't uninitialized pointers be found > >>> as you code? > >>> > >> > >> In C one can write a lot of code before anything is tested and somewhere > >> along the line a pointer might not have been initialized, it's easy to > >> miss sometimes. > > > > That is not at all related to the language. You can do stupid things in > > any language. > > > > > >> With Forth that is not much of an issue all routines are small so you > >> can see what you are doing. > > > > They are only small if you write them small. In VHDL I try to keep my > > modules small although that has a different meaning than in Forth. I > > want to try coding the bulk of my work in procedures sometime. I know > > people who do that, but I don't see how what they are doing is very > > useful. One in particular would separate the three sections of a > > sequential process. One was initialization but I can't think what the > > other two were. Anyway, he would code the three sections as procedures > > which sounds nice from a Forth perspective, but there is no way to test > > a procedure in VHDL without the supporting code. He thought it provided > > more organized code, but I didn't see the difference since the three > > sections are all very apparent when coded inline. They are all dealing > > with the same signals and variables, so I just didn't see the advantage > > in splitting them up. > > > > So while I think most aspects of design, coding and testing we have > > talked about are language agnostic, Forth does lend itself to smaller > > module sizes. > > > > One cannot write every detail of the software writing process in a email > or news post, if I did I would have a book, picking at little details > because it was not mentioned does not mean I'm not aware of them. > Remember that, it makes for a more pleasant conversation. > > I have mentioned it here before when I write software I even have a > notebook with all the software requirements, all the details of the > software methodology including flowcharts and UML charts, I use State > Diagrams when needed to document program/data triggers, and the source > is well documented so I do plan the software well, but we are humans and > we can make mistakes with the best of intentions. > > Some languages are more prone than others to allow mistakes to slip by, > C is well known for that. I always write my Forth applications bottom up > because Forth allows me to, I prefer writing software bottom up when > it's practical because it eliminates a lot of low level mistakes and > actually works quite well doing so. > > -- > Cecil - k5nwa One of the easiest ways to avoid making mistakes when writing software, is to not write any software --- this seems to be Rickman's strategy. It is an easy thing to write long-winded posts on comp.lang.forth explaining that somebody (Cecil in this case) is a bad programmer who makes a lot of mistakes --- it is much more difficult to write code without mistakes --- if Cecil has written software that works, then I'm impressed (even if it was in Pascal, which isn't really my cup of tea), because I know from experience that this is not easy in any language. Debugging has always been the difficult part of programming. Everybody has written code that seemed brilliant, but then found that it didn't work and they didn't know why --- in this case you have to debug it --- many would-be programmers give up and just stop programming, then they spend the rest of their lives on the internet pretending to be big experts on programming...
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-25 17:38 -0400 |
| Message-ID | <odoff8$9f7$1@dont-email.me> |
| In reply to | #58146 |
On 4/25/2017 5:12 PM, hughaguilar96@gmail.com wrote: > > One of the easiest ways to avoid making mistakes when writing > software, is to not write any software --- this seems to be Rickman's > strategy. I write software mostly when I get paid for it. Obviously you don't have that constraint or you wouldn't be writing any software. > It is an easy thing to write long-winded posts on comp.lang.forth > explaining that somebody (Cecil in this case) is a bad programmer who > makes a lot of mistakes --- it is much more difficult to write code > without mistakes --- if Cecil has written software that works, then > I'm impressed (even if it was in Pascal, which isn't really my cup of > tea), because I know from experience that this is not easy in any > language. It would seem it's even more difficult to find anyone willing to pay for software to be written... in any language. > Debugging has always been the difficult part of programming. > Everybody has written code that seemed brilliant, but then found that > it didn't work and they didn't know why --- in this case you have to > debug it --- many would-be programmers give up and just stop > programming, then they spend the rest of their lives on the internet > pretending to be big experts on programming... Really, people just *give up* writing software they can't figure out? Is that autobiographical? Oh, it wasn't software you couldn't figure out, it was finding a software job! -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-25 16:41 -0500 |
| Message-ID | <odofjp$9u9$1@dont-email.me> |
| In reply to | #58146 |
On 4/25/2017 4:12 PM, hughaguilar96@gmail.com wrote: > On Tuesday, April 25, 2017 at 1:57:18 PM UTC-7, Cecil - k5nwa wrote: >> On 4/25/2017 3:30 PM, rickman wrote: >>> On 4/25/2017 3:29 PM, Cecil Bayona wrote: >>>> On 4/25/2017 1:49 PM, rickman wrote: >>>>> On 4/25/2017 2:19 PM, Cecil Bayona wrote: >>>>>> >>>>>> An example in my life was writing complex software in C, it became a >>>>>> major problem in C finding bugs that crashed the system. I was going >>>>>> insane trying to find the bugs, there was a lot of pressure as the >>>>>> client was using the software and demanded stability. I bit the bullet >>>>>> and wrote a program to translate the C code into Borland Pascal, >>>>>> after a >>>>>> weekend of getting the translator to work right I had a working version >>>>>> of the software in Borland Pascal, I then turned on all the safety >>>>>> features in the Borland compiler on and re-compiled the code, within >>>>>> less than an hour the Borland run code started complaining about >>>>>> problems, mostly uninitialized pointers, after fixing them the customer >>>>>> mentioned that in over a week the system had not crashed or glitched >>>>>> once, this was a big life lesson. >>>>> >>>>> What was the underlying cause of these problems? It wasn't the C >>>>> compiler. >>>> >>>> Not the compiler but the language is like the Wild West anything goes so >>>> if one is not careful you can have mistakes that are difficult to find. >>>> Pascal and Go are languages that are restricted and check for dumb >>>> issues. >>> >>> The problem isn't the tool. I may not be the world's best expert in >>> anything, but one thing I have learned is that mistakes are made by >>> people and only people can prevent them. >>> >>> One of the most rigorous processes for avoiding mistakes is that used to >>> design and build nuclear reactors and yet nuclear reactors have problems >>> and even accidents. >>> >>> I'm not suggesting that we should build nuclear reactors without >>> processes to minimize mistakes. I'm saying that for software >>> development you can do a very decent job by using the sorts of methods >>> we use in programming in Forth which is to simplify the problems in ways >>> that make the mistakes easier to avoid. >>> >>> You said it yourself, "if one is not careful you can have mistakes"... >>> So program with intent and test early and often. >>> >>> I guess I have very seldom seen a compiler prevent me from making a >>> mistake that was, "difficult to find". Those mistakes require a human. ;) >>> >>> >>>>>> After that experience I stopped using C for projects, Borland Pascal's >>>>>> compile and run-time checks would catch all sorts of dumb mistakes that >>>>>> I would have missed using C. It didn't take long to get used to Pascals >>>>>> wordier way of writing code, and the requirement of explicit >>>>>> casting, in >>>>>> the end I could write code in my sleep in Borland Pascal and did not >>>>>> get >>>>>> nasty surprises, it was worth the effort. >>>>> >>>>> Did you consider the idea of not writing bad code in the first place? >>>>> That's where you are with Forth. It has very little in the way of >>>>> compiler checks. You have to avoid mistakes by not writing them. >>>>> >>>>> Personally I find it interesting that I use VHDL and Forth. I don't >>>>> think you can find two more opposite languages in terms of error >>>>> checking. >>>> >>>> Ah now you are getting to the root cause, writing bad code is too easy, >>>> and if you are in a hurry you can miss things that will burn you later. >>> >>> Huh? Not sure what I said about that. But don't be in a hurry. It has >>> been documented many, many times that spending time up front on analysis >>> and proper design methods will get you to a finished product faster than >>> rushing. The hurrier I go, the behinder I get. >>> >>> >>>> But like you I like Forth which has no checks for anything so what is >>>> the difference? >>> >>> The difference is a huge amount of work you spend in VHDL coding and the >>> huge amount of work you spend in Forth with low level testing. I would >>> prefer that testing were easier in VHDL. The issue is not so much the >>> effort required to design a test bench. For me it is the tools which >>> require you to set up a project and designate folders and all manner of >>> initialization to begin a simulation. The tool providers seem to be >>> very focused on the "BIG" picture and not the little ones, so the little >>> efforts are hard. >>> >>> >>>> C is usually written top down with a lot of code being written before >>>> one can test anything, this leads to more bugs, one is building on a >>>> foundation of untested code. >>> >>> Nonesense. Forth is often written top down with testing by using stubs. >>> Or C can be *designed* top down and written/tested bottom up. >>> >>> >>>> Forth also is like the Wild West but one writes code in a totally >>>> different way. One writes Forth mostly bottom up, writing small >>>> routines that are easily tested before using them elsewhere, the result >>>> is relatively error free code. C on the hand with its lengthy edit, >>>> compile, then test way of doing things encourages one to add a lot of >>>> untested code to a program which then tends to have more bugs. >>> >>> Don't confuse writing code with design. Sounds to me like you aren't >>> used to performing design separate from coding. >>> >>> >>>> One of the reasons for looking at Go is it's lightning fast compiler >>>> which makes it more similar to Forth than to C but still Forth is >>>> wonderful for testing software as you go by it interactive nature and >>>> it's culture of writing small procedures that are easily tested, that is >>>> possible because the low overhead in calling small procedures. >>>> >>>> So they could be opposite but the both can work out well. >>>> >>>>> >>>>> >>>>>> The moral learned was pay now pay later, later bring interest payments >>>>>> with it so it's far better to pay now. This indecision between Verilog >>>>>> and VHDL seems a lot similar to my issues between C and Borland Pascal >>>>>> so maybe that experience applies here too. >>>>> >>>>> I have made a lot of money by paying later. I bought two houses on >>>>> mortgages and both are paid off now with values higher than the cost >>>>> of the loans. By paying cash I would barely be buying the first one >>>>> now, if that! >>>> >>>> Not applicable here. >>> >>> It was your analogy... ;) >>> >>> >>>>>> When I first wanted to start this software project I dug out my old >>>>>> copies of Borland Pascal but the problem is that they would not install >>>>>> or run with Windows 10 so that reliable and efficient software was out >>>>>> of the picture since a new copy is out of reach due to it's cost of >>>>>> over >>>>>> $1400 for the professional version, that is why I started looking at >>>>>> Go, >>>>>> efficient yet full of checks to keep you out of trouble. >>>>> >>>>> Oh, so you don't use Forth much then? Is that just a hobby thing with >>>>> you? >>>>> >>>> >>>> For a long time large applications were written in Delphi, smaller tools >>>> were written in Forth, that worked out well as large applications needed >>>> a lot of libraries not available in Forth. Small tools specially if they >>>> interfaced to hardware were a lot easier to write and debug in Forth so >>>> it was a tool to be used when the purpose suited it, when it does then >>>> it's a wonderful language where one can write error free code like no >>>> other. >>>> >>>> Actually Forth can be good for large applications but one needs >>>> libraries to accomplish some complicated task, according to people here >>>> it's to be avoided. >>> >>> What's to be avoided??? Using libraries or accomplishign complicated >>> tasks? >>> >>> >>>> For Delphi I wrote some B Tree Database routines >>>> that were incredibly fast but it took a while to debug them and the code >>>> was fairly large some here insist that it be written for each >>>> application, that is insane so for large applications I had all sorts of >>>> libraries in Delphi that were tested and made my life much easier. >>>> >>>>> I just don't end up adding bugs to my code so much. With Forth the >>>>> small unit testing works very well. With VHDL I spend a lot of time >>>>> thinking about how the code will work together, then simulation finds >>>>> the bugs much more easily than running in the chip. >>>>> >>>>> I seriously think it was an epiphany for me when Jeff Fox wrote that >>>>> stack errors just mean the programmer can't count. Avoiding stack >>>>> errors is literally that simple, count the parameters added and >>>>> removed from the stack. A compiler isn't needed to find those errors, >>>>> just as, in my opinion, a compiler isn't needed to find uninitialized >>>>> pointers. Heck, we had to perform requirements traceability analysis >>>>> which was all done by hand. Why can't uninitialized pointers be found >>>>> as you code? >>>>> >>>> >>>> In C one can write a lot of code before anything is tested and somewhere >>>> along the line a pointer might not have been initialized, it's easy to >>>> miss sometimes. >>> >>> That is not at all related to the language. You can do stupid things in >>> any language. >>> >>> >>>> With Forth that is not much of an issue all routines are small so you >>>> can see what you are doing. >>> >>> They are only small if you write them small. In VHDL I try to keep my >>> modules small although that has a different meaning than in Forth. I >>> want to try coding the bulk of my work in procedures sometime. I know >>> people who do that, but I don't see how what they are doing is very >>> useful. One in particular would separate the three sections of a >>> sequential process. One was initialization but I can't think what the >>> other two were. Anyway, he would code the three sections as procedures >>> which sounds nice from a Forth perspective, but there is no way to test >>> a procedure in VHDL without the supporting code. He thought it provided >>> more organized code, but I didn't see the difference since the three >>> sections are all very apparent when coded inline. They are all dealing >>> with the same signals and variables, so I just didn't see the advantage >>> in splitting them up. >>> >>> So while I think most aspects of design, coding and testing we have >>> talked about are language agnostic, Forth does lend itself to smaller >>> module sizes. >>> >> >> One cannot write every detail of the software writing process in a email >> or news post, if I did I would have a book, picking at little details >> because it was not mentioned does not mean I'm not aware of them. >> Remember that, it makes for a more pleasant conversation. >> >> I have mentioned it here before when I write software I even have a >> notebook with all the software requirements, all the details of the >> software methodology including flowcharts and UML charts, I use State >> Diagrams when needed to document program/data triggers, and the source >> is well documented so I do plan the software well, but we are humans and >> we can make mistakes with the best of intentions. >> >> Some languages are more prone than others to allow mistakes to slip by, >> C is well known for that. I always write my Forth applications bottom up >> because Forth allows me to, I prefer writing software bottom up when >> it's practical because it eliminates a lot of low level mistakes and >> actually works quite well doing so. >> >> -- >> Cecil - k5nwa > > One of the easiest ways to avoid making mistakes when writing software, is to not write any software --- this seems to be Rickman's strategy. > > It is an easy thing to write long-winded posts on comp.lang.forth explaining that somebody (Cecil in this case) is a bad programmer who makes a lot of mistakes --- it is much more difficult to write code without mistakes --- if Cecil has written software that works, then I'm impressed (even if it was in Pascal, which isn't really my cup of tea), because I know from experience that this is not easy in any language. > > Debugging has always been the difficult part of programming. Everybody has written code that seemed brilliant, but then found that it didn't work and they didn't know why --- in this case you have to debug it --- many would-be programmers give up and just stop programming, then they spend the rest of their lives on the internet pretending to be big experts on programming... > I think you got the gist of it. I have written quite a few complex software applications even thought my job has never been to be a programmer except when I was a consultant for about three years. For a while my job was to be a hardware engineer but I help write a NC controllers software. As a consultant I wrote several large programs; A program to read time clocks and keep tract/edit peoples hours with over a thousand employees and 20+ time clocks, and generate a multitude of reports. A program to keep track of all students grades and schedules of classes, it would schedule classes on many criteria such as needed courses, prior requirements, proximity of the classrooms and it allowed Councillors to override the schedules yet if they asked the system to reschedule from scratch it kept the counselors recommendations as part of the scheduling. It kept track of a multitude of other things like parent/teacher meetings and such. An accounting system for a food vendor, they have very strict requirements that commercial accounting systems don't have. GL, AP, AR, Vending, Inventory, Ordering modules. This software was interesting in that their site was very prone to lightning so the computer often crashed while posting, I made it keeping track of all the steps needed to post using transaction tracking technology , so if the system crashed there was no need to clean up anything the system would continued right where it left off. I was very proud of that system, everyone else said that it was not possible to do what the owner wanted but I accomplished it with no problems. Every food item, salesman, location had a variety of variables, taxes depended on the city so there were hundreds of tax, and commission rates that had to be figured out so the owner could see his profits. A hazardous waste disposal simulator that actually thought it was the real thing and actually scheduled the chemicals at a weapons depot to make sure if there was an accident chemicals that interacted with one another were scheduled to not be present, it was very complex, and written in Prolog, it actually learned from how long things took to move around to improve the flow of the disposal. And numerous smaller programs to do things like talk to various NC machines to upload and download programs for them and many other programs. Multitudes of software tools to manage large networks mostly in Forth. Anyway I have written quite a bit of complex software all but one by myself. That doesn't count software I wrote for my own use, multitudes of compiler, translators, even an OS. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-25 15:11 -0700 |
| Message-ID | <7a913f5f-d881-4cb6-9f89-dff3bfcf5979@googlegroups.com> |
| In reply to | #58150 |
On Tuesday, April 25, 2017 at 2:41:13 PM UTC-7, Cecil - k5nwa wrote: > I have written quite a few complex software applications even thought my > job has never been to be a programmer except when I was a consultant for > about three years. Your resume is quite impressive! :-) > For a while my job was to be a hardware engineer but I help write a NC > controllers software. The MiniForth/RACE is used in CNC machines such as milling machines. Do you mean that you wrote the gcode for the CNC machines --- or that you wrote the firmware used internally within the CNC that interpreted the gcode? > Anyway I have written quite a bit of complex software all but one by > myself. I have often said that team programming is a bad idea. OTOH, some programs are too big for one programmer to write by himself in a reasonable amount of time. In this case, I would divide the program into sub-programs that are distinct, and assign one programmer to each sub-program. For example, you may have more than one processor running at the same time, so each processor's code is a sub-program. Also, when you have one processor and a multitasking OS, each task is a sub-program. The idea here is that each programmer has something that he is responsible for --- team programming is a bad idea when the programmers' responsibility isn't clearly demarcated --- then, when the project goes to heck, everybody involved begins pointing fingers at the other team members, and nobody takes responsibility.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-25 17:32 -0500 |
| Message-ID | <odoijl$l7j$1@dont-email.me> |
| In reply to | #58153 |
On 4/25/2017 5:11 PM, hughaguilar96@gmail.com wrote: > On Tuesday, April 25, 2017 at 2:41:13 PM UTC-7, Cecil - k5nwa wrote: >> I have written quite a few complex software applications even thought my >> job has never been to be a programmer except when I was a consultant for >> about three years. > > Your resume is quite impressive! :-) > >> For a while my job was to be a hardware engineer but I help write a NC >> controllers software. > > The MiniForth/RACE is used in CNC machines such as milling machines. > > Do you mean that you wrote the gcode for the CNC machines --- or that you wrote the firmware used internally within the CNC that interpreted the gcode? The firmware for the CNC controller but I was not the main writer, I wrote the diagnostics, the error compensation routines (machine learning from actual experience), and helped with the rest. We used a 12MHz 8085 board with a Floating Point co-processor. I designed along with other hardware the D/A board, the high speed counters, the CPU was interesting it allowed for shared memory and multiple processors if needed quite nice for the late 70's. > >> Anyway I have written quite a bit of complex software all but one by >> myself. > > I have often said that team programming is a bad idea. > > OTOH, some programs are too big for one programmer to write by himself in a reasonable amount of time. In this case, I would divide the program into sub-programs that are distinct, and assign one programmer to each sub-program. For example, you may have more than one processor running at the same time, so each processor's code is a sub-program. Also, when you have one processor and a multitasking OS, each task is a sub-program. The idea here is that each programmer has something that he is responsible for --- team programming is a bad idea when the programmers' responsibility isn't clearly demarcated --- then, when the project goes to heck, everybody involved begins pointing fingers at the other team members, and nobody takes responsibility. > That is why I was responsible for those two areas so the main programmer did not have to bother with them, but quite often I helped with the rest of the program, mostly the real time software. I also wrote all the external diagnostics for the production team, it was all controlled by a multi-tasking Monitor called CLM which stood for Cecil's Little Monitor, that part was fun. I also evaluated all the hardware CPUs, I wrote a Subroutine threaded Optimizing Compiler that could compile code for about 8 CPUs, that was a fun part of the job. Overall that company was a fun place to go to every morning. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-04-26 03:33 -0700 |
| Message-ID | <666799a9-e9b8-46fc-b06d-d0499ade69d9@googlegroups.com> |
| In reply to | #58141 |
On Tuesday, 25 April 2017 21:57:18 UTC+1, Cecil - k5nwa wrote: > On 4/25/2017 3:30 PM, rickman wrote: > > On 4/25/2017 3:29 PM, Cecil Bayona wrote: > >> On 4/25/2017 1:49 PM, rickman wrote: > >>> On 4/25/2017 2:19 PM, Cecil Bayona wrote: > >>>> > >>>> An example in my life was writing complex software in C, it became a > >>>> major problem in C finding bugs that crashed the system. I was going > >>>> insane trying to find the bugs, there was a lot of pressure as the > >>>> client was using the software and demanded stability. I bit the bullet > >>>> and wrote a program to translate the C code into Borland Pascal, > >>>> after a > >>>> weekend of getting the translator to work right I had a working version > >>>> of the software in Borland Pascal, I then turned on all the safety > >>>> features in the Borland compiler on and re-compiled the code, within > >>>> less than an hour the Borland run code started complaining about > >>>> problems, mostly uninitialized pointers, after fixing them the customer > >>>> mentioned that in over a week the system had not crashed or glitched > >>>> once, this was a big life lesson. > >>> > >>> What was the underlying cause of these problems? It wasn't the C > >>> compiler. > >> > >> Not the compiler but the language is like the Wild West anything goes so > >> if one is not careful you can have mistakes that are difficult to find. > >> Pascal and Go are languages that are restricted and check for dumb > >> issues. > > > > The problem isn't the tool. I may not be the world's best expert in > > anything, but one thing I have learned is that mistakes are made by > > people and only people can prevent them. > > > > One of the most rigorous processes for avoiding mistakes is that used to > > design and build nuclear reactors and yet nuclear reactors have problems > > and even accidents. > > > > I'm not suggesting that we should build nuclear reactors without > > processes to minimize mistakes. I'm saying that for software > > development you can do a very decent job by using the sorts of methods > > we use in programming in Forth which is to simplify the problems in ways > > that make the mistakes easier to avoid. > > > > You said it yourself, "if one is not careful you can have mistakes"... > > So program with intent and test early and often. > > > > I guess I have very seldom seen a compiler prevent me from making a > > mistake that was, "difficult to find". Those mistakes require a human. ;) > > > > > >>>> After that experience I stopped using C for projects, Borland Pascal's > >>>> compile and run-time checks would catch all sorts of dumb mistakes that > >>>> I would have missed using C. It didn't take long to get used to Pascals > >>>> wordier way of writing code, and the requirement of explicit > >>>> casting, in > >>>> the end I could write code in my sleep in Borland Pascal and did not > >>>> get > >>>> nasty surprises, it was worth the effort. > >>> > >>> Did you consider the idea of not writing bad code in the first place? > >>> That's where you are with Forth. It has very little in the way of > >>> compiler checks. You have to avoid mistakes by not writing them. > >>> > >>> Personally I find it interesting that I use VHDL and Forth. I don't > >>> think you can find two more opposite languages in terms of error > >>> checking. > >> > >> Ah now you are getting to the root cause, writing bad code is too easy, > >> and if you are in a hurry you can miss things that will burn you later. > > > > Huh? Not sure what I said about that. But don't be in a hurry. It has > > been documented many, many times that spending time up front on analysis > > and proper design methods will get you to a finished product faster than > > rushing. The hurrier I go, the behinder I get. > > > > > >> But like you I like Forth which has no checks for anything so what is > >> the difference? > > > > The difference is a huge amount of work you spend in VHDL coding and the > > huge amount of work you spend in Forth with low level testing. I would > > prefer that testing were easier in VHDL. The issue is not so much the > > effort required to design a test bench. For me it is the tools which > > require you to set up a project and designate folders and all manner of > > initialization to begin a simulation. The tool providers seem to be > > very focused on the "BIG" picture and not the little ones, so the little > > efforts are hard. > > > > > >> C is usually written top down with a lot of code being written before > >> one can test anything, this leads to more bugs, one is building on a > >> foundation of untested code. > > > > Nonesense. Forth is often written top down with testing by using stubs. > > Or C can be *designed* top down and written/tested bottom up. > > > > > >> Forth also is like the Wild West but one writes code in a totally > >> different way. One writes Forth mostly bottom up, writing small > >> routines that are easily tested before using them elsewhere, the result > >> is relatively error free code. C on the hand with its lengthy edit, > >> compile, then test way of doing things encourages one to add a lot of > >> untested code to a program which then tends to have more bugs. > > > > Don't confuse writing code with design. Sounds to me like you aren't > > used to performing design separate from coding. > > > > > >> One of the reasons for looking at Go is it's lightning fast compiler > >> which makes it more similar to Forth than to C but still Forth is > >> wonderful for testing software as you go by it interactive nature and > >> it's culture of writing small procedures that are easily tested, that is > >> possible because the low overhead in calling small procedures. > >> > >> So they could be opposite but the both can work out well. > >> > >>> > >>> > >>>> The moral learned was pay now pay later, later bring interest payments > >>>> with it so it's far better to pay now. This indecision between Verilog > >>>> and VHDL seems a lot similar to my issues between C and Borland Pascal > >>>> so maybe that experience applies here too. > >>> > >>> I have made a lot of money by paying later. I bought two houses on > >>> mortgages and both are paid off now with values higher than the cost > >>> of the loans. By paying cash I would barely be buying the first one > >>> now, if that! > >> > >> Not applicable here. > > > > It was your analogy... ;) > > > > > >>>> When I first wanted to start this software project I dug out my old > >>>> copies of Borland Pascal but the problem is that they would not install > >>>> or run with Windows 10 so that reliable and efficient software was out > >>>> of the picture since a new copy is out of reach due to it's cost of > >>>> over > >>>> $1400 for the professional version, that is why I started looking at > >>>> Go, > >>>> efficient yet full of checks to keep you out of trouble. > >>> > >>> Oh, so you don't use Forth much then? Is that just a hobby thing with > >>> you? > >>> > >> > >> For a long time large applications were written in Delphi, smaller tools > >> were written in Forth, that worked out well as large applications needed > >> a lot of libraries not available in Forth. Small tools specially if they > >> interfaced to hardware were a lot easier to write and debug in Forth so > >> it was a tool to be used when the purpose suited it, when it does then > >> it's a wonderful language where one can write error free code like no > >> other. > >> > >> Actually Forth can be good for large applications but one needs > >> libraries to accomplish some complicated task, according to people here > >> it's to be avoided. > > > > What's to be avoided??? Using libraries or accomplishign complicated > > tasks? > > > > > >> For Delphi I wrote some B Tree Database routines > >> that were incredibly fast but it took a while to debug them and the code > >> was fairly large some here insist that it be written for each > >> application, that is insane so for large applications I had all sorts of > >> libraries in Delphi that were tested and made my life much easier. > >> > >>> I just don't end up adding bugs to my code so much. With Forth the > >>> small unit testing works very well. With VHDL I spend a lot of time > >>> thinking about how the code will work together, then simulation finds > >>> the bugs much more easily than running in the chip. > >>> > >>> I seriously think it was an epiphany for me when Jeff Fox wrote that > >>> stack errors just mean the programmer can't count. Avoiding stack > >>> errors is literally that simple, count the parameters added and > >>> removed from the stack. A compiler isn't needed to find those errors, > >>> just as, in my opinion, a compiler isn't needed to find uninitialized > >>> pointers. Heck, we had to perform requirements traceability analysis > >>> which was all done by hand. Why can't uninitialized pointers be found > >>> as you code? > >>> > >> > >> In C one can write a lot of code before anything is tested and somewhere > >> along the line a pointer might not have been initialized, it's easy to > >> miss sometimes. > > > > That is not at all related to the language. You can do stupid things in > > any language. > > > > > >> With Forth that is not much of an issue all routines are small so you > >> can see what you are doing. > > > > They are only small if you write them small. In VHDL I try to keep my > > modules small although that has a different meaning than in Forth. I > > want to try coding the bulk of my work in procedures sometime. I know > > people who do that, but I don't see how what they are doing is very > > useful. One in particular would separate the three sections of a > > sequential process. One was initialization but I can't think what the > > other two were. Anyway, he would code the three sections as procedures > > which sounds nice from a Forth perspective, but there is no way to test > > a procedure in VHDL without the supporting code. He thought it provided > > more organized code, but I didn't see the difference since the three > > sections are all very apparent when coded inline. They are all dealing > > with the same signals and variables, so I just didn't see the advantage > > in splitting them up. > > > > So while I think most aspects of design, coding and testing we have > > talked about are language agnostic, Forth does lend itself to smaller > > module sizes. > > > > One cannot write every detail of the software writing process in a email > or news post, if I did I would have a book, picking at little details > because it was not mentioned does not mean I'm not aware of them. > Remember that, it makes for a more pleasant conversation. > > I have mentioned it here before when I write software I even have a > notebook with all the software requirements, all the details of the > software methodology including flowcharts and UML charts, I use State > Diagrams when needed to document program/data triggers, and the source > is well documented so I do plan the software well, but we are humans and > we can make mistakes with the best of intentions. > > Some languages are more prone than others to allow mistakes to slip by, > C is well known for that. I always write my Forth applications bottom up > because Forth allows me to, I prefer writing software bottom up when > it's practical because it eliminates a lot of low level mistakes and > actually works quite well doing so. > > -- > Cecil - k5nwa I'm in *exactly* the same position as you: Thinking "Hmm... Verilog or VHDL?" I'm going down the Verilog route. It seems a lot more readable. However, I don't have a clue about which tools to use. Do the FPGA vendor tools allow you to use either language, or if I want to use Verilog do I have to go with vendor x, and if I want VHDL then vendor y? Also, is it possible to make "real" chips (ASICs) out of Verilog code? A naïve question, but I think I read that it was not possible, though I can't see why.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-26 11:33 -0400 |
| Message-ID | <odqedu$sfb$1@dont-email.me> |
| In reply to | #58178 |
On 4/26/2017 6:33 AM, Mark Wills wrote: > On Tuesday, 25 April 2017 21:57:18 UTC+1, Cecil - k5nwa wrote: >> On 4/25/2017 3:30 PM, rickman wrote: >>> On 4/25/2017 3:29 PM, Cecil Bayona wrote: >>>> On 4/25/2017 1:49 PM, rickman wrote: >>>>> On 4/25/2017 2:19 PM, Cecil Bayona wrote: >>>>>> >>>>>> An example in my life was writing complex software in C, it became a >>>>>> major problem in C finding bugs that crashed the system. I was going >>>>>> insane trying to find the bugs, there was a lot of pressure as the >>>>>> client was using the software and demanded stability. I bit the bullet >>>>>> and wrote a program to translate the C code into Borland Pascal, >>>>>> after a >>>>>> weekend of getting the translator to work right I had a working version >>>>>> of the software in Borland Pascal, I then turned on all the safety >>>>>> features in the Borland compiler on and re-compiled the code, within >>>>>> less than an hour the Borland run code started complaining about >>>>>> problems, mostly uninitialized pointers, after fixing them the customer >>>>>> mentioned that in over a week the system had not crashed or glitched >>>>>> once, this was a big life lesson. >>>>> >>>>> What was the underlying cause of these problems? It wasn't the C >>>>> compiler. >>>> >>>> Not the compiler but the language is like the Wild West anything goes so >>>> if one is not careful you can have mistakes that are difficult to find. >>>> Pascal and Go are languages that are restricted and check for dumb >>>> issues. >>> >>> The problem isn't the tool. I may not be the world's best expert in >>> anything, but one thing I have learned is that mistakes are made by >>> people and only people can prevent them. >>> >>> One of the most rigorous processes for avoiding mistakes is that used to >>> design and build nuclear reactors and yet nuclear reactors have problems >>> and even accidents. >>> >>> I'm not suggesting that we should build nuclear reactors without >>> processes to minimize mistakes. I'm saying that for software >>> development you can do a very decent job by using the sorts of methods >>> we use in programming in Forth which is to simplify the problems in ways >>> that make the mistakes easier to avoid. >>> >>> You said it yourself, "if one is not careful you can have mistakes"... >>> So program with intent and test early and often. >>> >>> I guess I have very seldom seen a compiler prevent me from making a >>> mistake that was, "difficult to find". Those mistakes require a human. ;) >>> >>> >>>>>> After that experience I stopped using C for projects, Borland Pascal's >>>>>> compile and run-time checks would catch all sorts of dumb mistakes that >>>>>> I would have missed using C. It didn't take long to get used to Pascals >>>>>> wordier way of writing code, and the requirement of explicit >>>>>> casting, in >>>>>> the end I could write code in my sleep in Borland Pascal and did not >>>>>> get >>>>>> nasty surprises, it was worth the effort. >>>>> >>>>> Did you consider the idea of not writing bad code in the first place? >>>>> That's where you are with Forth. It has very little in the way of >>>>> compiler checks. You have to avoid mistakes by not writing them. >>>>> >>>>> Personally I find it interesting that I use VHDL and Forth. I don't >>>>> think you can find two more opposite languages in terms of error >>>>> checking. >>>> >>>> Ah now you are getting to the root cause, writing bad code is too easy, >>>> and if you are in a hurry you can miss things that will burn you later. >>> >>> Huh? Not sure what I said about that. But don't be in a hurry. It has >>> been documented many, many times that spending time up front on analysis >>> and proper design methods will get you to a finished product faster than >>> rushing. The hurrier I go, the behinder I get. >>> >>> >>>> But like you I like Forth which has no checks for anything so what is >>>> the difference? >>> >>> The difference is a huge amount of work you spend in VHDL coding and the >>> huge amount of work you spend in Forth with low level testing. I would >>> prefer that testing were easier in VHDL. The issue is not so much the >>> effort required to design a test bench. For me it is the tools which >>> require you to set up a project and designate folders and all manner of >>> initialization to begin a simulation. The tool providers seem to be >>> very focused on the "BIG" picture and not the little ones, so the little >>> efforts are hard. >>> >>> >>>> C is usually written top down with a lot of code being written before >>>> one can test anything, this leads to more bugs, one is building on a >>>> foundation of untested code. >>> >>> Nonesense. Forth is often written top down with testing by using stubs. >>> Or C can be *designed* top down and written/tested bottom up. >>> >>> >>>> Forth also is like the Wild West but one writes code in a totally >>>> different way. One writes Forth mostly bottom up, writing small >>>> routines that are easily tested before using them elsewhere, the result >>>> is relatively error free code. C on the hand with its lengthy edit, >>>> compile, then test way of doing things encourages one to add a lot of >>>> untested code to a program which then tends to have more bugs. >>> >>> Don't confuse writing code with design. Sounds to me like you aren't >>> used to performing design separate from coding. >>> >>> >>>> One of the reasons for looking at Go is it's lightning fast compiler >>>> which makes it more similar to Forth than to C but still Forth is >>>> wonderful for testing software as you go by it interactive nature and >>>> it's culture of writing small procedures that are easily tested, that is >>>> possible because the low overhead in calling small procedures. >>>> >>>> So they could be opposite but the both can work out well. >>>> >>>>> >>>>> >>>>>> The moral learned was pay now pay later, later bring interest payments >>>>>> with it so it's far better to pay now. This indecision between Verilog >>>>>> and VHDL seems a lot similar to my issues between C and Borland Pascal >>>>>> so maybe that experience applies here too. >>>>> >>>>> I have made a lot of money by paying later. I bought two houses on >>>>> mortgages and both are paid off now with values higher than the cost >>>>> of the loans. By paying cash I would barely be buying the first one >>>>> now, if that! >>>> >>>> Not applicable here. >>> >>> It was your analogy... ;) >>> >>> >>>>>> When I first wanted to start this software project I dug out my old >>>>>> copies of Borland Pascal but the problem is that they would not install >>>>>> or run with Windows 10 so that reliable and efficient software was out >>>>>> of the picture since a new copy is out of reach due to it's cost of >>>>>> over >>>>>> $1400 for the professional version, that is why I started looking at >>>>>> Go, >>>>>> efficient yet full of checks to keep you out of trouble. >>>>> >>>>> Oh, so you don't use Forth much then? Is that just a hobby thing with >>>>> you? >>>>> >>>> >>>> For a long time large applications were written in Delphi, smaller tools >>>> were written in Forth, that worked out well as large applications needed >>>> a lot of libraries not available in Forth. Small tools specially if they >>>> interfaced to hardware were a lot easier to write and debug in Forth so >>>> it was a tool to be used when the purpose suited it, when it does then >>>> it's a wonderful language where one can write error free code like no >>>> other. >>>> >>>> Actually Forth can be good for large applications but one needs >>>> libraries to accomplish some complicated task, according to people here >>>> it's to be avoided. >>> >>> What's to be avoided??? Using libraries or accomplishign complicated >>> tasks? >>> >>> >>>> For Delphi I wrote some B Tree Database routines >>>> that were incredibly fast but it took a while to debug them and the code >>>> was fairly large some here insist that it be written for each >>>> application, that is insane so for large applications I had all sorts of >>>> libraries in Delphi that were tested and made my life much easier. >>>> >>>>> I just don't end up adding bugs to my code so much. With Forth the >>>>> small unit testing works very well. With VHDL I spend a lot of time >>>>> thinking about how the code will work together, then simulation finds >>>>> the bugs much more easily than running in the chip. >>>>> >>>>> I seriously think it was an epiphany for me when Jeff Fox wrote that >>>>> stack errors just mean the programmer can't count. Avoiding stack >>>>> errors is literally that simple, count the parameters added and >>>>> removed from the stack. A compiler isn't needed to find those errors, >>>>> just as, in my opinion, a compiler isn't needed to find uninitialized >>>>> pointers. Heck, we had to perform requirements traceability analysis >>>>> which was all done by hand. Why can't uninitialized pointers be found >>>>> as you code? >>>>> >>>> >>>> In C one can write a lot of code before anything is tested and somewhere >>>> along the line a pointer might not have been initialized, it's easy to >>>> miss sometimes. >>> >>> That is not at all related to the language. You can do stupid things in >>> any language. >>> >>> >>>> With Forth that is not much of an issue all routines are small so you >>>> can see what you are doing. >>> >>> They are only small if you write them small. In VHDL I try to keep my >>> modules small although that has a different meaning than in Forth. I >>> want to try coding the bulk of my work in procedures sometime. I know >>> people who do that, but I don't see how what they are doing is very >>> useful. One in particular would separate the three sections of a >>> sequential process. One was initialization but I can't think what the >>> other two were. Anyway, he would code the three sections as procedures >>> which sounds nice from a Forth perspective, but there is no way to test >>> a procedure in VHDL without the supporting code. He thought it provided >>> more organized code, but I didn't see the difference since the three >>> sections are all very apparent when coded inline. They are all dealing >>> with the same signals and variables, so I just didn't see the advantage >>> in splitting them up. >>> >>> So while I think most aspects of design, coding and testing we have >>> talked about are language agnostic, Forth does lend itself to smaller >>> module sizes. >>> >> >> One cannot write every detail of the software writing process in a email >> or news post, if I did I would have a book, picking at little details >> because it was not mentioned does not mean I'm not aware of them. >> Remember that, it makes for a more pleasant conversation. >> >> I have mentioned it here before when I write software I even have a >> notebook with all the software requirements, all the details of the >> software methodology including flowcharts and UML charts, I use State >> Diagrams when needed to document program/data triggers, and the source >> is well documented so I do plan the software well, but we are humans and >> we can make mistakes with the best of intentions. >> >> Some languages are more prone than others to allow mistakes to slip by, >> C is well known for that. I always write my Forth applications bottom up >> because Forth allows me to, I prefer writing software bottom up when >> it's practical because it eliminates a lot of low level mistakes and >> actually works quite well doing so. >> >> -- >> Cecil - k5nwa > > I'm in *exactly* the same position as you: Thinking "Hmm... Verilog or > VHDL?" > > I'm going down the Verilog route. It seems a lot more readable. > > However, I don't have a clue about which tools to use. Do the FPGA > vendor tools allow you to use either language, or if I want to use > Verilog do I have to go with vendor x, and if I want VHDL then vendor y? > > Also, is it possible to make "real" chips (ASICs) out of Verilog code? > A naïve question, but I think I read that it was not possible, though > I can't see why. With exceedingly few exceptions both languages are supported by the vendors' tools. Most even support mixed modes with some modules in each language. I think the open source tools for the iCE40 line of FPGAs only support Verilog. I don't think I would choose a language based on how "readable" it seemed at first look. If you did that with other languages would you ever give Forth a second look? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-26 14:05 -0700 |
| Message-ID | <adcabd17-546a-45da-a0cf-fef836bdbc67@googlegroups.com> |
| In reply to | #58178 |
среда, 26 апреля 2017 г., 13:33:02 UTC+3 пользователь Mark Wills написал: > On Tuesday, 25 April 2017 21:57:18 UTC+1, Cecil - k5nwa wrote: > > On 4/25/2017 3:30 PM, rickman wrote: > > > On 4/25/2017 3:29 PM, Cecil Bayona wrote: > > >> On 4/25/2017 1:49 PM, rickman wrote: > > >>> On 4/25/2017 2:19 PM, Cecil Bayona wrote: > > >>>> > > >>>> An example in my life was writing complex software in C, it became a > > >>>> major problem in C finding bugs that crashed the system. I was going > > >>>> insane trying to find the bugs, there was a lot of pressure as the > > >>>> client was using the software and demanded stability. I bit the bullet > > >>>> and wrote a program to translate the C code into Borland Pascal, > > >>>> after a > > >>>> weekend of getting the translator to work right I had a working version > > >>>> of the software in Borland Pascal, I then turned on all the safety > > >>>> features in the Borland compiler on and re-compiled the code, within > > >>>> less than an hour the Borland run code started complaining about > > >>>> problems, mostly uninitialized pointers, after fixing them the customer > > >>>> mentioned that in over a week the system had not crashed or glitched > > >>>> once, this was a big life lesson. > > >>> > > >>> What was the underlying cause of these problems? It wasn't the C > > >>> compiler. > > >> > > >> Not the compiler but the language is like the Wild West anything goes so > > >> if one is not careful you can have mistakes that are difficult to find. > > >> Pascal and Go are languages that are restricted and check for dumb > > >> issues. > > > > > > The problem isn't the tool. I may not be the world's best expert in > > > anything, but one thing I have learned is that mistakes are made by > > > people and only people can prevent them. > > > > > > One of the most rigorous processes for avoiding mistakes is that used to > > > design and build nuclear reactors and yet nuclear reactors have problems > > > and even accidents. > > > > > > I'm not suggesting that we should build nuclear reactors without > > > processes to minimize mistakes. I'm saying that for software > > > development you can do a very decent job by using the sorts of methods > > > we use in programming in Forth which is to simplify the problems in ways > > > that make the mistakes easier to avoid. > > > > > > You said it yourself, "if one is not careful you can have mistakes"... > > > So program with intent and test early and often. > > > > > > I guess I have very seldom seen a compiler prevent me from making a > > > mistake that was, "difficult to find". Those mistakes require a human. ;) > > > > > > > > >>>> After that experience I stopped using C for projects, Borland Pascal's > > >>>> compile and run-time checks would catch all sorts of dumb mistakes that > > >>>> I would have missed using C. It didn't take long to get used to Pascals > > >>>> wordier way of writing code, and the requirement of explicit > > >>>> casting, in > > >>>> the end I could write code in my sleep in Borland Pascal and did not > > >>>> get > > >>>> nasty surprises, it was worth the effort. > > >>> > > >>> Did you consider the idea of not writing bad code in the first place? > > >>> That's where you are with Forth. It has very little in the way of > > >>> compiler checks. You have to avoid mistakes by not writing them. > > >>> > > >>> Personally I find it interesting that I use VHDL and Forth. I don't > > >>> think you can find two more opposite languages in terms of error > > >>> checking. > > >> > > >> Ah now you are getting to the root cause, writing bad code is too easy, > > >> and if you are in a hurry you can miss things that will burn you later. > > > > > > Huh? Not sure what I said about that. But don't be in a hurry. It has > > > been documented many, many times that spending time up front on analysis > > > and proper design methods will get you to a finished product faster than > > > rushing. The hurrier I go, the behinder I get. > > > > > > > > >> But like you I like Forth which has no checks for anything so what is > > >> the difference? > > > > > > The difference is a huge amount of work you spend in VHDL coding and the > > > huge amount of work you spend in Forth with low level testing. I would > > > prefer that testing were easier in VHDL. The issue is not so much the > > > effort required to design a test bench. For me it is the tools which > > > require you to set up a project and designate folders and all manner of > > > initialization to begin a simulation. The tool providers seem to be > > > very focused on the "BIG" picture and not the little ones, so the little > > > efforts are hard. > > > > > > > > >> C is usually written top down with a lot of code being written before > > >> one can test anything, this leads to more bugs, one is building on a > > >> foundation of untested code. > > > > > > Nonesense. Forth is often written top down with testing by using stubs. > > > Or C can be *designed* top down and written/tested bottom up. > > > > > > > > >> Forth also is like the Wild West but one writes code in a totally > > >> different way. One writes Forth mostly bottom up, writing small > > >> routines that are easily tested before using them elsewhere, the result > > >> is relatively error free code. C on the hand with its lengthy edit, > > >> compile, then test way of doing things encourages one to add a lot of > > >> untested code to a program which then tends to have more bugs. > > > > > > Don't confuse writing code with design. Sounds to me like you aren't > > > used to performing design separate from coding. > > > > > > > > >> One of the reasons for looking at Go is it's lightning fast compiler > > >> which makes it more similar to Forth than to C but still Forth is > > >> wonderful for testing software as you go by it interactive nature and > > >> it's culture of writing small procedures that are easily tested, that is > > >> possible because the low overhead in calling small procedures. > > >> > > >> So they could be opposite but the both can work out well. > > >> > > >>> > > >>> > > >>>> The moral learned was pay now pay later, later bring interest payments > > >>>> with it so it's far better to pay now. This indecision between Verilog > > >>>> and VHDL seems a lot similar to my issues between C and Borland Pascal > > >>>> so maybe that experience applies here too. > > >>> > > >>> I have made a lot of money by paying later. I bought two houses on > > >>> mortgages and both are paid off now with values higher than the cost > > >>> of the loans. By paying cash I would barely be buying the first one > > >>> now, if that! > > >> > > >> Not applicable here. > > > > > > It was your analogy... ;) > > > > > > > > >>>> When I first wanted to start this software project I dug out my old > > >>>> copies of Borland Pascal but the problem is that they would not install > > >>>> or run with Windows 10 so that reliable and efficient software was out > > >>>> of the picture since a new copy is out of reach due to it's cost of > > >>>> over > > >>>> $1400 for the professional version, that is why I started looking at > > >>>> Go, > > >>>> efficient yet full of checks to keep you out of trouble. > > >>> > > >>> Oh, so you don't use Forth much then? Is that just a hobby thing with > > >>> you? > > >>> > > >> > > >> For a long time large applications were written in Delphi, smaller tools > > >> were written in Forth, that worked out well as large applications needed > > >> a lot of libraries not available in Forth. Small tools specially if they > > >> interfaced to hardware were a lot easier to write and debug in Forth so > > >> it was a tool to be used when the purpose suited it, when it does then > > >> it's a wonderful language where one can write error free code like no > > >> other. > > >> > > >> Actually Forth can be good for large applications but one needs > > >> libraries to accomplish some complicated task, according to people here > > >> it's to be avoided. > > > > > > What's to be avoided??? Using libraries or accomplishign complicated > > > tasks? > > > > > > > > >> For Delphi I wrote some B Tree Database routines > > >> that were incredibly fast but it took a while to debug them and the code > > >> was fairly large some here insist that it be written for each > > >> application, that is insane so for large applications I had all sorts of > > >> libraries in Delphi that were tested and made my life much easier. > > >> > > >>> I just don't end up adding bugs to my code so much. With Forth the > > >>> small unit testing works very well. With VHDL I spend a lot of time > > >>> thinking about how the code will work together, then simulation finds > > >>> the bugs much more easily than running in the chip. > > >>> > > >>> I seriously think it was an epiphany for me when Jeff Fox wrote that > > >>> stack errors just mean the programmer can't count. Avoiding stack > > >>> errors is literally that simple, count the parameters added and > > >>> removed from the stack. A compiler isn't needed to find those errors, > > >>> just as, in my opinion, a compiler isn't needed to find uninitialized > > >>> pointers. Heck, we had to perform requirements traceability analysis > > >>> which was all done by hand. Why can't uninitialized pointers be found > > >>> as you code? > > >>> > > >> > > >> In C one can write a lot of code before anything is tested and somewhere > > >> along the line a pointer might not have been initialized, it's easy to > > >> miss sometimes. > > > > > > That is not at all related to the language. You can do stupid things in > > > any language. > > > > > > > > >> With Forth that is not much of an issue all routines are small so you > > >> can see what you are doing. > > > > > > They are only small if you write them small. In VHDL I try to keep my > > > modules small although that has a different meaning than in Forth. I > > > want to try coding the bulk of my work in procedures sometime. I know > > > people who do that, but I don't see how what they are doing is very > > > useful. One in particular would separate the three sections of a > > > sequential process. One was initialization but I can't think what the > > > other two were. Anyway, he would code the three sections as procedures > > > which sounds nice from a Forth perspective, but there is no way to test > > > a procedure in VHDL without the supporting code. He thought it provided > > > more organized code, but I didn't see the difference since the three > > > sections are all very apparent when coded inline. They are all dealing > > > with the same signals and variables, so I just didn't see the advantage > > > in splitting them up. > > > > > > So while I think most aspects of design, coding and testing we have > > > talked about are language agnostic, Forth does lend itself to smaller > > > module sizes. > > > > > > > One cannot write every detail of the software writing process in a email > > or news post, if I did I would have a book, picking at little details > > because it was not mentioned does not mean I'm not aware of them. > > Remember that, it makes for a more pleasant conversation. > > > > I have mentioned it here before when I write software I even have a > > notebook with all the software requirements, all the details of the > > software methodology including flowcharts and UML charts, I use State > > Diagrams when needed to document program/data triggers, and the source > > is well documented so I do plan the software well, but we are humans and > > we can make mistakes with the best of intentions. > > > > Some languages are more prone than others to allow mistakes to slip by, > > C is well known for that. I always write my Forth applications bottom up > > because Forth allows me to, I prefer writing software bottom up when > > it's practical because it eliminates a lot of low level mistakes and > > actually works quite well doing so. > > > > -- > > Cecil - k5nwa > > I'm in *exactly* the same position as you: Thinking "Hmm... Verilog or > VHDL?" > > I'm going down the Verilog route. It seems a lot more readable. > > However, I don't have a clue about which tools to use. Do the FPGA > vendor tools allow you to use either language, or if I want to use > Verilog do I have to go with vendor x, and if I want VHDL then vendor y? > > Also, is it possible to make "real" chips (ASICs) out of Verilog code? > A naïve question, but I think I read that it was not possible, though > I can't see why. Usually FPGA vendors support both VHDL and Verilog. It is proven for Xilinx and Altera. Lattice and Microsei (formerly Actel) has very small part of the world market and when I compare Lattice and Xilinx I see *2 price for Lattice chips with same logic size. Take a look on Xilinx Spartan-6 (lowest ost) or Artix-7, and Altera Cyclone X. ASICs has similar design flow and your Verilog/VHDL code can be used for silicon synthesis. However, many complex rules will be applied by factory. Mainly it relates to hardware blocks in FPGA, such as multipliers, transceivers etc. That blocks are paid by FPGA vendors, but not by you, so if you want to use good multiplier, you need to buy a separate license. The same thing may be applied to fast IO pins etc. ASIC is almost useless unless you have 100K pcs order. Demonstrating your CPU in FPGA is normal way now. With many competition and large number of cores we should focus on customer demands rather than thinking about cool commands. If you can provide an effective development flow for you CPU, it is better than rising clock speed by 5%.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-26 17:24 -0400 |
| Message-ID | <odr30q$644$1@dont-email.me> |
| In reply to | #58210 |
On 4/26/2017 5:05 PM, Ilya Tarasov wrote: > среда, 26 апреля 2017 г., 13:33:02 UTC+3 пользователь Mark Wills > написал: >> >> However, I don't have a clue about which tools to use. Do the FPGA >> vendor tools allow you to use either language, or if I want to use >> Verilog do I have to go with vendor x, and if I want VHDL then >> vendor y? >> >> Also, is it possible to make "real" chips (ASICs) out of Verilog >> code? A naïve question, but I think I read that it was not >> possible, though I can't see why. > > Usually FPGA vendors support both VHDL and Verilog. It is proven for > Xilinx and Altera. Lattice and Microsei (formerly Actel) has very > small part of the world market and when I compare Lattice and Xilinx > I see *2 price for Lattice chips with same logic size. Take a look on > Xilinx Spartan-6 (lowest ost) or Artix-7, and Altera Cyclone X. Unless you are building a small number of units, the advertised prices at vendors is pointless. If you are building a small number of units then the price is not so important. To get good pricing for >10,000 a year you need to contact the vendors directly and negotiate. They will toss out the book prices and cut to the bone for a design in. > ASIC is almost useless unless you have 100K pcs order. And exceedingly expensive unless you go with the hard IP solutions from the FPGA vendors where the NRE of chip design is done and they use masks to program your bitstream. I don't know if they even do this anymore. I believe Xilinx found they could get to the same prices by using your design details to pare down the test vectors which both reduces the test time and increases the yield, both important for a low price. It's not all about silicon area. > Demonstrating > your CPU in FPGA is normal way now. With many competition and large > number of cores we should focus on customer demands rather than > thinking about cool commands. If you can provide an effective > development flow for you CPU, it is better than rising clock speed by > 5%. I agree 100%. Rather than focusing on finding interesting tricks to improve some aspect of the CPU I think it is more useful to provide ways of optimizing the CPU for different design goals. In other words, flexibility. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-26 14:51 -0700 |
| Message-ID | <cfc4df19-c6ee-4801-af61-38d01dd103fe@googlegroups.com> |
| In reply to | #58211 |
четверг, 27 апреля 2017 г., 0:24:43 UTC+3 пользователь rickman написал: > On 4/26/2017 5:05 PM, Ilya Tarasov wrote: > > среда, 26 апреля 2017 г., 13:33:02 UTC+3 пользователь Mark Wills > > написал: > >> > >> However, I don't have a clue about which tools to use. Do the FPGA > >> vendor tools allow you to use either language, or if I want to use > >> Verilog do I have to go with vendor x, and if I want VHDL then > >> vendor y? > >> > >> Also, is it possible to make "real" chips (ASICs) out of Verilog > >> code? A naïve question, but I think I read that it was not > >> possible, though I can't see why. > > > > Usually FPGA vendors support both VHDL and Verilog. It is proven for > > Xilinx and Altera. Lattice and Microsei (formerly Actel) has very > > small part of the world market and when I compare Lattice and Xilinx > > I see *2 price for Lattice chips with same logic size. Take a look on > > Xilinx Spartan-6 (lowest ost) or Artix-7, and Altera Cyclone X. > > Unless you are building a small number of units, the advertised prices > at vendors is pointless. If you are building a small number of units > then the price is not so important. To get good pricing for >10,000 a > year you need to contact the vendors directly and negotiate. They will > toss out the book prices and cut to the bone for a design in. Very very interesting, if you bear in mind I work for Xilinx. What details you want to know about this process? :) Have you any ~10,000 pcs projects? > > ASIC is almost useless unless you have 100K pcs order. > > And exceedingly expensive unless you go with the hard IP solutions from > the FPGA vendors where the NRE of chip design is done and they use masks > to program your bitstream. I don't know if they even do this anymore. > I believe Xilinx found they could get to the same prices by using your > design details to pare down the test vectors which both reduces the test > time and increases the yield, both important for a low price. It's not > all about silicon area. Have you partners and certain names which can help you? I know exactly where to go with HDL code, how it must be prepared and what prices exist in silicon area. Please don't try to teach me, the fact you know something about HDL and FPGA don't mean you are an expert. > > Demonstrating > > your CPU in FPGA is normal way now. With many competition and large > > number of cores we should focus on customer demands rather than > > thinking about cool commands. If you can provide an effective > > development flow for you CPU, it is better than rising clock speed by > > 5%. > > I agree 100%. Rather than focusing on finding interesting tricks to > improve some aspect of the CPU I think it is more useful to provide ways > of optimizing the CPU for different design goals. In other words, > flexibility. Not just CPU, an entire system including CPU, hardware accelerators and other peripheral. Forth will never be faster than register file with many outputs and orthogonal addressing, but system will be effective with Forth with its dense code and other parts with high performance.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-26 18:29 -0400 |
| Message-ID | <odr6qr$kn9$1@dont-email.me> |
| In reply to | #58214 |
On 4/26/2017 5:51 PM, Ilya Tarasov wrote: > четверг, 27 апреля 2017 г., 0:24:43 UTC+3 пользователь rickman > написал: >> >> Unless you are building a small number of units, the advertised >> prices at vendors is pointless. If you are building a small number >> of units then the price is not so important. To get good pricing >> for >10,000 a year you need to contact the vendors directly and >> negotiate. They will toss out the book prices and cut to the bone >> for a design in. > > Very very interesting, if you bear in mind I work for Xilinx. What > details you want to know about this process? :) Have you any ~10,000 > pcs projects? You are an employee of Xilinx? Interesting. Some time ago there were a couple of employees of Xilinx who would post in comp.arch.fpga. They often would enter into exchanges that would be considered arguments if done in person. Eventually word got back to Xilinx and they were told to stop posting in newsgroups. I believe I saw Austin Leesa's name (one of the two) on a recent Xilinx forum post cited in a thread in comp.arch.fpga. So I guess he is still working for Xilinx unlike Peter Alfke who passed a few years back. I wonder if Xilinx knows you are representing them here? What exactly is your position with Xilinx? >> And exceedingly expensive unless you go with the hard IP solutions >> from the FPGA vendors where the NRE of chip design is done and they >> use masks to program your bitstream. I don't know if they even do >> this anymore. I believe Xilinx found they could get to the same >> prices by using your design details to pare down the test vectors >> which both reduces the test time and increases the yield, both >> important for a low price. It's not all about silicon area. > > Have you partners and certain names which can help you? I know > exactly where to go with HDL code, how it must be prepared and what > prices exist in silicon area. Please don't try to teach me, the fact > you know something about HDL and FPGA don't mean you are an expert. It's funny that you think everything is about you. I was expounding on the topic for the benefit of others. If you feel slighted that I assumed you didn't know something, I am sorry. Consider I was not addressing you specifically. >> I agree 100%. Rather than focusing on finding interesting tricks >> to improve some aspect of the CPU I think it is more useful to >> provide ways of optimizing the CPU for different design goals. In >> other words, flexibility. > > Not just CPU, an entire system including CPU, hardware accelerators > and other peripheral. Forth will never be faster than register file > with many outputs and orthogonal addressing, but system will be > effective with Forth with its dense code and other parts with high > performance. I'm not sure why you feel a stack processor can't be faster than a register based machine. I'm not sure that isn't true. So far, every example of register based machine I've seen, prepared in a similar way (process, technology, etc) has been slower than a stack machine. But then it's not often they can be compared on an equal footing. I believe the GA144 is made on a 180 nm process and runs at 700 MIPs. Even though those CPU MIPS are not the same as other processors or Dhrystone MIPS, the difference is large enough to make pretty clear that this CPU is faster than anything on a similar process. Of course it is not apples to oranges exactly because of the functional limitations of the F18A. I have never seen Dhrystone on a GA144. Another example is the J1 which was developed to overcome the shortfall of the MicroBlaze, a Xilinx processor. The J1 is smaller and runs faster enabling more functionality in the video application it was used in. The J1 is not a specialized processor in any way so it didn't gain its speed by special accelerators. It's just a simple stack processor that runs fast. Are your stack processor designs not faster than register based processor designs? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-26 16:18 -0700 |
| Message-ID | <8d52a88e-fb6e-4e33-9e90-dad85834e613@googlegroups.com> |
| In reply to | #58215 |
четверг, 27 апреля 2017 г., 1:29:47 UTC+3 пользователь rickman написал: > On 4/26/2017 5:51 PM, Ilya Tarasov wrote: > > четверг, 27 апреля 2017 г., 0:24:43 UTC+3 пользователь rickman > > написал: > >> > >> Unless you are building a small number of units, the advertised > >> prices at vendors is pointless. If you are building a small number > >> of units then the price is not so important. To get good pricing > >> for >10,000 a year you need to contact the vendors directly and > >> negotiate. They will toss out the book prices and cut to the bone > >> for a design in. > > > > Very very interesting, if you bear in mind I work for Xilinx. What > > details you want to know about this process? :) Have you any ~10,000 > > pcs projects? > > You are an employee of Xilinx? Interesting. Some time ago there were a > couple of employees of Xilinx who would post in comp.arch.fpga. They > often would enter into exchanges that would be considered arguments if > done in person. Eventually word got back to Xilinx and they were told > to stop posting in newsgroups. I believe I saw Austin Leesa's name (one > of the two) on a recent Xilinx forum post cited in a thread in > comp.arch.fpga. So I guess he is still working for Xilinx unlike Peter > Alfke who passed a few years back. > > I wonder if Xilinx knows you are representing them here? What exactly > is your position with Xilinx? Stop your fantasies please :))) I don't say I'm an Xilinx employee. There are many Xilinx partners in the world and many ways to work FOR Xilinx, but not IN Xilinx. So I'm free to post my opinion unless it is information under NDA. More interesting for Xilinx would be your attempt to stop Xilinx promotion in newsgroup. (And more interesting for other organizations in Russia your words about burning my house...) > > Have you partners and certain names which can help you? I know > > exactly where to go with HDL code, how it must be prepared and what > > prices exist in silicon area. Please don't try to teach me, the fact > > you know something about HDL and FPGA don't mean you are an expert. > > It's funny that you think everything is about you. I was expounding on > the topic for the benefit of others. If you feel slighted that I > assumed you didn't know something, I am sorry. Consider I was not > addressing you specifically. When you need to answer those who asking you, not to my posts. > >> I agree 100%. Rather than focusing on finding interesting tricks > >> to improve some aspect of the CPU I think it is more useful to > >> provide ways of optimizing the CPU for different design goals. In > >> other words, flexibility. > > > > Not just CPU, an entire system including CPU, hardware accelerators > > and other peripheral. Forth will never be faster than register file > > with many outputs and orthogonal addressing, but system will be > > effective with Forth with its dense code and other parts with high > > performance. > > I'm not sure why you feel a stack processor can't be faster than a > register based machine. I'm not sure that isn't true. So far, every > example of register based machine I've seen, prepared in a similar way > (process, technology, etc) has been slower than a stack machine. But > then it's not often they can be compared on an equal footing. If you not sure why do you state stack machine is faster? > Are your stack processor designs not faster than register based > processor designs? Faster by what? By clock speed, by operations per logic cell, by target algoritm iterations per second?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-26 21:07 -0400 |
| Message-ID | <odrg3f$cov$1@dont-email.me> |
| In reply to | #58216 |
On 4/26/2017 7:18 PM, Ilya Tarasov wrote: > четверг, 27 апреля 2017 г., 1:29:47 UTC+3 пользователь rickman написал: >> On 4/26/2017 5:51 PM, Ilya Tarasov wrote: >>> четверг, 27 апреля 2017 г., 0:24:43 UTC+3 пользователь rickman >>> написал: >>>> >>>> Unless you are building a small number of units, the advertised >>>> prices at vendors is pointless. If you are building a small number >>>> of units then the price is not so important. To get good pricing >>>> for >10,000 a year you need to contact the vendors directly and >>>> negotiate. They will toss out the book prices and cut to the bone >>>> for a design in. >>> >>> Very very interesting, if you bear in mind I work for Xilinx. What >>> details you want to know about this process? :) Have you any ~10,000 >>> pcs projects? >> >> You are an employee of Xilinx? Interesting. Some time ago there were a >> couple of employees of Xilinx who would post in comp.arch.fpga. They >> often would enter into exchanges that would be considered arguments if >> done in person. Eventually word got back to Xilinx and they were told >> to stop posting in newsgroups. I believe I saw Austin Leesa's name (one >> of the two) on a recent Xilinx forum post cited in a thread in >> comp.arch.fpga. So I guess he is still working for Xilinx unlike Peter >> Alfke who passed a few years back. >> >> I wonder if Xilinx knows you are representing them here? What exactly >> is your position with Xilinx? > > Stop your fantasies please :))) I don't say I'm an Xilinx employee. There are many Xilinx partners in the world and many ways to work FOR Xilinx, but not IN Xilinx. So I'm free to post my opinion unless it is information under NDA. More interesting for Xilinx would be your attempt to stop Xilinx promotion in newsgroup. (And more interesting for other organizations in Russia your words about burning my house...) > >>> Have you partners and certain names which can help you? I know >>> exactly where to go with HDL code, how it must be prepared and what >>> prices exist in silicon area. Please don't try to teach me, the fact >>> you know something about HDL and FPGA don't mean you are an expert. >> >> It's funny that you think everything is about you. I was expounding on >> the topic for the benefit of others. If you feel slighted that I >> assumed you didn't know something, I am sorry. Consider I was not >> addressing you specifically. > > When you need to answer those who asking you, not to my posts. > >>>> I agree 100%. Rather than focusing on finding interesting tricks >>>> to improve some aspect of the CPU I think it is more useful to >>>> provide ways of optimizing the CPU for different design goals. In >>>> other words, flexibility. >>> >>> Not just CPU, an entire system including CPU, hardware accelerators >>> and other peripheral. Forth will never be faster than register file >>> with many outputs and orthogonal addressing, but system will be >>> effective with Forth with its dense code and other parts with high >>> performance. >> >> I'm not sure why you feel a stack processor can't be faster than a >> register based machine. I'm not sure that isn't true. So far, every >> example of register based machine I've seen, prepared in a similar way >> (process, technology, etc) has been slower than a stack machine. But >> then it's not often they can be compared on an equal footing. > > If you not sure why do you state stack machine is faster? > >> Are your stack processor designs not faster than register based >> processor designs? > > Faster by what? By clock speed, by operations per logic cell, by target algoritm iterations per second? You snip parts of my post that answer the questions you ask and then you say things that are pointless. I'm tired of this game. Bye. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-27 01:52 -0700 |
| Message-ID | <62d728ff-a4d8-4146-80ee-611deadc0c01@googlegroups.com> |
| In reply to | #58219 |
четверг, 27 апреля 2017 г., 4:08:01 UTC+3 пользователь rickman написал: > On 4/26/2017 7:18 PM, Ilya Tarasov wrote: > > четверг, 27 апреля 2017 г., 1:29:47 UTC+3 пользователь rickman написал: > >> On 4/26/2017 5:51 PM, Ilya Tarasov wrote: > >>> четверг, 27 апреля 2017 г., 0:24:43 UTC+3 пользователь rickman > >>> написал: > >>>> > >>>> Unless you are building a small number of units, the advertised > >>>> prices at vendors is pointless. If you are building a small number > >>>> of units then the price is not so important. To get good pricing > >>>> for >10,000 a year you need to contact the vendors directly and > >>>> negotiate. They will toss out the book prices and cut to the bone > >>>> for a design in. > >>> > >>> Very very interesting, if you bear in mind I work for Xilinx. What > >>> details you want to know about this process? :) Have you any ~10,000 > >>> pcs projects? > >> > >> You are an employee of Xilinx? Interesting. Some time ago there were a > >> couple of employees of Xilinx who would post in comp.arch.fpga. They > >> often would enter into exchanges that would be considered arguments if > >> done in person. Eventually word got back to Xilinx and they were told > >> to stop posting in newsgroups. I believe I saw Austin Leesa's name (one > >> of the two) on a recent Xilinx forum post cited in a thread in > >> comp.arch.fpga. So I guess he is still working for Xilinx unlike Peter > >> Alfke who passed a few years back. > >> > >> I wonder if Xilinx knows you are representing them here? What exactly > >> is your position with Xilinx? > > > > Stop your fantasies please :))) I don't say I'm an Xilinx employee. There are many Xilinx partners in the world and many ways to work FOR Xilinx, but not IN Xilinx. So I'm free to post my opinion unless it is information under NDA. More interesting for Xilinx would be your attempt to stop Xilinx promotion in newsgroup. (And more interesting for other organizations in Russia your words about burning my house...) > > > >>> Have you partners and certain names which can help you? I know > >>> exactly where to go with HDL code, how it must be prepared and what > >>> prices exist in silicon area. Please don't try to teach me, the fact > >>> you know something about HDL and FPGA don't mean you are an expert. > >> > >> It's funny that you think everything is about you. I was expounding on > >> the topic for the benefit of others. If you feel slighted that I > >> assumed you didn't know something, I am sorry. Consider I was not > >> addressing you specifically. > > > > When you need to answer those who asking you, not to my posts. > > > >>>> I agree 100%. Rather than focusing on finding interesting tricks > >>>> to improve some aspect of the CPU I think it is more useful to > >>>> provide ways of optimizing the CPU for different design goals. In > >>>> other words, flexibility. > >>> > >>> Not just CPU, an entire system including CPU, hardware accelerators > >>> and other peripheral. Forth will never be faster than register file > >>> with many outputs and orthogonal addressing, but system will be > >>> effective with Forth with its dense code and other parts with high > >>> performance. > >> > >> I'm not sure why you feel a stack processor can't be faster than a > >> register based machine. I'm not sure that isn't true. So far, every > >> example of register based machine I've seen, prepared in a similar way > >> (process, technology, etc) has been slower than a stack machine. But > >> then it's not often they can be compared on an equal footing. > > > > If you not sure why do you state stack machine is faster? > > > >> Are your stack processor designs not faster than register based > >> processor designs? > > > > Faster by what? By clock speed, by operations per logic cell, by target algoritm iterations per second? > > You snip parts of my post that answer the questions you ask and then you > say things that are pointless. I'm tired of this game. Bye. If you think it is a language barrier problem, I think I need to inform somebody without thit problem about your words of 'burning my house' and 'web attack'. Have you appropriate official department near you? I see a little chances of performing a terrorist attack against me with burning my house (however, who knows), but since you looks like a programmer, you probably can perform a 'web attack' you wrote above. I must inform your action may be illegal. In this case, it is better to call somebody else, officially responsible for anti-terrorist and anti-hacker protection, to check all snipped and non-snipped parts of your messages, right?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-04-27 02:10 -0700 |
| Message-ID | <6086c2fd-162d-431f-95f5-f71f08c60da3@googlegroups.com> |
| In reply to | #58240 |
On Thursday, 27 April 2017 09:52:34 UTC+1, Ilya Tarasov wrote: > четверг, 27 апреля 2017 г., 4:08:01 UTC+3 пользователь rickman написал: > > On 4/26/2017 7:18 PM, Ilya Tarasov wrote: > > > четверг, 27 апреля 2017 г., 1:29:47 UTC+3 пользователь rickman написал: > > >> On 4/26/2017 5:51 PM, Ilya Tarasov wrote: > > >>> четверг, 27 апреля 2017 г., 0:24:43 UTC+3 пользователь rickman > > >>> написал: > > >>>> > > >>>> Unless you are building a small number of units, the advertised > > >>>> prices at vendors is pointless. If you are building a small number > > >>>> of units then the price is not so important. To get good pricing > > >>>> for >10,000 a year you need to contact the vendors directly and > > >>>> negotiate. They will toss out the book prices and cut to the bone > > >>>> for a design in. > > >>> > > >>> Very very interesting, if you bear in mind I work for Xilinx. What > > >>> details you want to know about this process? :) Have you any ~10,000 > > >>> pcs projects? > > >> > > >> You are an employee of Xilinx? Interesting. Some time ago there were a > > >> couple of employees of Xilinx who would post in comp.arch.fpga. They > > >> often would enter into exchanges that would be considered arguments if > > >> done in person. Eventually word got back to Xilinx and they were told > > >> to stop posting in newsgroups. I believe I saw Austin Leesa's name (one > > >> of the two) on a recent Xilinx forum post cited in a thread in > > >> comp.arch.fpga. So I guess he is still working for Xilinx unlike Peter > > >> Alfke who passed a few years back. > > >> > > >> I wonder if Xilinx knows you are representing them here? What exactly > > >> is your position with Xilinx? > > > > > > Stop your fantasies please :))) I don't say I'm an Xilinx employee. There are many Xilinx partners in the world and many ways to work FOR Xilinx, but not IN Xilinx. So I'm free to post my opinion unless it is information under NDA. More interesting for Xilinx would be your attempt to stop Xilinx promotion in newsgroup. (And more interesting for other organizations in Russia your words about burning my house...) > > > > > >>> Have you partners and certain names which can help you? I know > > >>> exactly where to go with HDL code, how it must be prepared and what > > >>> prices exist in silicon area. Please don't try to teach me, the fact > > >>> you know something about HDL and FPGA don't mean you are an expert. > > >> > > >> It's funny that you think everything is about you. I was expounding on > > >> the topic for the benefit of others. If you feel slighted that I > > >> assumed you didn't know something, I am sorry. Consider I was not > > >> addressing you specifically. > > > > > > When you need to answer those who asking you, not to my posts. > > > > > >>>> I agree 100%. Rather than focusing on finding interesting tricks > > >>>> to improve some aspect of the CPU I think it is more useful to > > >>>> provide ways of optimizing the CPU for different design goals. In > > >>>> other words, flexibility. > > >>> > > >>> Not just CPU, an entire system including CPU, hardware accelerators > > >>> and other peripheral. Forth will never be faster than register file > > >>> with many outputs and orthogonal addressing, but system will be > > >>> effective with Forth with its dense code and other parts with high > > >>> performance. > > >> > > >> I'm not sure why you feel a stack processor can't be faster than a > > >> register based machine. I'm not sure that isn't true. So far, every > > >> example of register based machine I've seen, prepared in a similar way > > >> (process, technology, etc) has been slower than a stack machine. But > > >> then it's not often they can be compared on an equal footing. > > > > > > If you not sure why do you state stack machine is faster? > > > > > >> Are your stack processor designs not faster than register based > > >> processor designs? > > > > > > Faster by what? By clock speed, by operations per logic cell, by target algoritm iterations per second? > > > > You snip parts of my post that answer the questions you ask and then you > > say things that are pointless. I'm tired of this game. Bye. > > If you think it is a language barrier problem, I think I need to inform somebody without thit problem about your words of 'burning my house' and 'web attack'. Have you appropriate official department near you? I see a little chances of performing a terrorist attack against me with burning my house (however, who knows), but since you looks like a programmer, you probably can perform a 'web attack' you wrote above. I must inform your action may be illegal. In this case, it is better to call somebody else, officially responsible for anti-terrorist and anti-hacker protection, to check all snipped and non-snipped parts of your messages, right? Guy, calm down. Rick's comment about burning down your house was: a) Entirely tongue in cheek - not meant to be taken literally; b) Not aimed at anyone in particular If I said "Don't use local variables in Forth, or else I'll hunt you down and shoot you while you sleep" it does NOT mean I am literally going to do that. It means I am very strongly opposed to local variables. Jeez. For the record: I'm in favour of local variables.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-27 02:22 -0700 |
| Message-ID | <f98117b3-f137-4569-acd3-072b6afca3c1@googlegroups.com> |
| In reply to | #58241 |
четверг, 27 апреля 2017 г., 12:10:26 UTC+3 пользователь Mark Wills написал: > On Thursday, 27 April 2017 09:52:34 UTC+1, Ilya Tarasov wrote: > > четверг, 27 апреля 2017 г., 4:08:01 UTC+3 пользователь rickman написал: > > > On 4/26/2017 7:18 PM, Ilya Tarasov wrote: > > > > четверг, 27 апреля 2017 г., 1:29:47 UTC+3 пользователь rickman написал: > > > >> On 4/26/2017 5:51 PM, Ilya Tarasov wrote: > > > >>> четверг, 27 апреля 2017 г., 0:24:43 UTC+3 пользователь rickman > > > >>> написал: > > > >>>> > > > >>>> Unless you are building a small number of units, the advertised > > > >>>> prices at vendors is pointless. If you are building a small number > > > >>>> of units then the price is not so important. To get good pricing > > > >>>> for >10,000 a year you need to contact the vendors directly and > > > >>>> negotiate. They will toss out the book prices and cut to the bone > > > >>>> for a design in. > > > >>> > > > >>> Very very interesting, if you bear in mind I work for Xilinx. What > > > >>> details you want to know about this process? :) Have you any ~10,000 > > > >>> pcs projects? > > > >> > > > >> You are an employee of Xilinx? Interesting. Some time ago there were a > > > >> couple of employees of Xilinx who would post in comp.arch.fpga. They > > > >> often would enter into exchanges that would be considered arguments if > > > >> done in person. Eventually word got back to Xilinx and they were told > > > >> to stop posting in newsgroups. I believe I saw Austin Leesa's name (one > > > >> of the two) on a recent Xilinx forum post cited in a thread in > > > >> comp.arch.fpga. So I guess he is still working for Xilinx unlike Peter > > > >> Alfke who passed a few years back. > > > >> > > > >> I wonder if Xilinx knows you are representing them here? What exactly > > > >> is your position with Xilinx? > > > > > > > > Stop your fantasies please :))) I don't say I'm an Xilinx employee. There are many Xilinx partners in the world and many ways to work FOR Xilinx, but not IN Xilinx. So I'm free to post my opinion unless it is information under NDA. More interesting for Xilinx would be your attempt to stop Xilinx promotion in newsgroup. (And more interesting for other organizations in Russia your words about burning my house...) > > > > > > > >>> Have you partners and certain names which can help you? I know > > > >>> exactly where to go with HDL code, how it must be prepared and what > > > >>> prices exist in silicon area. Please don't try to teach me, the fact > > > >>> you know something about HDL and FPGA don't mean you are an expert. > > > >> > > > >> It's funny that you think everything is about you. I was expounding on > > > >> the topic for the benefit of others. If you feel slighted that I > > > >> assumed you didn't know something, I am sorry. Consider I was not > > > >> addressing you specifically. > > > > > > > > When you need to answer those who asking you, not to my posts. > > > > > > > >>>> I agree 100%. Rather than focusing on finding interesting tricks > > > >>>> to improve some aspect of the CPU I think it is more useful to > > > >>>> provide ways of optimizing the CPU for different design goals. In > > > >>>> other words, flexibility. > > > >>> > > > >>> Not just CPU, an entire system including CPU, hardware accelerators > > > >>> and other peripheral. Forth will never be faster than register file > > > >>> with many outputs and orthogonal addressing, but system will be > > > >>> effective with Forth with its dense code and other parts with high > > > >>> performance. > > > >> > > > >> I'm not sure why you feel a stack processor can't be faster than a > > > >> register based machine. I'm not sure that isn't true. So far, every > > > >> example of register based machine I've seen, prepared in a similar way > > > >> (process, technology, etc) has been slower than a stack machine. But > > > >> then it's not often they can be compared on an equal footing. > > > > > > > > If you not sure why do you state stack machine is faster? > > > > > > > >> Are your stack processor designs not faster than register based > > > >> processor designs? > > > > > > > > Faster by what? By clock speed, by operations per logic cell, by target algoritm iterations per second? > > > > > > You snip parts of my post that answer the questions you ask and then you > > > say things that are pointless. I'm tired of this game. Bye. > > > > If you think it is a language barrier problem, I think I need to inform somebody without thit problem about your words of 'burning my house' and 'web attack'. Have you appropriate official department near you? I see a little chances of performing a terrorist attack against me with burning my house (however, who knows), but since you looks like a programmer, you probably can perform a 'web attack' you wrote above. I must inform your action may be illegal. In this case, it is better to call somebody else, officially responsible for anti-terrorist and anti-hacker protection, to check all snipped and non-snipped parts of your messages, right? > > Guy, calm down. Rick's comment about burning down your house was: > > a) Entirely tongue in cheek - not meant to be taken literally; > b) Not aimed at anyone in particular > > If I said "Don't use local variables in Forth, or else I'll hunt you down > and shoot you while you sleep" it does NOT mean I am literally going to do > that. It means I am very strongly opposed to local variables. > > Jeez. > > For the record: I'm in favour of local variables. Are you sure I think is was literally? :))) But he must check his words very very carefully. His words to write to Xilinx were aimed to... whom? If he want to play this kind of game, I don't plan to do the same. And I'm ready to pass him to an appropriate departments to decide is it literally or not. It is his choice.
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web