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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 11:58 -0400 |
| Message-ID | <odt49r$426$2@dont-email.me> |
| In reply to | #58267 |
On 4/27/2017 11:21 AM, rickman wrote: > 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. -------(now) > 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]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-28 07:53 -0500 |
| Message-ID | <guOdnVqji7vYpp7EnZ2dnUU7-YvNnZ2d@supernews.com> |
| In reply to | #58267 |
rickman <gnuarm@gmail.com> wrote: > 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: >> >> >> 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. It can't have been, because Chuck's first chip was Novix, and Novix had external stack memories. There was no stack cache, unless you count T and N. The single-cycle stack memory chips were fast enough to get pretty hot: it was certainly the first time I'd seen that in pure CMOS. The maximum clock was limited by the speed of the stack chips. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2017-04-28 22:31 +0100 |
| Message-ID | <20170428223115.78f00ead@t530.lan> |
| In reply to | #58267 |
On Thu, 27 Apr 2017 11:21:40 -0400 rickman <gnuarm@gmail.com> wrote: > What does "register renaming" mean in a stack machine? We usually use descriptive labels for data stack documentation, but surely the basic machine names for stack items are their offset from TOS: : xxx ( 3 2 1 0 -- 1 0 ) \ ... Where instructions are executed strictly sequentially, then no 'renaming' is required or possible. But where instruction execution may overlap (Superscalar or OoO execution) then 'renaming' might happen, for example: Assume a stack processor with a good size and broadly accessible stack cache, in which many instructions are executed in one clock cycle, but some take more, multiplication needs 8. Executing this code: : frigd ( a b c d -- a+b-c*d ) * rot rot + swap - ; runs like this: Cyc Stack Word c*d name --- ----- ---- -------- 0 (S a b c d ) : [none] 1 (S a b c d ) * [none] 2 (S a b c*d ) rot 0 3 (S b c*d a ) rot 1 4 (S c*d a b ) + 2 5 (S c*d a+b ) swap 1 6 (S a+b c*d ) - 0 7 (S a+b-c*d ) ; [none] The multiplier is still running at cycle 7, when the Exit instruction is executed. Just after the multiplication started, the stack picture was (S a b c*d ), or ( 1 0 -- 0 ) in machine terms. By following the position of the humanly readable c*d stack item you can see that it's actual machine name is changing on almost every instruction. The data item creation by the first multiply and destruction by the subtract must also be something to do with renaming. Does not the renaming operations internal to register processors have the same purpose and functionality? Jan Coombs
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-28 20:14 -0400 |
| Message-ID | <oe0lmj$901$1@dont-email.me> |
| In reply to | #58315 |
On 4/28/2017 5:31 PM, Jan Coombs wrote: > On Thu, 27 Apr 2017 11:21:40 -0400 > rickman <gnuarm@gmail.com> wrote: > >> What does "register renaming" mean in a stack machine? > > We usually use descriptive labels for data stack documentation, > but surely the basic machine names for stack items are their > offset from TOS: > > : xxx ( 3 2 1 0 -- 1 0 ) \ ... > > Where instructions are executed strictly sequentially, then no > 'renaming' is required or possible. But where instruction > execution may overlap (Superscalar or OoO execution) then > 'renaming' might happen, for example: > > Assume a stack processor with a good size and broadly accessible > stack cache, in which many instructions are executed in one > clock cycle, but some take more, multiplication needs 8. > > Executing this code: > > : frigd ( a b c d -- a+b-c*d ) * rot rot + swap - ; > > runs like this: > > Cyc Stack Word c*d name > --- ----- ---- -------- > 0 (S a b c d ) : [none] > 1 (S a b c d ) * [none] > 2 (S a b c*d ) rot 0 > 3 (S b c*d a ) rot 1 > 4 (S c*d a b ) + 2 > 5 (S c*d a+b ) swap 1 > 6 (S a+b c*d ) - 0 > 7 (S a+b-c*d ) ; [none] > > The multiplier is still running at cycle 7, when the Exit > instruction is executed. Just after the multiplication started, > the stack picture was (S a b c*d ), or ( 1 0 -- 0 ) in machine > terms. > > By following the position of the humanly readable c*d stack > item you can see that it's actual machine name is changing on > almost every instruction. The data item creation by the first > multiply and destruction by the subtract must also be something > to do with renaming. I don't follow. I see what is happening on the stack, but I don't see how this has anything to do with register renaming. Are you saying that to execute overlapped operations the operands and results have to be accessed on the stack by addressing into the stack? I believe that makes it a register machine in a real sense. Stack juggling evaporates and all operands are just addressed. No? > Does not the renaming operations internal to register > processors have the same purpose and functionality? > > Jan Coombs > -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2017-04-30 16:08 +0100 |
| Message-ID | <20170430160843.702dbe4f@t530.lan> |
| In reply to | #58319 |
On Fri, 28 Apr 2017 20:14:11 -0400
rickman <gnuarm@gmail.com> wrote:
>> > What does "register renaming" mean in a stack machine?
[reply deleted]
> I don't follow. I see what is happening on the stack, but I
> don't see how this has anything to do with register renaming.
With the help of Anton's comments I've thought it through again,
and the notes below are perhaps a little clearer?
Register Machine
----------------
Pgmr. Model Internal Architecture
----------- ---------------------
complex
R0 R1 R2 R3 ==> dynamic ==> r0 r1 r2 r3 r4 r5 r6 r7
| | mapping | |
|fixed-size| |---larger-fixed-size---|
Stack Machine
-------------
Pgmr Model Internal Architecture
---------- ---------------------
simple
... S2 S1 S0 ==> explicit ==> ... s2 s1 s0 s-1 s-2 s-3 ...
| | mapping | |
|-varbl-size-| |-------variable-size--------|
Stack Example
-------------
NOOP instructions and some others require one clock cycle.
: * ( c d -- c*d ) \ multiply is a primitive in hardware, and
\ takes eight cycles to complete
Pgmr. Model Internal Notes
----------- -------- -----
(S c d (s 1 0 before multiplication starts
setup operands
(S c d (s 1 0 consume 1st multiplicand
(S c (s 0 -1 consume 2nd multiplicand
(S (s -1 -2 allocate space for product
(S x (s 0 -1 -2
(S x (s 0 -1 -2 multiplication in progress
x is part of product
cleanup operands
(S c*d (s 0 -1 -2 first
(S c*d (s 0 -1 and second
(S c*d (s 0
(S c*d (s 0 multiplication complete
The above shows the stack item renaming that would happen if the
multiplication was followed by eight NOOP instructions.
If other instructions were here the internal stack effects
would be more complex, but equally predictable. These other
instructions would push the product 'c*d' down the data stack
while the multiplication is in progress, effective renaming it
in machine terms.
Note also that in addition to the eight clock cycles needed to
perform multiplication, a further six are required to really
tart it up:)
Jan Coombs
--
> > Does not the renaming operations internal to register
> > processors have the same purpose and functionality?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-29 13:48 +0000 |
| Message-ID | <2017Apr29.154835@mips.complang.tuwien.ac.at> |
| In reply to | #58267 |
rickman <gnuarm@gmail.com> writes:
>On 4/27/2017 5:46 AM, Jan Coombs wrote:
>> 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?
You would probably call it something else, but the basic mechanism is
similar: each new computed value is given a new physical
(microarchitectural) register, and the stack becomes only an
architectural way of describing the data flow to the
microarchitecture, just as the architectural registers on a register
machine are the architectural way to describe the data flow to the
microarchitecture. E.g., if you have several iterations of the loop
body
dup @ 1+ over ! cell+
(let's ignore loop control for now.)
Then the first loop iteration might be somthing like that to the data
flow engine
1 r100 = r99 @
2 r101 = r100+1
3 r101 r99 !
4 r102 = r99+cell
The second iteration gets new physical registers, but otherwise the
computation is the same:
5 r103 = r102 @
6 r104 = r103+1
7 r104 r102 !
8 r105 = r102+cell
The cool thing here is that instruction 1 and 4 can be executed right
away; since 4 takes only one cycle, in the next cycle we can already
start instrucions 5 (this requires assuming (and later verifying) that
the @ does not fetch from the same address as the ! in instruction 3)
and 8, and in the next cycle the corresponding instructions from the
next iteration. Instruction 1 takes a while, even if it hits the
cache, so instruction 2 can only execute some cycles after 1, and 3
one cycle after 2.
As a result, the iterations of the loop overlap, as in software
pipelining (but software pipelining is a complicated compiler
optimization).
The hardware can reuse physical registers when the corresponding
architectural value dies; for a stack architecture that would be when
the value is popped from the stack; for a register architecture it is
when the architectural register is overwritten by a new value.
- 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-29 10:45 -0400 |
| Message-ID | <oe28oq$2lt$1@dont-email.me> |
| In reply to | #58355 |
On 4/29/2017 9:48 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> On 4/27/2017 5:46 AM, Jan Coombs wrote: >>> 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? > > You would probably call it something else, but the basic mechanism is > similar: each new computed value is given a new physical > (microarchitectural) register, and the stack becomes only an > architectural way of describing the data flow to the > microarchitecture, just as the architectural registers on a register > machine are the architectural way to describe the data flow to the > microarchitecture. E.g., if you have several iterations of the loop > body > > dup @ 1+ over ! cell+ > > (let's ignore loop control for now.) > > Then the first loop iteration might be somthing like that to the data > flow engine > > 1 r100 = r99 @ > 2 r101 = r100+1 > 3 r101 r99 ! > 4 r102 = r99+cell > > The second iteration gets new physical registers, but otherwise the > computation is the same: > > 5 r103 = r102 @ > 6 r104 = r103+1 > 7 r104 r102 ! > 8 r105 = r102+cell > > The cool thing here is that instruction 1 and 4 can be executed right > away; since 4 takes only one cycle, in the next cycle we can already > start instrucions 5 (this requires assuming (and later verifying) that > the @ does not fetch from the same address as the ! in instruction 3) > and 8, and in the next cycle the corresponding instructions from the > next iteration. Instruction 1 takes a while, even if it hits the > cache, so instruction 2 can only execute some cycles after 1, and 3 > one cycle after 2. > > As a result, the iterations of the loop overlap, as in software > pipelining (but software pipelining is a complicated compiler > optimization). > > The hardware can reuse physical registers when the corresponding > architectural value dies; for a stack architecture that would be when > the value is popped from the stack; for a register architecture it is > when the architectural register is overwritten by a new value. You have left the stack model behind and are now using a register based design. I understand register renaming in the context of a register based machine. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-27 15:49 +0000 |
| Message-ID | <2017Apr27.174903@mips.complang.tuwien.ac.at> |
| In reply to | #58247 |
Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
>On Wed, 26 Apr 2017 20:34:49 -0700
>Paul Rubin <no.email@nospam.invalid> wrote:
>> 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.
I think that an OoO with register-renaming execution substrate like
that used in high-end Intel CPUs would do mostly ok when combined with
a stack architecture front end. But at that point, you have lost all
advantages that the stack architecture gives you. And if you
dogmatically stick with a pure stack machine (Chuck Moore didn't), you
have to use memory for storing temporary values in algorithms where
too much data is active at once (stuff that has traditionally been
written in assembly language); so you probably want to add some
registers or locals.
To see how that might work, you could translate your architecture
pretty directly to Intel code: Not quite as directly as machine Forth,
but by having a compiler that treats the register set as a stack
(well, actually, several stacks).
There is an interesting concept [kim&smith02] called dependence-based
scheduling where register-architecture code is implemented on a kind
of accumulator-machine substrate (with several sets of ALUs and
accumulators for parallel execution); this does not really work out
for register architectures [salverda&zilles07], but it might be more
appropriate for an accumulator or a stack-based architecture. You
would probably have several architectural accumulators or stacks to
allow having several computation strands that talk to each other or
extend across control flow.
Architecturally such a stack-based architecture might be similar to
Bernd Paysan's 4stack architecture, but the implementation would be
different. 4stack is implemented in a VLIW style (i.e., no OoO
execution).
>Where a stack machine is built entirely within an FPGA, all
>memories are equally (very) fast, then there is less need for
>these methods.
You mean, the logic is so slow that on-chip memory can keep up with
it. Yes, then you don't need caches (at least if you don't want to
access more memory than available on-chip). OoO and register renaming
helps also when memory is fast. E.g., our LaTeX benchmark
<https://www.complang.tuwien.ac.at/franz/latex-bench> runs mostly from
cache, and runs twice as fast on a 1650MHz AMD E-450 (low-end AMD
chip, dual-issue OoO) than on a 1600MHz Intel Atom N330 (low-end Intel
chip, dual-issue in-order).
>Is there anything else big lurking under your "etc"?
Multi-issue, branch prediction, store-to-load forwarding, and memory
disambiguation are some other things that play a big role in the
bigger CPUs, and there are a number of other techniques that help
(probably including some that are not public).
@InProceedings{kim&smith02,
author = {Ho-Seop Kim and James E. Smith},
title = {An Instruction Set and Microarchitecture for
Instruction Level Distributed Processing},
crossref = {isca02},
pages = {71--81},
url = {http://www.ece.wisc.edu/~hskim/papers/kimh_ildp.pdf},
annote = {This paper addresses the problems of wide
superscalars with communication across the chip and
the number of write ports in the register file. The
authors propose an architecture (ILDP) with
general-purpose registers and with accumulators
(with instructions only accessing one accumulator
(read and/or write) and one register (read or
write); for the accumulators their death is
specified explicitly in the instructions. The
microarchitecture builds \emph{strands} from
instructions working on an accumulator; a strand
starts with an instruction writing to an accumulator
without reading from it, continues with instructions
reading from (and possibly writing to) the
accumulator and ends with an instruction that kills
the accumulator. Strands are allocated to one out of
eight processing elements (PEs) dynamically (i.e.,
accumulators are renamed). A PE consists of
mainly one ALU data path (but also a copy of the
GPRs and an L1 cache). They evaluated this
architecture by translating Alpha binaries into it,
and comparing their architecture to a 4-wide or
8-wide Alpha implementation; their architecture has
a lower L1 cache latency, though. The performance of
ILDP in clock cycles is competetive, and one can
expect faster clocks for ILDP. The paper also
presents data for other stuff, e.g. general-purpose
register writes, which have to be promoted between
strands and which are relatively few.}
}
@Proceedings{isca02,
title = "$29^\textit{th}$ Annual International Symposium on Computer Architecture",
booktitle = "$29^\textit{th}$ Annual International Symposium on Computer Architecture",
year = "2002",
key = "ISCA 29",
}
@InProceedings{salverda&zilles07,
author = {Pierre Salverda and Craig Zilles},
title = {Dependence-Based Scheduling Revisited: A Tale of Two
Baselines},
booktitle = {Sixth Annual Workshop on Duplicating, Deconstructing, and Debunking (WDDD 2007)},
year = {2007},
url = {http://www.ece.wisc.edu/~wddd/2007/papers/wddd_01.pdf},
url2 = {http://www-sal.cs.uiuc.edu/~zilles/papers/lanes.wddd-2007.pdf},
annote = {When the authors simulated the dependence-based
scheduling work by Palacharla, Kim, and Smith, they
found 30\% lower IPC than a conventional OoO
machine, whereas the original simulations only found
a 5\% lower IPC. The paper analyses the reasons for
this, and provides a number of insights into how
hardware schedulers, execution engines, and various
features in them interact, and why and how
dependence-based scheduling works. The authors'
simulation had a number of significant differences
from the simulation in the original work: it used a
memory disambiguator, 2-cycle load latency (instead
of 1-cycle), and a better branch predictor. These
changes increase the number of strands available at
the same time, and the 8-lane dependence-based
machine becomes lane-limited (and instruction fetch
stalls waiting for a free lane), so it cannot profit
from the improvements or work around the higher
latency, whereas a conventional OoO machine can. 24
lanes would be required to bring the IPC
disadvantage of the dependence-based machine down to
5\% on the authors' simulator. OTOH, by changing
these parts of their simulation to be like the
original work, the dependence-based scheduling only
had an 11\% IPC disadvantage on an 8-lane machine
(much closer to the original 5\%)}
}
- 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-29 00:27 +0100 |
| Message-ID | <20170429002752.5e5e079d@t530.lan> |
| In reply to | #58279 |
On Thu, 27 Apr 2017 15:49:03 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes: > >On Wed, 26 Apr 2017 20:34:49 -0700 > >Paul Rubin <no.email@nospam.invalid> wrote: > >> 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. > > I think that an OoO with register-renaming execution substrate > like that used in high-end Intel CPUs would do mostly ok when > combined with a stack architecture front end. But at that > point, you have lost all advantages that the stack > architecture gives you. I'm using a very small FPGA, and have a series of goals which each require support for a variable length data type. This limits me to a programming model where only a few items near the top of data stack (in cache) can be re-ordered. Because call and branch address calculation may take a few cycles, these can run in parallel with other instructions, but this is all for now. > And if you dogmatically stick with a > pure stack machine (Chuck Moore didn't), you have to use > memory for storing temporary values in algorithms where too > much data is active at once (stuff that has traditionally been > written in assembly language); so you probably want to add > some registers or locals. Is it the address registers A, B, TOR that Chuck added you are referring to? I would like to extend these into a MMU system with a relatively unrestricted number of concurrent mappings. > To see how that might work, you could translate your > architecture pretty directly to Intel code: Not quite as > directly as machine Forth, but by having a compiler that > treats the register set as a stack (well, actually, several > stacks). It's much too late to get me doing proper software modelling now my hardware source code is almost complete. > >Where a stack machine is built entirely within an FPGA, all > >memories are equally (very) fast, then there is less need for > >these methods. > > You mean, the logic is so slow that on-chip memory can keep up > with it. Yes, then you don't need caches (at least if you > don't want to access more memory than available on-chip). The tiny low-power FPGA I'm initially using will run memory blocks at 400MHz, so the critical logic needs to be simple enough to also meet this clock rate, and the rest will be pipelined. Because RAM is limited, most code will be stored in external serial Flash. This runs at 1/3 processor clock rate, and has a latency of 8 cycles. A code cache is needed to reduce stalls on nest and un-nest, also to run tight loops with no stalls. Thanks for the detailed comments and help, Jan Coombs -- > - 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-28 20:28 -0400 |
| Message-ID | <oe0mgr$aqo$1@dont-email.me> |
| In reply to | #58317 |
On 4/28/2017 7:27 PM, Jan Coombs wrote: > > It's much too late to get me doing proper software modelling now > my hardware source code is almost complete. I would certainly be interested in seeing it. Have you been doing any synthesis to check timing numbers? > The tiny low-power FPGA I'm initially using will run memory > blocks at 400MHz, so the critical logic needs to be simple > enough to also meet this clock rate, and the rest will be > pipelined. I believe you are describing the ICE40HX line of FPGAs. While the RAM will clock at 400 MHz, that does not mean you will be able to run any sort of logic with it at that speed without enormous amounts of effort in not just pipelining, but placing entities in the device. 400 MHz is a theoretical max speed under perfect conditions which are very hard to duplicate in a real design. Better to look at the timing for basic functions which are a bit over 200 MHz for adders and counters. That includes no control logic of any kind. I expect you will need to put a lot of effort into a CPU design to even get 200 MHz operation. It is not an easy thing to pipeline a real design with balanced delays across the design. > Because RAM is limited, most code will be stored in external > serial Flash. This runs at 1/3 processor clock rate, and has a > latency of 8 cycles. A code cache is needed to reduce stalls on > nest and un-nest, also to run tight loops with no stalls. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-29 14:15 +0000 |
| Message-ID | <2017Apr29.161540@mips.complang.tuwien.ac.at> |
| In reply to | #58317 |
Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
>On Thu, 27 Apr 2017 15:49:03 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> And if you dogmatically stick with a
>> pure stack machine (Chuck Moore didn't), you have to use
>> memory for storing temporary values in algorithms where too
>> much data is active at once (stuff that has traditionally been
>> written in assembly language); so you probably want to add
>> some registers or locals.
>
>Is it the address registers A, B, TOR that Chuck added you are
>referring to?
Yes, that's what I meant.
- 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-05-01 13:45 +0100 |
| Subject | Stack processor address regs . was Ting's EP32 32 Bit Processor |
| Message-ID | <20170501134533.4d17ca9c@t530.lan> |
| In reply to | #58356 |
On Sat, 29 Apr 2017 14:15:40 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes: > >On Thu, 27 Apr 2017 15:49:03 GMT > >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> And if you dogmatically stick with a > >> pure stack machine (Chuck Moore didn't), you have to use > >> memory for storing temporary values in algorithms where too > >> much data is active at once (stuff that has traditionally > >> been written in assembly language); so you probably want to > >> add some registers or locals. > > > >Is it the address registers A, B, TOR that Chuck added you are > >referring to? > > Yes, that's what I meant. This direction could progress further by moving all rarely changing data from the processor core to a token driven memory access controller with combined MMU. A load or store instruction would then just supply the access token and any dynamic base, or offset, or index to the memory access method+MMU control hardware. Rarely changing access parameters such as BASE, record-OFFSET, arrayElementSPAN, post-increment, pre-decrement or others would be stored in the mapping once for that data access mapping. There would seem to be three gains: 1. Reduce code size by using simpler opcodes. 2. Remove address computation from the prime data path. 3. Reduce the address stream between processor and MMU. Is there any information that shows how many concurrent mappings are commonly used? Jan Coombs --
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-02 13:15 +0000 |
| Subject | Re: Stack processor address regs . was Ting's EP32 32 Bit Processor |
| Message-ID | <2017May2.151517@mips.complang.tuwien.ac.at> |
| In reply to | #58441 |
Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> writes:
>Is there any information that shows how many concurrent mappings
>are commonly used?
It's unclear to me what you mean with "mappings", but you can look at
the numbers for various hardware features:
E.g., an Intel Haswell has 4 TLB entries for 1GB pages (probably
intended for I/O ranges), 32 DTLB L1 entries, 1024 DTLB L2 entries
(each for 4KB or 2MB pages).
The 286 and IA-32 have support for 8192 segments, with 4 (286) or 6
(IA-32) segment registers for (software-controlled) "caching" of
segment data. Few people made use of this feature on IA-32, and from
what I read they found segment register handling to be too slow (or
conversely, too frequently necessary); I guess the frequency is only
in part due to their low numbers, but also due to the software
control.
My laptop currently has 289 processes shown with "ps aux". Together
they have 31191 mappings ("cat /proc/[1-9]*/maps|wc -l"), i.e., a
little over 100 on average per process, with up to 1051 mappings per
process (for compiz; wc -l /proc/[1-9]*/maps|sort -n).
- 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 | jim.brakefield@ieee.org |
|---|---|
| Date | 2017-04-28 18:20 -0700 |
| Message-ID | <d9aa4b44-dc1e-48f1-b885-7be08743e7d5@googlegroups.com> |
| In reply to | #58221 |
On Wednesday, April 26, 2017 at 10:34:53 PM UTC-5, 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. One thing that would help stack machines in lieu of register renaming etc. is not requiring dense stacks. E.g., Temporaries left in place on the stack until subroutine return. Requires TOS offset addressing of the stack. Assumes stack kept/cached in FPGA register file. Then stack machines might have an advantage over RISC due to faster subroutine call/return. Jim Brakefield
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-04-29 13:00 +0200 |
| Message-ID | <1cuqvoilgcha4$.uk2s2ctlefc1$.dlg@40tude.net> |
| In reply to | #58321 |
Op Fri, 28 Apr 2017 18:20:57 -0700 (PDT) schreef jim.brakefield@ieee.org: > Temporaries left in place on the stack until subroutine return. You know that Forth has two stacks? Items may be left on the data stack and are not touched by call/return. Addresses for calls and returns use the other stack: the return stack. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-04-29 11:47 +0000 |
| Message-ID | <xn0kpb37531kjw700f@nntp.aioe.org> |
| In reply to | #58343 |
Coos Haak wrote: > Op Fri, 28 Apr 2017 18:20:57 -0700 (PDT) schreef > jim.brakefield@ieee.org: > > > Temporaries left in place on the stack until subroutine return. > > You know that Forth has two stacks? Or more, right? Some could have a control stack, a string stack, etc. <g> -- Rudy Velthuis http://www.rvelthuis.de "Always do right- this will gratify some and astonish the rest." -- Mark Twain (1835-1910)
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-04-29 15:02 +0200 |
| Message-ID | <17xfu3v1kvgew$.1q06er4eibjje$.dlg@40tude.net> |
| In reply to | #58348 |
Op Sat, 29 Apr 2017 11:47:35 +0000 (UTC) schreef Rudy Velthuis: > Coos Haak wrote: > >> Op Fri, 28 Apr 2017 18:20:57 -0700 (PDT) schreef >> jim.brakefield@ieee.org: >> >>> Temporaries left in place on the stack until subroutine return. >> >> You know that Forth has two stacks? > > Or more, right? Some could have a control stack, a string stack, etc. > <g> Of course, I use a separate one for locals and have place for another one. But I made a remark that the data and return stack are separate in Forth. There is no need to remove parameters during call/return like as in C. groet Coos 1,86 m, still below average in the Netherlands.
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2017-04-30 18:32 -0700 |
| Message-ID | <16f24c74-e1a0-42de-8c96-9d6c4c72bd40@googlegroups.com> |
| In reply to | #58343 |
On Saturday, April 29, 2017 at 6:00:48 AM UTC-5, Coos Haak wrote: > Op Fri, 28 Apr 2017 18:20:57 -0700 (PDT) schreef jim.brakefield@ieee.org: > > > Temporaries left in place on the stack until subroutine return. > > You know that Forth has two stacks? > Items may be left on the data stack and are not touched by call/return. > Addresses for calls and returns use the other stack: the return stack. > > groet Coos ]> You know that Forth has two stacks? The return stack has many possible usages. The minimal usage seems to be just the return address and possibly a frame pointer for locals. It's a nice place for subroutine(word) parameters, then again, there are usually more parameters than results, so leaving parameters on the data stack is more efficient. Wish there was a simple way to translate between "pick" access to parameters, temporaries and locals and the swap/dup/rot/... access used in traditional Forth? Jim Brakefield
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-26 20:40 -0700 |
| Message-ID | <87a1e5ff-4127-4b90-a559-969120d187e7@googlegroups.com> |
| In reply to | #58215 |
On Wednesday, April 26, 2017 at 3:29:47 PM UTC-7, rickman wrote: > On 4/26/2017 5:51 PM, Ilya Tarasov wrote: > > Have you partners and certain names which can help you? I know > > exactly where to go with HDL code, how it must be prepared and what > > prices exist in silicon area. Please don't try to teach me, the fact > > you know something about HDL and FPGA don't mean you are an expert. Ilya is asking if Rick Collins has partners, and if these partners have names. Ilya is dubious that Rick Collins actually has a job --- maybe there are no "partners" --- maybe there is no money because the job and the partners are all a fantasy. > It's funny that you think everything is about you. I was expounding on > the topic for the benefit of others. If you feel slighted that I > assumed you didn't know something, I am sorry. Consider I was not > addressing you specifically. Rick Collins said that he wanted to burn Ilya Tarasov's house down --- it seems unsurprising that Ilya "feels slighted" or believes that he was being addressed specifically --- most people would take this personally. Now Rick Collins adopts the "voice of reason" to make it seem like he is perfectly reasonable --- everybody else is insane, or paranoid, or they think that everything is about them (megalomania) --- this is very similar to how, earlier, he said that he wanted to work with me on the Stundurd design, expecting me to take the bait, but I would have to forget about all the gross insults he has thrown at me (said that I was insane, homosexual, etc.).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-04-27 01:21 -0400 |
| Message-ID | <odruun$9tf$1@dont-email.me> |
| In reply to | #58222 |
On 4/26/2017 11:40 PM, hughaguilar96@gmail.com wrote: > On Wednesday, April 26, 2017 at 3:29:47 PM UTC-7, rickman wrote: >> On 4/26/2017 5:51 PM, Ilya Tarasov wrote: >>> Have you partners and certain names which can help you? I know >>> exactly where to go with HDL code, how it must be prepared and >>> what prices exist in silicon area. Please don't try to teach me, >>> the fact you know something about HDL and FPGA don't mean you are >>> an expert. > > Ilya is asking if Rick Collins has partners, and if these partners > have names. > > Ilya is dubious that Rick Collins actually has a job --- maybe there > are no "partners" --- maybe there is no money because the job and the > partners are all a fantasy. It is clearly you who is living in a fantasy. Hardly anything you have posted is based in reality. You make up things about people and then suggest that the people your fantasy is about are somehow responsible for your fantasy. >> It's funny that you think everything is about you. I was >> expounding on the topic for the benefit of others. If you feel >> slighted that I assumed you didn't know something, I am sorry. >> Consider I was not addressing you specifically. > > Rick Collins said that he wanted to burn Ilya Tarasov's house down > --- it seems unsurprising that Ilya "feels slighted" or believes that > he was being addressed specifically --- most people would take this > personally. More of your fantasy world. This is why I say you are insane. You can't separate your fantasies from reality. > Now Rick Collins adopts the "voice of reason" to make it seem like he > is perfectly reasonable --- everybody else is insane, or paranoid, or > they think that everything is about them (megalomania) --- this is > very similar to how, earlier, he said that he wanted to work with me > on the Stundurd design, expecting me to take the bait, but I would > have to forget about all the gross insults he has thrown at me (said > that I was insane, homosexual, etc.). No, everyone else is not insane... just the insane ones like you. I'm sorry if you consider this to be an insult. If you want me to apologize, I am sorry you are hurt by what I said. But I can't say it isn't the truth. What I said about working with you had nothing to do with insults, it has to do with you needing to not be insane or at least not acting insane. But I know you can't do that so I will never need to worry about working with you. BTW, I'm pretty sure I didn't say you were gay. I have no reason to say that about you other than the fact that you are extremely homophobic and in my experience those who are *very* homophobic are actually reacting to the self-loathing they feel rather than anything about actual gays. But it can go either way. You seem to hate so many people for such small reasons it is entirely possible that you don't hate gays because you hate being gay yourself, rather you just hate gays because you do what you do best, hate people. This is getting tiring. It would be better if I just didn't respond to you. But like many here, it is hard to resist replying to the crazies. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web