Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #46626 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2016-04-11 15:32 -0400 |
| Last post | 2016-05-21 22:32 -0400 |
| Articles | 20 on this page of 146 — 19 participants |
Back to article view | Back to comp.lang.forth
Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-11 15:32 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-14 08:10 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-14 12:43 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-14 17:33 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-14 21:09 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 04:38 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-15 11:55 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 10:24 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-15 14:07 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 mhx@iae.nl - 2016-04-15 10:56 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-15 14:33 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-18 17:59 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-19 03:50 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-22 00:33 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 04:27 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 06:30 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-18 21:47 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "HAA" <someone@microsoft.com> - 2016-04-21 01:27 +1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-20 21:12 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-20 15:54 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-20 19:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-21 17:13 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-21 22:26 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-22 11:35 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-22 14:47 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-22 12:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 01:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-23 15:11 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 18:50 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-23 16:01 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 22:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-23 21:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 01:58 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-24 00:53 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 12:08 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "Elizabeth D. Rather" <erather@forth.com> - 2016-04-24 14:59 -1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 22:15 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-24 20:05 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-24 20:24 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-25 18:41 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-30 08:39 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-30 13:17 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-02 11:17 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-02 16:31 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-02 16:50 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-02 16:49 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-03 09:06 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-03 10:20 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-03 14:36 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-03 14:44 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-03 16:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-03 16:28 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-03 13:37 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-05 02:56 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-05-05 23:56 +0100
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-06 08:42 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 13:00 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-06 13:56 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-07 03:48 -0500
Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-05-07 14:05 +0100
Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-07 08:34 -0500
Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 pahihu <pahihu@gmail.com> - 2016-05-08 12:22 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-04 00:10 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-04 00:34 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Walter Banks <walter@bytecraft.com> - 2016-05-06 12:20 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 13:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 11:30 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 15:23 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 12:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 12:56 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 17:04 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Walter Banks <walter@bytecraft.com> - 2016-05-06 17:38 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 15:01 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 18:58 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 19:09 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:14 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 19:17 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:24 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:20 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Walter Banks <walter@bytecraft.com> - 2016-05-06 17:36 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-07 13:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-07 14:57 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "Elizabeth D. Rather" <erather@forth.com> - 2016-05-03 10:58 -1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-03 21:35 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 23:04 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 03:12 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 22:41 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 01:55 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 23:21 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 03:21 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-24 08:40 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-24 08:34 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 12:16 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 22:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 03:29 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-25 19:03 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-26 05:04 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-26 10:42 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-26 15:12 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-26 16:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-26 21:10 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-27 01:18 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 09:44 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-27 09:48 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-28 23:23 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-26 05:05 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 stephen@mpeforth.com (Stephen Pelc) - 2016-04-23 12:10 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 08:05 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-23 13:01 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 18:36 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "HAA" <someone@microsoft.com> - 2016-04-23 21:33 +1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-22 09:47 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "WJ" <w_a_x_man@yahoo.com> - 2016-04-25 07:24 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 16:16 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-26 03:15 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-26 11:22 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-27 07:48 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 12:05 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-27 10:34 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 10:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 14:27 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 11:38 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 16:04 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 16:52 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 17:25 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-05-01 10:06 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-01 14:07 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-05-01 11:14 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 17:17 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-28 02:06 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-28 00:43 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-28 11:53 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-04-28 18:39 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-28 17:02 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-30 13:32 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-30 16:49 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-30 18:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-30 22:08 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-05-01 09:32 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-01 14:10 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 14:12 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Coos Haak <chforth@hccnet.nl> - 2016-04-27 23:45 +0200
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-29 07:17 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-16 18:48 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Cecil Bayona <cbayona@cbayona.com> - 2016-05-17 14:28 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-21 22:32 -0400
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-07 08:34 -0500 |
| Subject | Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 |
| Message-ID | <3aCdnSFYfpp_c7DKnZ2dnUU7-f3NnZ2d@supernews.com> |
| In reply to | #46974 |
Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> wrote: > On Sat, 07 May 2016 03:48:31 -0500 > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> > >> > I don't think you can change the stack point on the RTX >> > other than by pushes and pops. Am I wrong about that? >> >> Yes. Register 09 is the stack pointer. It's a bit fiddly to >> use because bits 0-7 contain the data stack pointer, 8-15 the >> return stack pointer. > > Thanks, so only a few instructions to pick, fancy trying roll? Execution time would have been linear in the depth parameter, I guess. n TIMES >R MD I! n TIMES R> . MD I@ > Took took a while to find, the full ASIC register list and > details are here > > http://netwinder.oregonstate.edu/devteam/andrewm/forth/strongarm/docs/rtx2010.pdf Yeah, that's just the datasheet. I've got the programmer's reference manual on paper here, but I don't know if that's been scaneed on the web. Thinking about it some more, on RTX I think you'd have to be very careful if an interrupt occurred while the stack pointer was adjusted during PICK . That wasn't much of a problem with Novix, which had very flaky interrupt behaviour so most people didn't use interrupts at all. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2016-05-08 12:22 -0700 |
| Subject | Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 |
| Message-ID | <c64e3009-0e27-48a3-aebc-5f36ace61077@googlegroups.com> |
| In reply to | #46975 |
2016. május 7., szombat 15:34:28 UTC+2 időpontban Andrew Haley a következőt > > http://netwinder.oregonstate.edu/devteam/andrewm/forth/strongarm/docs/rtx2010.pdf > > Yeah, that's just the datasheet. I've got the programmer's reference > manual on paper here, but I don't know if that's been scaneed on the > web. > Nope, the RTX2010 PM cannot be found on the web. RTX2000 PM is/was available. The RTX2010 datasheet references several times the PM for clarification though... pahihu
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-04 00:10 -0700 |
| Message-ID | <f1ab54fe-55fb-4d18-bb58-5bc9e08da00c@googlegroups.com> |
| In reply to | #46901 |
On Tuesday, May 3, 2016 at 11:36:14 AM UTC-7, Mike Mellen wrote: > The same reasoning led to the Harris C compiler - customers comfortable > with C. I left Harris soon after the C compiler was released, so I don't > know how much it was used compared to the Forth compiler (or the > customers' own self-produced Forth compilers). After I finished MFX (the Forth cross-compiler, assembler and simulator) I was asked to write a C compiler for the MiniForth. I said that I needed local variables, so the MiniForth was upgraded to provide 16 16-bit global variables that had significantly faster access than regular globals. I wrote some code to provide MFX with local variables in these globals. At the beginning of a function, there was code to push the locals that the function would use onto the return-stack, then the locals were loaded, and at the end of the function there was code to pull the locals from the return-stack to restore the caller's locals. This system was modeled after the C compiler for the 8051 that uses global variables in the zero-page as locals (both the MiniForth and the 8051 lack indexed addressing). The problem is that you can't take the address of a local variable and pass it into a sub-function, so those 8051 C compilers aren't really standard C, and mine wouldn't be either. I wrote quite a lot of code to meta-compile ghost primitives that used local variables. I never did write the C compiler though. I was planning on using LCC (I had the book). The problem was that quite a lot of work would be needed to modify LCC to generate Forth code. Testra seemed to expect the C compiler to be done quickly. They weren't willing to pay me to learn how LCC works, but they expected me to begin work right away on modifying LCC. I just quit. The whole C compiler thing was over my head --- I might have figured out LCC given some time --- I wasn't really interested though, so I just moved on. I hadn't gotten a raise after finishing MFX, and I wasn't getting health insurance (that is why I had to give up skiing and snow-boarding), so I wasn't enthusiastic about continuing especially if learning LCC was mostly going to be on my own time --- also, I was very dubious that I could write a C compiler that would generate efficient code on the MiniForth as compared to the C compilers for the mainstream processors (the MC6812 etc.), so I considered the C compiler to be a fool's errand. It is hard to get enthusiastic when you know that your only possible future is to have a million C programmers tell you that C on the MiniForth sucks as compared to C on the mainstream processors. This is similar to how all the x86 enthusiasts said that the PowerPC sucked at running x86 machine-code (the PowerPC could emulate 32-bit x86 machine-code faster than the 80486 could run it, but it got beat by the Pentium). I knew that nobody would ever use the MiniForth outside of Testra, and that the motion-control program would most likely be the only program ever written for the MiniForth --- afaik, the motion-control program is still the only program that the RACE (formerly known as MiniForth) is used for, although they did sell those motion-control boards for over 20 years now and continue to do so today. I still don't know how to write a C compiler --- Testra doesn't either, as they never did get a C compiler for the RACE --- afaik, they never hired anybody to replace me after I left, but they just kept the motion-control program going themselves forever.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-04 00:34 -0700 |
| Message-ID | <a296c46f-e000-4702-9da0-2d2510d75c47@googlegroups.com> |
| In reply to | #46910 |
On Wednesday, May 4, 2016 at 12:10:49 AM UTC-7, hughag...@gmail.com wrote: > After I finished MFX (the Forth cross-compiler, assembler and simulator) I was asked to write a C compiler for the MiniForth. I said that I needed local variables, so the MiniForth was upgraded to provide 16 16-bit global variables that had significantly faster access than regular globals. I wrote some code to provide MFX with local variables in these globals. At the beginning of a function, there was code to push the locals that the function would use onto the return-stack, then the locals were loaded, and at the end of the function there was code to pull the locals from the return-stack to restore the caller's locals. This system was modeled after the C compiler for the 8051 that uses global variables in the zero-page as locals (both the MiniForth and the 8051 lack indexed addressing). The problem is that you can't take the address of a local variable and pass it into a sub-function, so those 8051 C compilers aren't really standard C, and mine wouldn't be either. You could have done something similar on the RTX2000. You have those short literals that provide a literal in the range [0,31]. You could dedicate the lower 32 bytes to 16 16-bit globals that are faster than usual, and use these as local variables.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-05-06 12:20 -0400 |
| Message-ID | <ngig7i$v0n$1@gioia.aioe.org> |
| In reply to | #46910 |
On 2016-05-04 3:10 AM, hughaguilar96@gmail.com wrote: > On Tuesday, May 3, 2016 at 11:36:14 AM UTC-7, Mike Mellen wrote: >> The same reasoning led to the Harris C compiler - customers >> comfortable with C. I left Harris soon after the C compiler was >> released, so I don't know how much it was used compared to the >> Forth compiler (or the customers' own self-produced Forth >> compilers). > > After I finished MFX (the Forth cross-compiler, assembler and > simulator) I was asked to write a C compiler for the MiniForth. I > said that I needed local variables, so the MiniForth was upgraded to > provide 16 16-bit global variables that had significantly faster > access than regular globals. I wrote some code to provide MFX with > local variables in these globals. At the beginning of a function, > there was code to push the locals that the function would use onto > the return-stack, then the locals were loaded, and at the end of the > function there was code to pull the locals from the return-stack to > restore the caller's locals. This system was modeled after the C > compiler for the 8051 that uses global variables in the zero-page as > locals (both the MiniForth and the 8051 lack indexed addressing). The > problem is that you can't take the address of a local variable and > pass it into a sub-function, so those 8051 C compilers aren't really > standard C, and mine wouldn't be either. > > I wrote quite a lot of code to meta-compile ghost primitives that > used local variables. I never did write the C compiler though. I was > planning on using LCC (I had the book). The problem was that quite a > lot of work would be needed to modify LCC to generate Forth code. > Testra seemed to expect the C compiler to be done quickly. They > weren't willing to pay me to learn how LCC works, but they expected > me to begin work right away on modifying LCC. I just quit. The whole > C compiler thing was over my head --- I might have figured out LCC > given some time --- I wasn't really interested though, so I just > moved on. I hadn't gotten a raise after finishing MFX, and I wasn't > getting health insurance (that is why I had to give up skiing and > snow-boarding), so I wasn't enthusiastic about continuing especially > if learning LCC was mostly going to be on my own time --- also, I was > very dubious that I could write a C compiler that would generate > efficient code on the MiniForth as compared to the C compilers for > the mainstream processors (the MC6812 etc.), so I considered the C > compiler to be a fool's errand. It is hard to get enthusiastic when > you know that your only possible future is to have a million C > programmers tell you that C on the MiniForth sucks as compared to C > on the mainstream processors. This is similar to how all the x86 > enthusiasts said that the PowerPC sucked at running x86 machine-code > (the PowerPC could emulate 32-bit x86 machine-code faster than the > 80486 could run it, but it got beat by the Pentium). > > I knew that nobody would ever use the MiniForth outside of Testra, > and that the motion-control program would most likely be the only > program ever written for the MiniForth --- afaik, the motion-control > program is still the only program that the RACE (formerly known as > MiniForth) is used for, although they did sell those motion-control > boards for over 20 years now and continue to do so today. > > I still don't know how to write a C compiler --- Testra doesn't > either, as they never did get a C compiler for the RACE --- afaik, > they never hired anybody to replace me after I left, but they just > kept the motion-control program going themselves forever. > About 20 years ago we did an internal project to re target our C compiler to forth. Most of what we have done has been embedded system related. We handled locals the same way we did with small processors using a compiled stack. For embedded systems recursion is rare very rare. I have seen three actual embedded systems programs in the last 25 years or so that actually needed recursion most cases recursion is optimized away with by the compiler. Compiled stacks allocate locals in global space and optimizes variable reuse in the compiler. This results in the same ram requirements but frees up direct access to locals significantly speeding up execution. I haven't looked at the approaches used by other C to forth compilers. w..
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-06 13:03 -0400 |
| Message-ID | <ngiiir$eli$1@dont-email.me> |
| In reply to | #46939 |
On 5/6/2016 12:20 PM, Walter Banks wrote: > > About 20 years ago we did an internal project to re target our C > compiler to forth. Most of what we have done has been embedded system > related. We handled locals the same way we did with small processors > using a compiled stack. > > For embedded systems recursion is rare very rare. I have seen three > actual embedded systems programs in the last 25 years or so that > actually needed recursion most cases recursion is optimized away with by > the compiler. Compiled stacks allocate locals in global space and > optimizes variable reuse in the compiler. This results in the same ram > requirements but frees up direct access to locals significantly speeding > up execution. > > I haven't looked at the approaches used by other C to forth compilers. I guess I'm showing my ignorance, but what does it mean, a C to Forth compiler? Does it read C and spit out Forth? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-06 11:30 -0700 |
| Message-ID | <874mabca4z.fsf@nightsong.com> |
| In reply to | #46944 |
rickman <gnuarm@gmail.com> writes: >> I haven't looked at the approaches used by other C to forth compilers. > I guess I'm showing my ignorance, but what does it mean, a C to Forth > compiler? Does it read C and spit out Forth? That's what I'd expect. There's one on the VFX site. It uses PICK all over the place to get at the C locals. I don't remember if it also has a way to modify them (POKE or whatever), which would seem even more un-Forth than PICK already is.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-06 15:23 -0400 |
| Message-ID | <ngiqp0$eim$1@dont-email.me> |
| In reply to | #46947 |
On 5/6/2016 2:30 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> I haven't looked at the approaches used by other C to forth compilers. >> I guess I'm showing my ignorance, but what does it mean, a C to Forth >> compiler? Does it read C and spit out Forth? > > That's what I'd expect. There's one on the VFX site. It uses PICK all > over the place to get at the C locals. I don't remember if it also has > a way to modify them (POKE or whatever), which would seem even more > un-Forth than PICK already is. A stack is not a stack frame. I would think the C stack should be implemented in memory like it is with other CPUs. PICK and POKE is a poor way to do this... I guess. Certainly it won't work well on machines where the stack is not addressable. MPE has a C library interface now. Better to just compile the C code to machine code and directly link from Forth I think. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-06 12:51 -0700 |
| Message-ID | <87wpn7artg.fsf@nightsong.com> |
| In reply to | #46948 |
rickman <gnuarm@gmail.com> writes: > I would think the C stack should be implemented in memory like it is > with other CPUs. PICK and POKE is a poor way to do this... I guess. You're talking to the wrong guy--I didn't write that compiler ;-). > MPE has a C library interface now. Better to just compile the C code > to machine code and directly link from Forth I think. The compiler is described as a research project and I don't know if it's actively developed these days. See http://mpeforth.com/arena.htm way at the end of the page.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-06 12:56 -0700 |
| Message-ID | <87shxvarkn.fsf@nightsong.com> |
| In reply to | #46949 |
Paul Rubin <no.email@nospam.invalid> writes: >> PICK and POKE is a poor way to do this... I guess. > You're talking to the wrong guy--I didn't write that compiler ;-). Actually, maybe I mis-remembered. Looking at the 1.20 docs it appears that it simply relies on Forth locals to implement C locals. I had remembered seeing PICK but this sort of amounts to the same thing. What I had been hoping to see was translation into actual stack code to the extent possible. That is a messy problem and Koopman's book and the Chlorophyll papers talk about it.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-06 17:04 -0400 |
| Message-ID | <ngj0m8$51b$1@dont-email.me> |
| In reply to | #46950 |
On 5/6/2016 3:56 PM, Paul Rubin wrote: > Paul Rubin <no.email@nospam.invalid> writes: >>> PICK and POKE is a poor way to do this... I guess. >> You're talking to the wrong guy--I didn't write that compiler ;-). > > Actually, maybe I mis-remembered. Looking at the 1.20 docs it appears > that it simply relies on Forth locals to implement C locals. I had > remembered seeing PICK but this sort of amounts to the same thing. What > I had been hoping to see was translation into actual stack code to the > extent possible. That is a messy problem and Koopman's book and the > Chlorophyll papers talk about it. There is a soft CPU called ZPU which is actually a stack based machine. It is notable because it was designed to implement C. Funny, I recall discussing this CPU when it was still in its early days and there was a block diagram. Now I can't find any sign of the block diagram. But the CPU seems to get used here and there including professional use. I remember the author mentioned was a PITA it was to generate code for a stack machine. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-05-06 17:38 -0400 |
| Message-ID | <ngj2rm$1veu$2@gioia.aioe.org> |
| In reply to | #46952 |
On 2016-05-06 5:04 PM, rickman wrote: > > I remember the author mentioned was a PITA it was to generate code > for a stack machine. > I have written C backend's to target stack machines. It isn't that bad. Modern C compilers doing strategy passes to plan code organization in later passes can generate some really compact fast code. w..
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-06 15:01 -0700 |
| Message-ID | <87oa8ic0cj.fsf@nightsong.com> |
| In reply to | #46952 |
rickman <gnuarm@gmail.com> writes: > There is a soft CPU called ZPU which is actually a stack based > machine. It is notable because it was designed to implement C. Funny, > I recall discussing this CPU when it was still in its early days and > there was a block diagram. Now I can't find any sign of the block > diagram. But the CPU seems to get used here and there including > professional use. I can't make much sense of the HDL, but I get the impression that the stack is in ordinary memory: https://github.com/zylin/zpu/blob/master/zpu/hdl/zpu4/core/zpu_core.vhd so you can in principle get at the stack interior using memory instructions, relative to the spoffset register (if that's accessible). Also it was intended as a tiny sequencer without much regard for runtime efficiency, so if doing stuff like that burns extra cycles they might not have cared.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-06 18:58 -0400 |
| Message-ID | <ngj7bd$ta5$1@dont-email.me> |
| In reply to | #46955 |
On 5/6/2016 6:01 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> There is a soft CPU called ZPU which is actually a stack based >> machine. It is notable because it was designed to implement C. Funny, >> I recall discussing this CPU when it was still in its early days and >> there was a block diagram. Now I can't find any sign of the block >> diagram. But the CPU seems to get used here and there including >> professional use. > > I can't make much sense of the HDL, but I get the impression that the > stack is in ordinary memory: > > https://github.com/zylin/zpu/blob/master/zpu/hdl/zpu4/core/zpu_core.vhd It has been too long to remember for sure. I thought there was an internal stack used in place of registers and an external stack used for the C stack frame. I know there was a diagram, but maybe *I* had drawn that to help me visualize the structure. I do remember it is *very* basic with as few as possible data paths and connections. Highly compacted and time multiplexed. I'd have to go through the code to figure this out again for sure. > so you can in principle get at the stack interior using memory > instructions, relative to the spoffset register (if that's accessible). > > Also it was intended as a tiny sequencer without much regard for runtime > efficiency, so if doing stuff like that burns extra cycles they might > not have cared. The intent was to design an instruction set that could be implemented as small as possible while allowing speed optimized versions as well, the whole thing supported by a C compiler. The applications are your decision. The implementations I have seen so far don't run very fast because of the basic structure of the instruction set. I'm not so impressed, but then that doesn't mean much. People use it, so that says a lot. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-06 19:09 -0400 |
| Message-ID | <ngj7vv$v1s$1@dont-email.me> |
| In reply to | #46956 |
On 5/6/2016 6:58 PM, rickman wrote: > On 5/6/2016 6:01 PM, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>> There is a soft CPU called ZPU which is actually a stack based >>> machine. It is notable because it was designed to implement C. Funny, >>> I recall discussing this CPU when it was still in its early days and >>> there was a block diagram. Now I can't find any sign of the block >>> diagram. But the CPU seems to get used here and there including >>> professional use. >> >> I can't make much sense of the HDL, but I get the impression that the >> stack is in ordinary memory: >> >> >> https://github.com/zylin/zpu/blob/master/zpu/hdl/zpu4/core/zpu_core.vhd > > It has been too long to remember for sure. I thought there was an > internal stack used in place of registers and an external stack used for > the C stack frame. I know there was a diagram, but maybe *I* had drawn > that to help me visualize the structure. I do remember it is *very* > basic with as few as possible data paths and connections. Highly > compacted and time multiplexed. > > I'd have to go through the code to figure this out again for sure. > > >> so you can in principle get at the stack interior using memory >> instructions, relative to the spoffset register (if that's accessible). >> >> Also it was intended as a tiny sequencer without much regard for runtime >> efficiency, so if doing stuff like that burns extra cycles they might >> not have cared. > > The intent was to design an instruction set that could be implemented as > small as possible while allowing speed optimized versions as well, the > whole thing supported by a C compiler. The applications are your decision. > > The implementations I have seen so far don't run very fast because of > the basic structure of the instruction set. I'm not so impressed, but > then that doesn't mean much. People use it, so that says a lot. I was trying to look at the docs and found this page. But I can't get it to display in the browser as a web page, rather it shows me the source as if it were a text file. https://raw.githubusercontent.com/zylin/zpu/master/zpu/docs/zpu_arch.html How do I view this as a web page? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-06 16:14 -0700 |
| Message-ID | <87k2j6bwys.fsf@nightsong.com> |
| In reply to | #46957 |
rickman <gnuarm@gmail.com> writes:
> https://raw.githubusercontent.com/zylin/zpu/master/zpu/docs/zpu_arch.html
> How do I view this as a web page?
Save it to a disk file, then point the browser at it:
file://saved_filename.html
The file:// instead of https:// makes the browser read from your local
disk instead of over the network.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-06 19:17 -0400 |
| Message-ID | <ngj8fu$117$1@dont-email.me> |
| In reply to | #46958 |
On 5/6/2016 7:14 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> https://raw.githubusercontent.com/zylin/zpu/master/zpu/docs/zpu_arch.html >> How do I view this as a web page? > > Save it to a disk file, then point the browser at it: > > file://saved_filename.html > > The file:// instead of https:// makes the browser read from your local > disk instead of over the network. Then the illustrations don't show. I'm not going to go searching for the images. I figured there was something I was missing. If it has to be downloaded locally to view, there is something *they* are missing. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-06 16:24 -0700 |
| Message-ID | <87bn4ibwi9.fsf@nightsong.com> |
| In reply to | #46959 |
rickman <gnuarm@gmail.com> writes: > Then the illustrations don't show. I'm not going to go searching for > the images. I figured there was something I was missing. Oh yes, it looks like it does try to transclude some images, and I don't know where they are either. But the instruction set table seemed like enough to understand how to program the thing. The HDL also doesn't seem that impenetrable even for someone like me who doesn't know HDL. But I didn't try very hard to puzzle it out. > If it has to be downloaded locally to view, there is something *they* > are missing. It means they sent the wrong content-transfer-encoding header. There are various ways around it, downloading being pretty simple.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-06 16:20 -0700 |
| Message-ID | <87futubwoq.fsf@nightsong.com> |
| In reply to | #46957 |
rickman <gnuarm@gmail.com> writes: > https://raw.githubusercontent.com/zylin/zpu/master/zpu/docs/zpu_arch.html > How do I view this as a web page? Alternatively in Windows, just save it to your desktop, then double click on the desktop icon. Looking at it, it seems to me that the STORESP, LOADSP, and ADDSP instructions let you implement PICK and PICK ADD. POKE would be done with PUSHSPADD and STORE.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-05-06 17:36 -0400 |
| Message-ID | <ngj2oj$1veu$1@gioia.aioe.org> |
| In reply to | #46944 |
On 2016-05-06 1:03 PM, rickman wrote: > On 5/6/2016 12:20 PM, Walter Banks wrote: >> >> About 20 years ago we did an internal project to re target our C >> compiler to forth. Most of what we have done has been embedded >> system related. We handled locals the same way we did with small >> processors using a compiled stack. >> >> For embedded systems recursion is rare very rare. I have seen >> three actual embedded systems programs in the last 25 years or so >> that actually needed recursion most cases recursion is optimized >> away with by the compiler. Compiled stacks allocate locals in >> global space and optimizes variable reuse in the compiler. This >> results in the same ram requirements but frees up direct access to >> locals significantly speeding up execution. >> >> I haven't looked at the approaches used by other C to forth >> compilers. > > I guess I'm showing my ignorance, but what does it mean, a C to > Forth compiler? Does it read C and spit out Forth? > We were looking at using forth as an intermediate compiled step as a possible way to create an easily ported C compiler to a new ISA. Kind of like the old stage2 approach. w..
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web