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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 11:10 -0400 |
| Message-ID | <odt1fb$p81$2@dont-email.me> |
| In reply to | #58245 |
On 4/27/2017 5:22 AM, Ilya Tarasov wrote: > > 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. You continue to not understand basic English. Go ahead and "pass" me to an appropriate department. :) -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 11:25 -0400 |
| Message-ID | <odt2am$smm$1@dont-email.me> |
| In reply to | #58264 |
On 4/27/2017 11:10 AM, rickman wrote: > On 4/27/2017 5:22 AM, Ilya Tarasov wrote: >> >> 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. > > You continue to not understand basic English. Go ahead and "pass" me to > an appropriate department. :) But please don't send me to room 101! -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 11:08 -0400 |
| Message-ID | <odt1bm$p81$1@dont-email.me> |
| In reply to | #58241 |
On 4/27/2017 5:10 AM, Mark Wills wrote: > > 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 As I made the comment and *then* Ilya replied, it would be hard to say I was threatening him/her in particular much less anyone else. On 4/25/2017 2:34 PM, Ilya Tarasov wrote: > вторник, 25 апреля 2017 г., 21:15:46 UTC+3 пользователь rickman написал: >> On 4/25/2017 1:37 PM, Cecil Bayona wrote: >>> >>> I have books on both languages so I will think about it for a month or >>> two before I have to make a decision. >> >> Oh yeah, if you do decide to use VHDL I don't ever want to see you use >> >> if (clk'event and clk '1') >> > > if rising_edge(clk) > 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. You just made me realize the use of local variables would be related to an idea I had that combines a stack with register-like access. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-27 16:14 +0100 |
| Message-ID | <odt1nf$q3j$1@dont-email.me> |
| In reply to | #58263 |
On 4/27/2017 16:08, rickman wrote: > On 4/27/2017 5:10 AM, Mark Wills wrote: >> >> 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 > > As I made the comment and *then* Ilya replied, it would be hard to > say I was threatening him/her in particular much less anyone else. > > On 4/25/2017 2:34 PM, Ilya Tarasov wrote: >> вторник, 25 апреля 2017 г., 21:15:46 UTC+3 пользователь rickman >> написал: >>> On 4/25/2017 1:37 PM, Cecil Bayona wrote: >>>> >>>> I have books on both languages so I will think about it for a >>>> month or two before I have to make a decision. >>> >>> Oh yeah, if you do decide to use VHDL I don't ever want to see >>> you use >>> >>> if (clk'event and clk '1') >>> >> >> if rising_edge(clk) > > >> 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. > > You just made me realize the use of local variables would be related > to an idea I had that combines a stack with register-like access. > https://en.wikipedia.org/wiki/Mill_architecture#The_belt.2C_a_pipelining_register_system -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-27 16:17 +0100 |
| Message-ID | <odt1t7$q3j$2@dont-email.me> |
| In reply to | #58265 |
On 4/27/2017 16:14, Alex wrote: > On 4/27/2017 16:08, rickman wrote: >> On 4/27/2017 5:10 AM, Mark Wills wrote: >>> >>> 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 >> >> As I made the comment and *then* Ilya replied, it would be hard to >> say I was threatening him/her in particular much less anyone else. >> >> On 4/25/2017 2:34 PM, Ilya Tarasov wrote: >>> вторник, 25 апреля 2017 г., 21:15:46 UTC+3 пользователь rickman >>> написал: >>>> On 4/25/2017 1:37 PM, Cecil Bayona wrote: >>>>> >>>>> I have books on both languages so I will think about it for a >>>>> month or two before I have to make a decision. >>>> >>>> Oh yeah, if you do decide to use VHDL I don't ever want to see >>>> you use >>>> >>>> if (clk'event and clk '1') >>>> >>> >>> if rising_edge(clk) >> >> >>> 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. >> >> You just made me realize the use of local variables would be related >> to an idea I had that combines a stack with register-like access. >> > > https://en.wikipedia.org/wiki/Mill_architecture#The_belt.2C_a_pipelining_register_system > > Sorry, the primary link is https://en.wikipedia.org/wiki/Belt_machine -- Alex
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 11:46 -0400 |
| Message-ID | <odt3i5$1fh$1@dont-email.me> |
| In reply to | #58266 |
On 4/27/2017 11:17 AM, Alex wrote: > On 4/27/2017 16:14, Alex wrote: >> On 4/27/2017 16:08, rickman wrote: >>> On 4/27/2017 5:10 AM, Mark Wills wrote: >>>> >>>> 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 >>> >>> As I made the comment and *then* Ilya replied, it would be hard to >>> say I was threatening him/her in particular much less anyone else. >>> >>> On 4/25/2017 2:34 PM, Ilya Tarasov wrote: >>>> вторник, 25 апреля 2017 г., 21:15:46 UTC+3 пользователь rickman >>>> написал: >>>>> On 4/25/2017 1:37 PM, Cecil Bayona wrote: >>>>>> >>>>>> I have books on both languages so I will think about it for a >>>>>> month or two before I have to make a decision. >>>>> >>>>> Oh yeah, if you do decide to use VHDL I don't ever want to see >>>>> you use >>>>> >>>>> if (clk'event and clk '1') >>>>> >>>> >>>> if rising_edge(clk) >>> >>> >>>> 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. >>> >>> You just made me realize the use of local variables would be related >>> to an idea I had that combines a stack with register-like access. >>> >> >> https://en.wikipedia.org/wiki/Mill_architecture#The_belt.2C_a_pipelining_register_system >> >> > > Sorry, the primary link is https://en.wikipedia.org/wiki/Belt_machine Interesting. I can't quite picture how items "fall" off the end of the belt. I guess it is not like a stack where the items have to be carefully managed and explicitly dropped when no longer needed. An item simply ages and falls off the end when the belt is full. It doesn't matter that it was no longer needed some time ago. My idea is similar using a stack and very limited access into the stack. To keep the "register" fields in the instruction small access into the stack would be limited. The main goal is to reduce stack management operations which typically affect the top three items, (swap, over, etc) so deep access is not needed. I have a spreadsheet I did to evaluate some instruction sets in an implementation of an interrupt driven routine for a DDS. I see clock cycle counts ranging from 103 to 60 as I improve the process. I should get back to that and complete a design. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-27 14:07 -0700 |
| Message-ID | <2f8382e9-807d-4ebc-884d-32950cd1e78a@googlegroups.com> |
| In reply to | #58241 |
On Thursday, April 27, 2017 at 2:10:26 AM UTC-7, Mark Wills wrote: > On Thursday, 27 April 2017 09:52:34 UTC+1, Ilya Tarasov wrote: > > четверг, 27 апреля 2017 г., 4:08:01 UTC+3 пользователь rickman написал: > > > 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. Rickman has said "Bye" to me multiple times --- each time, I am happy that I won't be attacked by him again --- this never lasts more than a few days, and he is back at it again. This thread has now become composed almost entirely of long-winded Rickman posts, one after another, with no posts by anybody else in between. Rickman is obsessed with proving that he is right, and coming out on top --- he is trying to overwhelm Ilya's few posts --- as Joseph Stalin said: "Quantity has a quality of its own." > > 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. ANS-Forth is a cult! They are very creepy people who routinely make death threats against their perceived enemies, then later claim that it was all tongue-in-cheek, not aimed at anybody in particular, and just a big joke --- so it is actually the fault of the person they are attacking that he doesn't have enough of a sense of humor to laugh along with the joke --- chortle! chortle! yuk! yuk! They weren't joking though. Rickman clearly threatened to do a web attack against Ilya: On Tuesday, April 25, 2017 at 12:15:33 PM UTC-7, rickman wrote: > On 4/25/2017 3:00 PM, Cecil Bayona wrote: > > On 4/25/2017 1:39 PM, Ilya Tarasov wrote: > >> вторник, 25 апреля 2017 г., 21:38:05 UTC+3 пользователь > >> hughag...@gmail.com написал: > >>> Rickman has threatened to burn your house down --- aren't you scared? > >>> --- good thing you are in Russia, rather than in Rickman's city which > >>> is presumably here in the "Land of the Free." > >> > >> Checking my abilities to defend myself, it is better to Rickman to not > >> to try make me scared :D > >> > > A Kalashnikov is a wonderful equalizer, it can solve difficult problems > > quite effectively. > > It doesn't work very well against web based attacks. > > -- > > Rick C I blame Elizabeth Rather for this. She is totally focused on collecting sycophants --- her self-worth is directly based upon how many followers she has --- she is totally fine with creeps and twits, so long as they are loyal to her, because when it comes to sycophants: "Quantity has a quality of its own."
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 17:58 -0400 |
| Message-ID | <odtpbt$fjr$1@dont-email.me> |
| In reply to | #58287 |
On 4/27/2017 5:07 PM, hughaguilar96@gmail.com wrote: > > I blame Elizabeth Rather for this. What???!!! I can't be an Internet hazard on my own? This can only happen if someone spurs me on??? Rather than Hugh getting help, maybe I need therapy to learn to totally ignore him. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-26 20:34 -0700 |
| Message-ID | <87y3umjzfq.fsf@nightsong.com> |
| In reply to | #58215 |
rickman <gnuarm@gmail.com> writes: > 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. It seems to me from your examples that very small stack machines beat very small register machines. I don't see evidents that big stack machines (maybe because none exist) beat big register machines. It could be that the methods used to speed up high end register architecture implementations don't work as well on stack architectures. Examples: extensive register renaming, OOO, caching etc.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 01:07 -0400 |
| Message-ID | <odru5c$7pe$2@dont-email.me> |
| In reply to | #58221 |
On 4/26/2017 11:34 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> 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. > > It seems to me from your examples that very small stack machines beat > very small register machines. I don't see evidents that big stack > machines (maybe because none exist) beat big register machines. It > could be that the methods used to speed up high end register > architecture implementations don't work as well on stack architectures. > Examples: extensive register renaming, OOO, caching etc. If you read Koopman's book you will find info on large stack machines. Stack machines use other optimizations. I would think it would be fairly obvious that things like register renaming just don't apply to stack machines. That doesn't mean there aren't other ways of speeding up stack machines. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-27 21:21 -0700 |
| Message-ID | <87vappf9gr.fsf@nightsong.com> |
| In reply to | #58228 |
rickman <gnuarm@gmail.com> writes: > If you read Koopman's book you will find info on large stack machines. I read Koopman's book some time back, don't remember anything about large stack machines from it, might look again, but I'm quite sure no large stack machine (superscalar etc.) has ever been built.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-28 08:54 +0000 |
| Message-ID | <2017Apr28.105453@mips.complang.tuwien.ac.at> |
| In reply to | #58290 |
Paul Rubin <no.email@nospam.invalid> writes:
>I'm quite sure no
>large stack machine (superscalar etc.) has ever been built.
One of the features of the T9000 was superscalar execution, but it was
cancelled (prototypes may have been built). However, from what I
remember, what it did was to group stuff like load-load-add-store into
one macroinstruction, and execute that in one pass through the
pipeline, but not independent computations; and there definitely was
no OoO or register renaming in the T9000; you would need that for
truly superscalar execution of single-stack code.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2017-04-28 10:46 +0100 |
| Message-ID | <20170428104625.5b843569@t530.lan> |
| In reply to | #58290 |
On Thu, 27 Apr 2017 21:21:40 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > I read Koopman's book some time back, don't remember anything > about large stack machines from it, might look again, but I'm > quite sure no large stack machine (superscalar etc.) has ever > been built. You are right, the book only mentions data stack caching, which is the equivalent of having a large register set. Koopman shows that having about 12 cached stack items reduces fill and spill operations to about 2% of instructions in the simple test programs used. [1] To build a PC size stack engine 'register renaming', OoO execution, MMU, and the other methods you mentioned will likely be needed. The stack engine techniques used may differ, and use less transistors, for example: Operand storage might use 32 registers, with allocation and 'spill/fill' operations mostly handled explicitly by the compiler. An equivalent large stack engine might have a stack cache in which the top 8 items are re-orderable and accessible, and the remaining 24 are a pure stack. Obviously the compiler and code are simpler, with no explicit operand selection. The small multi-port memory array used for registers or stack cache is faster than general on-chip memory caches because of it's size. (All on-chip memory is ~10x faster and ~50x less power hungry than accessing external DRAM, which is part of the reason why larger processors are more complex) In the register machine a 1 of 32 mux is needed to access the register selected by the compiler. In the stack engine this is only 1 of 8. The most resource demanding part of this hardware is read data path operand selection. An implementation might use two input data data selectors. For the register machine 31 are needed for each data bit path, but only 7 for the stack engine. Also, the relative operand path delay is 1.7 times longer for the register machine. There is definitely a bit of apples vs oranges in this, but IMO not enough to make the comparison plain wrong. Jan Coombs -- [1] https://users.ece.cmu.edu/~koopman/stack_computers/sec6_4.html#641
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2017-04-27 10:46 +0100 |
| Message-ID | <20170427104627.42be65db@t530.lan> |
| In reply to | #58221 |
On Wed, 26 Apr 2017 20:34:49 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > rickman <gnuarm@gmail.com> writes: > > 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. > > It seems to me from your examples that very small stack > machines beat very small register machines. I don't see > evidents that big stack machines (maybe because none exist) > beat big register machines. It could be that the methods used > to speed up high end register architecture implementations > don't work as well on stack architectures. Examples: extensive > register renaming, OOO, caching etc. Where a stack machine is built entirely within an FPGA, all memories are equally (very) fast, then there is less need for these methods. But, I think more than one large stack engine had data stack cache. (SC32, PSC1000 ?) You are right that these methods need to be adapted for a stack engine. I would expect to find "extensive register renaming, OOO, [and] caching" in a PC sized stack engine, and have planned to incorporate these in mine[1] if it grows that big. I already need a code cache, because the flash memory on my board is four times slower than the on-chip RAM, and has a latency of 32 system clocks. The solution I'm looking at slurps a basic block of code into cache. When a call instruction is encountered only the remainimg unexecuted instructions are retained. With restricted construction the cache line can contain a loop of primitives including other conditionals. When the cache is full it starts dumping the oldest code fragments. I'm also looking at incorporating a radically simplified token accessible MMU to provide memory access control, array bounds enforcement, disk buffering for data and code, and similar. Is there anything else big lurking under your "etc"? Jan Coombs -- [1] intending to use open-source development once out the door.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-04-27 12:05 +0200 |
| Message-ID | <86vapqjhca.fsf@molnjunk.nocrew.org> |
| In reply to | #58247 |
Jan Coombs wrote: > I already need a code cache, because the flash memory on my board is > four times slower than the on-chip RAM, and has a latency of 32 system > clocks. The solution I'm looking at slurps a basic block of code into > cache. One idea I saw somewhere was to use the return stack as a kind of code cache. The way it would supposedly work was to not store addresses on the stack, but entire words. Say, a cache line worth of code for each stack item. It would be interesting to hear from the hardware folks if this would be at all feasible?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 11:50 -0400 |
| Message-ID | <odt3pu$2e4$1@dont-email.me> |
| In reply to | #58251 |
On 4/27/2017 6:05 AM, Lars Brinkhoff wrote: > Jan Coombs wrote: >> I already need a code cache, because the flash memory on my board is >> four times slower than the on-chip RAM, and has a latency of 32 system >> clocks. The solution I'm looking at slurps a basic block of code into >> cache. > > One idea I saw somewhere was to use the return stack as a kind of code > cache. The way it would supposedly work was to not store addresses on > the stack, but entire words. Say, a cache line worth of code for each > stack item. > > It would be interesting to hear from the hardware folks if this would be > at all feasible? Sure, it is feasible, but there is a hit in speed in that this would add a multiplexer to the data path for instructions, not that it would be a large hit, but around 2 ns in most FPGAs. What would the purpose of this be exactly? How would it be managed? I would think that would be the hard part. Cache is memory plus a bunch of management to know what is in the memory and to make decisions about what to keep and what to toss and what to fetch. The memory is the easy part. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-04-28 11:23 +0200 |
| Message-ID | <86d1bwkhqt.fsf@molnjunk.nocrew.org> |
| In reply to | #58272 |
rickman wrote: >> One idea I saw somewhere was to use the return stack as a kind of >> code cache. The way it would supposedly work was to not store >> addresses on the stack, but entire words. Say, a cache line worth of >> code for each stack item. > > What would the purpose of this be exactly? How would it be managed? I don't know, exactly. I read about it in a blog post somewhere, but I can't seem to find it now. It was about the F18A or colorForth or GreenArrays. I thoughth it was an interesting and novel idea. At first it seems strange, but when you think about it, it should work out. > I would think that would be the hard part. Cache is memory plus a > bunch of management to know what is in the memory and to make > decisions about what to keep and what to toss and what to fetch. Storing code in the return stack wouldn't exactly be caching. The top few items would have a high likelihood of being needed, but the bottom items would probably not. And many frequently executed definitions probably wouldn't be in the stack.
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-04-27 11:43 +0100 |
| Message-ID | <MPG.336bdbc22a277c3f98970f@news.virginmedia.com> |
| In reply to | #58247 |
In article <20170427104627.42be65db@t530.lan>, jenfhaomndgfwutc@murmic.plus.com says... > > It seems to me from your examples that very small stack > > machines beat very small register machines. I don't see > > evidents that big stack machines (maybe because none exist) > > beat big register machines. It could be that the methods used > > to speed up high end register architecture implementations > > don't work as well on stack architectures. Examples: extensive > > register renaming, OOO, caching etc. > There does seem to be little evidence of this one way or the other. (At least I've found little myself.) I think there is an assumtion that because early machines/software went this way because it was seen as more efficient that it must always be so. However the few off the cuff experiments I've seen (cant say where) tend to support the notion that a number of small stack machines will always be faster than register based architecture/OS given current fabrication techniques in situations where there is no trade off for cost. My own belief is that this "notion" should bubble down to lower cost production but I can't proove it myself (yet) or find supporting evidence. If you find some I'd welcome a post in my forum. PS - it occurrs to me as I write that Inmos transputers would fit this idea. -- 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 11:57 -0400 |
| Message-ID | <odt483$426$1@dont-email.me> |
| In reply to | #58255 |
On 4/27/2017 6:43 AM, john wrote: > In article <20170427104627.42be65db@t530.lan>, > jenfhaomndgfwutc@murmic.plus.com says... >>> It seems to me from your examples that very small stack >>> machines beat very small register machines. I don't see >>> evidents that big stack machines (maybe because none exist) >>> beat big register machines. It could be that the methods used >>> to speed up high end register architecture implementations >>> don't work as well on stack architectures. Examples: extensive >>> register renaming, OOO, caching etc. >> > There does seem to be little evidence of this one way or the other. > (At least I've found little myself.) > I think there is an assumtion that because early machines/software > went this way because it was seen as more efficient that it must always > be so. However the few off the cuff experiments I've seen (cant say where) > tend to support the notion that a number of small stack machines > will always be faster than register based architecture/OS given current > fabrication techniques in situations where there is no trade off for cost. > My own belief is that this "notion" should bubble down to lower cost > production but I can't proove it myself (yet) or find supporting evidence. > If you find some I'd welcome a post in my forum. > > PS - it occurrs to me as I write that Inmos transputers would fit this idea. In terms of the data path the only real difference between stack machines and register machines is that register machines provide for direct addressing of any register at any time. A stack machine uses a virtual stack implemented by a register like memory addressed by a stack point or an actual stack that is a more complex block of registers that move data up and down the array (not very often used). So the difference is mainly in the controlling logic (instruction decode and number of control points) and instruction size. A stack machine like the J1 uses a 16 bit instruction, so the only thing left is the complexity of the control logic. Give me the logic elements of a stack machine and I can create a register machine from them and vice versa. The only real difference is the complexity of the instruction set. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 11:21 -0400 |
| Message-ID | <odt244$rn7$1@dont-email.me> |
| In reply to | #58247 |
On 4/27/2017 5:46 AM, Jan Coombs wrote: > On Wed, 26 Apr 2017 20:34:49 -0700 > Paul Rubin <no.email@nospam.invalid> wrote: > >> rickman <gnuarm@gmail.com> writes: >>> 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. >> >> It seems to me from your examples that very small stack >> machines beat very small register machines. I don't see >> evidents that big stack machines (maybe because none exist) >> beat big register machines. It could be that the methods used >> to speed up high end register architecture implementations >> don't work as well on stack architectures. Examples: extensive >> register renaming, OOO, caching etc. > > Where a stack machine is built entirely within an FPGA, all > memories are equally (very) fast, then there is less need for > these methods. But, I think more than one large stack engine > had data stack cache. (SC32, PSC1000 ?) I don't recall the name, but I think it was Chuck's first stack processor chip. The question I have is how often did the on-chip cache have to spill to the external memory? Judging by the size of stacks on his later chips I think it was seldom. Interesting to see how the stack size progressed. It started virtually infinite by spilling to external memory and shrunk over iterations until it is not just 10 items deep, with an 8 item circular stack. I think main memory access would be more of an issue with the need to access programs external to the chip having the potential to slow things down enormously. > You are right that these methods need to be adapted for a stack > engine. I would expect to find "extensive register renaming, > OOO, [and] caching" in a PC sized stack engine, and have planned > to incorporate these in mine[1] if it grows that big. What does "register renaming" mean in a stack machine? > I already need a code cache, because the flash memory on my > board is four times slower than the on-chip RAM, and has a > latency of 32 system clocks. > > The solution I'm looking at slurps a basic block of code into > cache. When a call instruction is encountered only the > remainimg unexecuted instructions are retained. With restricted > construction the cache line can contain a loop of primitives > including other conditionals. When the cache is full it starts > dumping the oldest code fragments. Sounds very complex. My understanding is that cache is not as effective with threaded code as more linear code. It also causes pipeline flushes. What type of applications are you addressing with your CPU design? > I'm also looking at incorporating a radically simplified token > accessible MMU to provide memory access control, array bounds > enforcement, disk buffering for data and code, and similar. > > Is there anything else big lurking under your "etc"? > > Jan Coombs > -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web