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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-26 21:14 -0700 |
| Message-ID | <c0c4268a-63f9-4dba-8fe0-0db5ffd5edb8@googlegroups.com> |
| In reply to | #58214 |
On Wednesday, April 26, 2017 at 2:51:09 PM UTC-7, Ilya Tarasov wrote: > 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. In my experience, Ilya is incorrect about this. In 1994 the competition in the laser-etching field used an MC68000 board --- the 68K has a big register file (8 data registers and 8 address registers) and orthogonal addressing modes. Testra's Dallas 80c320 board was not fast enough to compete effectively. This is when Testra built the MiniForth on a Lattice isp1048 PLD --- the result was significantly less expensive than the competitor's board, and significantly faster --- the competitor ended up abandoning the field. That was also almost a quarter of a century ago. Ilya may be right about the modern world --- the ARM processors are about two orders of magnitude faster than the old MC68000 (also, faster than the ColdFire, which is the modern descendant of the 68K) --- the MiniForth is now the RACE and is built on an FPGA, and is over an order of magnitude faster than the MiniForth. So, Ilya may be right that a stack-machine is no longer competitive in speed with a register-file machine. What do people even need this kind of speed for??? In 1995 the MiniForth was making the laser-etcher move very quickly, and it maintained the same speed whether the lines were straight or had a lot of changes of direction, and it did all of this with minimal vibration (there was no harmonic resonance; vibration did not increase as time progressed). What would be the point of having a processor that runs 100 times faster? There is a limit to how fast mechanical contraptions using gears and belts can move --- also, there is a limit to how much the laser can be cranked up (the laser-etcher uses a small CO2 laser; afaik it was already turned up to its maximum heat). If the customers were happy in 1995, when did they become unhappy? Did their requirements change? Before we become too fascinated with speed, perhaps Ilya can enlighten us on what speed is needed for.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-04-27 02:17 -0700 |
| Message-ID | <4921a8c7-eaee-4977-8e84-4d509fb2ea59@googlegroups.com> |
| In reply to | #58225 |
четверг, 27 апреля 2017 г., 7:14:40 UTC+3 пользователь hughag...@gmail.com написал: > On Wednesday, April 26, 2017 at 2:51:09 PM UTC-7, Ilya Tarasov wrote: > > 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. > > In my experience, Ilya is incorrect about this. > In 1994 the competition in the laser-etching field used an MC68000 board --- the 68K has a big register file (8 data registers and 8 address registers) and orthogonal addressing modes. Testra's Dallas 80c320 board was not fast enough to compete effectively. This is when Testra built the MiniForth on a Lattice isp1048 PLD --- the result was significantly less expensive than the competitor's board, and significantly faster --- the competitor ended up abandoning the field. > > That was also almost a quarter of a century ago. Ilya may be right about the modern world --- the ARM processors are about two orders of magnitude faster than the old MC68000 (also, faster than the ColdFire, which is the modern descendant of the 68K) --- the MiniForth is now the RACE and is built on an FPGA, and is over an order of magnitude faster than the MiniForth. > > So, Ilya may be right that a stack-machine is no longer competitive in speed with a register-file machine. > > What do people even need this kind of speed for??? In 1995 the MiniForth was making the laser-etcher move very quickly, and it maintained the same speed whether the lines were straight or had a lot of changes of direction, and it did all of this with minimal vibration (there was no harmonic resonance; vibration did not increase as time progressed). What would be the point of having a processor that runs 100 times faster? There is a limit to how fast mechanical contraptions using gears and belts can move --- also, there is a limit to how much the laser can be cranked up (the laser-etcher uses a small CO2 laser; afaik it was already turned up to its maximum heat). > > If the customers were happy in 1995, when did they become unhappy? Did their requirements change? > > Before we become too fascinated with speed, perhaps Ilya can enlighten us on what speed is needed for. Please note I ask several question. This is not occasionally. :) Before, answering to Juergen Pintaske, I also ask hin several questions regarding 25$ price. It was because I can provide a Forth CPU for an FPGA below 10$ (so answer is yes), but I'm not ready to sell a full product, including core, documentation and support, for 25$. Forth CPU has similar situation, more complex than just yes or no answers. First of all, from the microarchitecture view, zero-operand CPU has a fundamental advantage of shorter pipeline. When 1-2-3 operand command need to read operands from the register file, Forth CPU may read top of stack regardless of next command, so basic 3-cycle pipeline (fetch-decode-execute) may be converted to 2-cycle (fetch-execute). There are many alerts here, because we still can get critical path on complex ALU, but having simple stack model we can read operands in parallel with next command fetching. From my experience, I have stack CPU running at the clock speed comparable to Xilinx Microblaze, but without any layout optimization! So Forth CPU can achieve good clock speed. Another good thing is known computational model. Having hardware-implemented words, we don't need to optimize Forth->assembler translation, because many words in the source text can be converted to machine codes directly. Possible bad thing is some algorithms requires many values to be available at the same time. For example, if we have several addresses and several data to store in sequence (to create a waveform) we may write this: 1 ADDR1 OUTPORT 0 ADDR1 OUTPORT 1 ADDR2 OUTPORT 0 ADDR2 OUTPORT etc. There are many literals like 0, 1, ADDR1, ADDR2 and all these are consumed by OUTPORT command (it is like !, but for ports). So we need to load literal on the stack again. With a register file, we can load ADDR1, ADDR2 to registers before entering a long cycle of waveform generating. In this case, values in registers will not be lost and we don't need to load it every time. Having, say, 32 registers, some algorithms may get benefit from optimizing register scheduling and use value tracking approach to avoid many loads of value already loaded into register. A 'bottleneck' of stack may prevent this, because numbers usually drops from the top of stack by all words. This is not a problem if Forth CPU is used properly, having system vision of entire design. At last, I use Forth CPU for almost every design, isn't it an answer on what I think about Forth benefits? :)
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-04-27 05:05 -0700 |
| Message-ID | <261007ce-7c3d-436b-b393-d78048f1fd29@googlegroups.com> |
| In reply to | #58244 |
On Thursday, 27 April 2017 10:17:32 UTC+1, Ilya Tarasov wrote:
> четверг, 27 апреля 2017 г., 7:14:40 UTC+3 пользователь hughag...@gmail.com написал:
> > On Wednesday, April 26, 2017 at 2:51:09 PM UTC-7, Ilya Tarasov wrote:
> > > 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.
> >
> > In my experience, Ilya is incorrect about this.
>
> > In 1994 the competition in the laser-etching field used an MC68000 board --- the 68K has a big register file (8 data registers and 8 address registers) and orthogonal addressing modes. Testra's Dallas 80c320 board was not fast enough to compete effectively. This is when Testra built the MiniForth on a Lattice isp1048 PLD --- the result was significantly less expensive than the competitor's board, and significantly faster --- the competitor ended up abandoning the field.
> >
> > That was also almost a quarter of a century ago. Ilya may be right about the modern world --- the ARM processors are about two orders of magnitude faster than the old MC68000 (also, faster than the ColdFire, which is the modern descendant of the 68K) --- the MiniForth is now the RACE and is built on an FPGA, and is over an order of magnitude faster than the MiniForth.
> >
> > So, Ilya may be right that a stack-machine is no longer competitive in speed with a register-file machine.
> >
> > What do people even need this kind of speed for??? In 1995 the MiniForth was making the laser-etcher move very quickly, and it maintained the same speed whether the lines were straight or had a lot of changes of direction, and it did all of this with minimal vibration (there was no harmonic resonance; vibration did not increase as time progressed). What would be the point of having a processor that runs 100 times faster? There is a limit to how fast mechanical contraptions using gears and belts can move --- also, there is a limit to how much the laser can be cranked up (the laser-etcher uses a small CO2 laser; afaik it was already turned up to its maximum heat).
> >
> > If the customers were happy in 1995, when did they become unhappy? Did their requirements change?
> >
> > Before we become too fascinated with speed, perhaps Ilya can enlighten us on what speed is needed for.
>
> Please note I ask several question. This is not occasionally. :)
>
> Before, answering to Juergen Pintaske, I also ask hin several questions regarding 25$ price. It was because I can provide a Forth CPU for an FPGA below 10$ (so answer is yes), but I'm not ready to sell a full product, including core, documentation and support, for 25$.
>
> Forth CPU has similar situation, more complex than just yes or no answers.
>
> First of all, from the microarchitecture view, zero-operand CPU has a fundamental advantage of shorter pipeline. When 1-2-3 operand command need to read operands from the register file, Forth CPU may read top of stack regardless of next command, so basic 3-cycle pipeline (fetch-decode-execute) may be converted to 2-cycle (fetch-execute). There are many alerts here, because we still can get critical path on complex ALU, but having simple stack model we can read operands in parallel with next command fetching.
>
> From my experience, I have stack CPU running at the clock speed comparable to Xilinx Microblaze, but without any layout optimization! So Forth CPU can achieve good clock speed.
>
> Another good thing is known computational model. Having hardware-implemented words, we don't need to optimize Forth->assembler translation, because many words in the source text can be converted to machine codes directly.
>
> Possible bad thing is some algorithms requires many values to be available at the same time. For example, if we have several addresses and several data to store in sequence (to create a waveform) we may write this:
>
> 1 ADDR1 OUTPORT
> 0 ADDR1 OUTPORT
> 1 ADDR2 OUTPORT
> 0 ADDR2 OUTPORT
> etc. There are many literals like 0, 1, ADDR1, ADDR2 and all these are consumed by OUTPORT command (it is like !, but for ports). So we need to load literal on the stack again.
>
> With a register file, we can load ADDR1, ADDR2 to registers before entering a long cycle of waveform generating. In this case, values in registers will not be lost and we don't need to load it every time.
>
> Having, say, 32 registers, some algorithms may get benefit from optimizing register scheduling and use value tracking approach to avoid many loads of value already loaded into register. A 'bottleneck' of stack may prevent this, because numbers usually drops from the top of stack by all words.
>
> This is not a problem if Forth CPU is used properly, having system vision of entire design. At last, I use Forth CPU for almost every design, isn't it an answer on what I think about Forth benefits? :)
This is interesting. To me (un-educated idiot!) it appears that a register
based machine should be faster than a stack machine, possibly by a considerable
margin.
Let's take an every-day example.
We have 100 filters in various pipelines on an gas plant. They filter out
sand and silt from the gas coming up from the wells (the water, oil, and
condensate has already been removed in an earlier part of the process).
These filters have a physical screen in them to block the large sand
particles, so eventually they clog up, reducing flow. If the flow reduces too
much you will induce a vacuum in the lines (there are pumps upstream), and
crush them, wrecking millions of dollars of equipment, and requiring millions
to repair it, plus costing millions in downtime - possibly leading to a bill
counted in the billions.
Consequently, we need to compute the differential pressure across the filter,
so that when the differential exceeds a certain pressure, we can raise and
alarm to the maintenance department before it becomes a problem.
We'll do this by having a pressure indicator on each side of the
filter assemblies, PI1 and PI2. (read in mono font):
PI1 PI2
-->-flow->--|-FILTER-|-->---
We need compute the differential pressure across the filter by subtracting
pi2 from pi1. If the differential is too high we can raise an alarm.
We'll just concern ourselves with processing the table of pressures and
computing and storing the differential.
1) An array of memory addresses contains the PI1 values.
2) Another array of memory addresses contains the PI2 values.
3) We'll compute the difference and store that in a third array.
Assembly language:
LOAD R0,PI1TAB ; PI1 of first filter
LOAD R1,PI2TAB ; PI2 of first filter
LOAD R2,DIFFTAB ; address of differential table
LOAD R3,100 ; number of filters to process
LOOP: ; start of loop
SUB (R1)+,(R0) ; subtract PI2 from PI1 (indirect addressing)
MOV (R0)+,(R2)+ ; store in differential table and advance address [1]
DEC R3 ; finished?
JNE LOOP ; loop back if not
[1] indirect addressing with post increment on both operands
Forth:
create PI1TAB 100 cells allot \ PI1 table array
create PI2TAB 100 cells allot \ PI2 table array
create DIFFTAB 100 cells allot \ differential table array
: computeDifferentials ( -- )
0 >r \ array index
100 begin \ 100 pairs to process
PI1TAB r@ + @ \ fetch PI1 from P1 array
PI2TAB r@ + @ \ fetch PI2 from P2 array
- \ subtract them
DIFTAB r@ + ! \ store in DIFTAB array
r> 1 cells + >r \ advance array index
1- dup 0= until \ loop if not finished
drop \ drop count
r> drop \ drop array index
;
Which is more efficient? Which is faster?
I'd argue that the "regular" CPU code is (probably) faster, because
the Forth code is spending quite a lot of time thrashing the return
stack. If we're thrashing the return stack *then we're not getting
our work done*.
I'd say the above is quite idiomatic Forth, but I'm always happy to be
schooled. I like Forth very much, but I don't profess to be particularly
good at writing awesome/cool/neat/lean/clean/efficient Forth.
Of course, a Forth *cpu* probably would not have begin/until instructions.
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-04-27 13:35 +0100 |
| Message-ID | <MPG.336bf5daecc629d8989710@news.virginmedia.com> |
| In reply to | #58256 |
In article <261007ce-7c3d-436b-b393-d78048f1fd29@googlegroups.com>, markwills1970@gmail.com says... > > On > > This is interesting. To me (un-educated idiot!) it appears that a register > based machine should be faster than a stack machine, possibly by a considerable > margin. I don't know if you've seen this link Mark. There's a few pages of stats and discussion you might find interesting in general. https://users.ece.cmu.edu/~koopman/stack_computers/sec6_1.html#611 -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-04-27 05:42 -0700 |
| Message-ID | <6644ae1e-c790-4ed7-aecc-3f38e1c334e4@googlegroups.com> |
| In reply to | #58257 |
On Thursday, 27 April 2017 13:35:38 UTC+1, john wrote: > In article <261007ce-7c3d-436b-b393-d78048f1fd29@googlegroups.com>, > markwills1970@gmail.com says... > > > > On > > > > This is interesting. To me (un-educated idiot!) it appears that a register > > based machine should be faster than a stack machine, possibly by a considerable > > margin. > > I don't know if you've seen this link Mark. > There's a few pages of stats and discussion you might find interesting > in general. > > https://users.ece.cmu.edu/~koopman/stack_computers/sec6_1.html#611 > > -- > > john > > ========================= > http://johntech.co.uk > > "Bleeding Edge Forum" > http://johntech.co.uk/forum/ > > ========================= Thanks John, I'll take a look.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-27 14:00 +0100 |
| Message-ID | <odspr9$skg$1@dont-email.me> |
| In reply to | #58256 |
On 4/27/2017 13:05, Mark Wills wrote: > We have 100 filters in various pipelines on an gas plant. Internet of Things. Do a search on programming languages recommended for IoT and weep. C C++ Python PHP Javascript. And top of the list it appears to be Java. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-04-27 06:04 -0700 |
| Message-ID | <709edffb-0e49-4cb3-b2f7-e4860a2aed31@googlegroups.com> |
| In reply to | #58260 |
On Thursday, 27 April 2017 14:00:27 UTC+1, Alex wrote: > On 4/27/2017 13:05, Mark Wills wrote: > > We have 100 filters in various pipelines on an gas plant. > > Internet of Things. Do a search on programming languages recommended for > IoT and weep. C C++ Python PHP Javascript. And top of the list it > appears to be Java. > > -- > Alex Sorry Alex, I'm not following you. What was your point? M
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-27 15:31 +0100 |
| Message-ID | <odsv6k$h13$1@dont-email.me> |
| In reply to | #58261 |
On 4/27/2017 14:04, Mark Wills wrote: > On Thursday, 27 April 2017 14:00:27 UTC+1, Alex wrote: >> On 4/27/2017 13:05, Mark Wills wrote: >>> We have 100 filters in various pipelines on an gas plant. >> >> Internet of Things. Do a search on programming languages recommended for >> IoT and weep. C C++ Python PHP Javascript. And top of the list it >> appears to be Java. >> >> -- >> Alex > > Sorry Alex, I'm not following you. What was your point? > > M > Perhaps I oversnipped. What you're describing (small, independent, internet connected, smart devices) is more generally called IoT. The programming languages favoured by IoT developers vary; but rarely does Forth feature (if at all). For example http://www.cuelogic.com/blog/your-guide-to-the-best-iot-programming-languages/. Short version: assembler if you must, then the C family of languages. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 12:26 -0400 |
| Message-ID | <odt5u1$aj8$1@dont-email.me> |
| In reply to | #58256 |
On 4/27/2017 8:05 AM, Mark Wills wrote:
>
> We'll just concern ourselves with processing the table of pressures and
> computing and storing the differential.
>
> 1) An array of memory addresses contains the PI1 values.
> 2) Another array of memory addresses contains the PI2 values.
> 3) We'll compute the difference and store that in a third array.
>
> Assembly language:
>
> LOAD R0,PI1TAB ; PI1 of first filter
> LOAD R1,PI2TAB ; PI2 of first filter
> LOAD R2,DIFFTAB ; address of differential table
> LOAD R3,100 ; number of filters to process
> LOOP: ; start of loop
> SUB (R1)+,(R0) ; subtract PI2 from PI1 (indirect addressing)
> MOV (R0)+,(R2)+ ; store in differential table and advance address [1]
> DEC R3 ; finished?
> JNE LOOP ; loop back if not
>
> [1] indirect addressing with post increment on both operands
>
> Forth:
> create PI1TAB 100 cells allot \ PI1 table array
> create PI2TAB 100 cells allot \ PI2 table array
> create DIFFTAB 100 cells allot \ differential table array
>
> : computeDifferentials ( -- )
> 0 >r \ array index
> 100 begin \ 100 pairs to process
> PI1TAB r@ + @ \ fetch PI1 from P1 array
> PI2TAB r@ + @ \ fetch PI2 from P2 array
> - \ subtract them
> DIFTAB r@ + ! \ store in DIFTAB array
> r> 1 cells + >r \ advance array index
> 1- dup 0= until \ loop if not finished
> drop \ drop count
> r> drop \ drop array index
> ;
100 CONSTANT NCELLS
create PI1TAB NCELLS cells allot \ PI1 table array
create PI2TAB NCELLS cells allot \ PI2 table array
create DIFFTAB NCELLS cells allot \ differential table array
: PDifs ( -- )
NCELLS 0 DO
PI1TAB I CELLS + @
PI2TAB I CELLS + @
-
DIFTAB I CELLS + !
LOOP ;
In reality I would write words for the tables that would automatically
do the index calculations, but that would mask the point of the comparison.
I will point out the register machine is doing all the same work. The
index calculations are inherent in the instructions, but they require
the same calculations and complicate the instructions.
> Which is more efficient?
Define "efficiency".
> Which is faster?
They would likely be very similar in speed because they are doing
exactly the same data movements and calculations... except that the
stack machine is using much simpler instructions that are easy to
decode, etc. So the stack machine has potential for a faster clock.
> I'd argue that the "regular" CPU code is (probably) faster, because
> the Forth code is spending quite a lot of time thrashing the return
> stack. If we're thrashing the return stack *then we're not getting
> our work done*.
Yes, if you use the return stack for no good reason you can get some
very bad performance.
> I'd say the above is quite idiomatic Forth, but I'm always happy to be
> schooled. I like Forth very much, but I don't profess to be particularly
> good at writing awesome/cool/neat/lean/clean/efficient Forth.
How about just reasonable code?
> Of course, a Forth *cpu* probably would not have begin/until instructions.
Why not? BEGIN is a marker like LOOP: in the register code and UNTIL is
just a comparison and a conditional jump. Conceivably this could be a
single instruction, but yes, more likely it would be two instructions,
at least in my designs as changing the instruction fetch address after a
compare would be late in the cycle and slow it down. Better to separate
the compare and the conditional into two instructions.
--
Rick C
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-04-29 08:04 -0700 |
| Message-ID | <d01c239b-8340-449b-a2b7-b8c6c20d831a@googlegroups.com> |
| In reply to | #58256 |
On Thursday, April 27, 2017 at 7:05:28 AM UTC-5, Mark Wills wrote: > Forth: > create PI1TAB 100 cells allot \ PI1 table array > create PI2TAB 100 cells allot \ PI2 table array > create DIFFTAB 100 cells allot \ differential table array > > : computeDifferentials ( -- ) > 0 >r \ array index > 100 begin \ 100 pairs to process > PI1TAB r@ + @ \ fetch PI1 from P1 array > PI2TAB r@ + @ \ fetch PI2 from P2 array > - \ subtract them > DIFTAB r@ + ! \ store in DIFTAB array > r> 1 cells + >r \ advance array index > 1- dup 0= until \ loop if not finished > drop \ drop count > r> drop \ drop array index > ; > > I'd say the above is quite idiomatic Forth "when you seen idiomatic Forth, you've seen --" Compare the following: : foo ( a -- a' ) [ 2 cells ] literal + ; : foo ( a -- a' ) 2 cells + ; Which is more idiomatic? I would say, the first is idiomatic of Forth when you don't have at least a peephole optimizer, and the second is idiomatic of Forth when you do have one. Of return-stack manipulation, I prefer 2+1 (two items on data stack, one item on return stack) with simpler compilers and then 3+0 (nothing on return stack) with more advanced compilers. Then you have ALLOCATE which is fine enough until you start dumping images after which it can become an obstruction. Likewise, do you use lots of wordlists or do you instead avoid them and do things like behead your private words? Some systems have no real limitations on wordlists and others have fairly severe limitations on them.
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-04-27 10:30 +0100 |
| Message-ID | <MPG.336bca9db4c7e4198970e@news.virginmedia.com> |
| In reply to | #58211 |
In article <odr30q$644$1@dont-email.me>, gnuarm@gmail.com says... > > 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. > > nail, head, bang... -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 12:32 -0400 |
| Message-ID | <odt68j$aj8$2@dont-email.me> |
| In reply to | #58246 |
On 4/27/2017 5:30 AM, john wrote: > In article <odr30q$644$1@dont-email.me>, gnuarm@gmail.com says... >> >> 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. >> >> > > nail, head, bang... Easier said than done though. Flexible changes in the CPU design require flexible software to support those changes. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-04-28 12:01 +0100 |
| Message-ID | <MPG.336d31576d468da989711@news.virginmedia.com> |
| In reply to | #58277 |
In article <odt68j$aj8$2@dont-email.me>, gnuarm@gmail.com says... > > On 4/27/2017 5:30 AM, john wrote: > > In article <odr30q$644$1@dont-email.me>, gnuarm@gmail.com says... > >> > >> 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. > >> > >> > > > > nail, head, bang... > > Easier said than done though. Flexible changes in the CPU design > require flexible software to support those changes. I absolutley agree. Much easier said than done. Even more so when your interest is in making it work the other way round. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-04-26 21:34 -0500 |
| Message-ID | <074892a8-d98c-6c96-6e80-5aff72593b3d@cbayona.com> |
| In reply to | #58178 |
On 4/26/2017 5:33 AM, Mark Wills wrote: > > 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. > Sorry for the late reply, I lost Internet access from last night until late this afternoon, bit thunderstorms wiped out equipment and cable last night. In any case a few persons have replied to your comment and questions, my advice is basically the same. FPGA manufactures offer for the most part free tools, most of them handle both VHDL and Verilog at the same time for a project, there are also many Open tools available some handle both languages some don't. ASIC for the most part needs the use of the tool provided by the manufacturer but I'm not an expert in that area. ASICs are meant for high volumes so they are expensive or even not available in small quantities, specially for the hobbyist or small production FPGA is the way to go. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 01:26 -0400 |
| Message-ID | <odrv7d$ao6$1@dont-email.me> |
| In reply to | #58220 |
On 4/26/2017 10:34 PM, Cecil Bayona wrote: > > ASIC for the most part needs the use of the tool provided by the > manufacturer but I'm not an expert in that area. ASICs are meant for > high volumes so they are expensive or even not available in small > quantities, specially for the hobbyist or small production FPGA is the > way to go. I recall that one time Green Arrays announced the receipt of some thousands of chips and someone pointed out that was the number you would get with the minimum number of wafers in a "prototype" run from some chip vendor. lol Yes, ASICs are not for small runs but I think there is one company that does chip batching not so different from they way OSHPARK does for PCBs. It still cost some significant bucks, but you don't need to buy 100,000 of them. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-27 21:25 -0700 |
| Message-ID | <87r30df9al.fsf@nightsong.com> |
| In reply to | #58230 |
rickman <gnuarm@gmail.com> writes: > ASICs are not for small runs but I think there is one company that > does chip batching not so different from they way OSHPARK does for > PCBs. There are several of those, MOSIS being the best known. http://cmp.imag.fr/technologies/price-list.html shows small chips in old processes (0.35u) almost in hobbyist range, though I'm not sure what you can do with it that you couldn't also do at better performance with a modern FPGA.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-28 02:50 -0400 |
| Message-ID | <oduohi$p5m$1@dont-email.me> |
| In reply to | #58291 |
On 4/28/2017 12:25 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> ASICs are not for small runs but I think there is one company that >> does chip batching not so different from they way OSHPARK does for >> PCBs. > > There are several of those, MOSIS being the best known. > > http://cmp.imag.fr/technologies/price-list.html > > shows small chips in old processes (0.35u) almost in hobbyist range, > though I'm not sure what you can do with it that you couldn't also do > at better performance with a modern FPGA. FPGAs are hobbled with slow routing delays. I don't know how fast a 350 nm device would be, but the GA144 cranks 700 MIPS in a 180 nm process. The 180 nm process is only twice as expensive as the 350 nm and gives chips a quarter the area and faster. Both should be more than fully amortized which is the main expense. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2017-04-28 00:23 -0700 |
| Message-ID | <6009c76f-141f-482a-8e86-d8d259b35eba@googlegroups.com> |
| In reply to | #58294 |
Just for comparison: - In 1996 DEC Alpha 21164 EV56 using a 0.35um process node clocked up to 666MHz. - In 2000 DEC Alpha 21264B EV68C using IBM 0.18um process node with copper interconnect clocked at 1250MHz. pahihu
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-28 07:46 +0000 |
| Message-ID | <2017Apr28.094610@mips.complang.tuwien.ac.at> |
| In reply to | #58294 |
rickman <gnuarm@gmail.com> writes:
>FPGAs are hobbled with slow routing delays. I don't know how fast a 350
>nm device would be, but the GA144 cranks 700 MIPS in a 180 nm process.
350nm: 300MHz Klamath (Pentium II), 266MHz K6
180nm: 1100MHz Coppermine (Pentium III), 1700MHz Palomino (Athlon XP),
2000MHz Williamette (Pentium 4)
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-04-28 02:25 -0700 |
| Message-ID | <05c4c86b-319e-4d69-8bac-49c9d54d9089@googlegroups.com> |
| In reply to | #58294 |
Why does smaller mean faster? Speed of light is speed of light. Is it because smaller transistors can switch faster?
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web