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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-04-30 08:39 -0700 |
| Message-ID | <12310190-e427-48a5-a6f2-b7166628948d@googlegroups.com> |
| In reply to | #46749 |
On Sunday, April 24, 2016 at 5:59:34 PM UTC-7, Elizabeth D. Rather wrote: > There was a > compiler (in fact, there were several compilers; Harris wrote one, as > did FORTH, Inc.). Why would Forth Inc. write a compiler for the RTX2000 except that Harris Semiconductor paid you to do it? Why would Harris Semiconductor write their own compiler except that the Forth Inc. compiler wasn't any good? In this thread you describe making a sale in France: https://groups.google.com/forum/#!searchin/comp.lang.forth/elizabeth$20france/comp.lang.forth/1y4khh5VZBc/_EQlo5a7XqcJ You call this a "good story" --- later on though, you cheerfully admit that your customer cancelled the contract because they weren't getting their money's worth. I suspect that the French bank does not consider this to be a "good story." In 1988 Forth Inc. was selling PolyForth for the 8088, and you failed to figure out how the segment registers worked so you put the entire thing (machine code, Forth code, data, dictionary) in a single 64KB segment. If you can't figure out how the 8088 works, then it seems unlikely that you could figure out how the RTX2000 works. I think you brag about jobs as if they were a success, but in truth you totally scammed the customer --- I doubt that anybody at Harris Semiconductor will say that your RTX2000 compiler was any good --- not a "good story" for them! After you kicked Charles Moore out of Forth Inc. he went on his own and designed the NC4016 processor. Harris Semiconductor bought the design and upgraded it to be the RTX2000 chip. Now, 28 years later, you are trying to take credit for the RTX2000 claiming that Forth Inc. was needed to write the compiler --- bullshit! --- as I said before, the reason why Forthers are interested in the RTX2000 is because it comes from the good old days before your ANS-Forth killed the Forth language. Lets take a look at how SwiftForth-v3 optimizes code compilation: : cell/ 4 / ; CELL/ isn't unique. ok see cell/ 478F7F EBX EAX MOV 8BC3 478F81 CDQ 99 478F82 4 # EBX MOV BB04000000 478F87 EBX IDIV F7FB 478F89 EAX EBX MOV 8BD8 478F8B RET C3 ok
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-30 13:17 -0400 |
| Message-ID | <ng2p44$i1k$1@dont-email.me> |
| In reply to | #46848 |
On 4/30/2016 11:39 AM, hughaguilar96@gmail.com wrote: > On Sunday, April 24, 2016 at 5:59:34 PM UTC-7, Elizabeth D. Rather > wrote: >> There was a compiler (in fact, there were several compilers; Harris >> wrote one, as did FORTH, Inc.). > > Why would Forth Inc. write a compiler for the RTX2000 except that > Harris Semiconductor paid you to do it? > > Why would Harris Semiconductor write their own compiler except that > the Forth Inc. compiler wasn't any good? I see you are on a tear again! You are so rabid you can't even get your facts straight. Who said Harris wrote a "Forth" compiler? I only find mention of a Harris "C" compiler. > In this thread you describe making a sale in France: > https://groups.google.com/forum/#!searchin/comp.lang.forth/elizabeth$20france/comp.lang.forth/1y4khh5VZBc/_EQlo5a7XqcJ > > You call this a "good story" --- later on though, you cheerfully > admit that your customer cancelled the contract because they weren't > getting their money's worth. I suspect that the French bank does not > consider this to be a "good story." You seem to have not read your own reference. "Subsequently, Datasaab decided that they didn't want to use proprietary software, and some Swedish programmers attempted to program the Datasaab devices using a FIG variant. This was unsuccessful (I don't know any of the details), and Forth was dropped." Where does it say a contract was canceled? The contract Forth, Inc had was with the BANK SNVB! Sounds to me like Datasaab management wanted to keep it in house so they attempted to duplicate the effort and failed. I will say this sounds like a condemnation of Forth in that Datasaab wasn't able to do the job using FIG Forth. I wonder what they did wrong. Maybe they tried to program like they were still using C. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mike Mellen <mmellen@intellikey.com> |
|---|---|
| Date | 2016-05-02 11:17 -0400 |
| Message-ID | <57276F7B.4090304@intellikey.com> |
| In reply to | #46848 |
On 4/30/2016 11:39 AM, hughaguilar96@gmail.com wrote: > > Why would Forth Inc. write a compiler for the RTX2000 except that Harris Semiconductor paid you to do it? > > Why would Harris Semiconductor write their own compiler except that the Forth Inc. compiler wasn't any good? Not that it really matters nearly 30 years later, but sometimes Hugh's rants go a little too far: I worked at Harris Semiconductor on the RTX project, so this is all firsthand information. I don't remember whether Harris approached Forth Inc about doing a polyForth for the RTX2000 or vice versa, but both companies were interested in pursuing the project. I was part of the team that met with Ms. Rather about their product. Forth Inc developed their compiler completely on their own. Other than some technical support and participation in the beta testing, Harris had no direct involvement in the polyForth development. Harris did produce a couple of Forth compilers. The first was part of a development kit that included a prototyping board and PC-based Forth cross-compiler. This was a result of the Marketing/Sales input that said that this was the type of support that customers "expected" for a microprocessor product. Harris also developed a native Forth compiler for the RTX, but I don't think it was ever released other than to a few select customers. Harris also provided an RTX C compiler. This was licensed from an outside vendor, but offered under the Harris name.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-02 16:31 -0400 |
| Message-ID | <ng8d8h$j5j$1@dont-email.me> |
| In reply to | #46869 |
On 5/2/2016 11:17 AM, Mike Mellen wrote: > > Not that it really matters nearly 30 years later, but sometimes Hugh's > rants go a little too far: Sometimes? > I worked at Harris Semiconductor on the RTX project, so this is all > firsthand information. I don't remember whether Harris approached Forth > Inc about doing a polyForth for the RTX2000 or vice versa, but both > companies were interested in pursuing the project. I was part of the > team that met with Ms. Rather about their product. Forth Inc developed > their compiler completely on their own. Other than some technical > support and participation in the beta testing, Harris had no direct > involvement in the polyForth development. > > Harris did produce a couple of Forth compilers. The first was part of a > development kit that included a prototyping board and PC-based Forth > cross-compiler. This was a result of the Marketing/Sales input that said > that this was the type of support that customers "expected" for a > microprocessor product. Harris also developed a native Forth compiler > for the RTX, but I don't think it was ever released other than to a few > select customers. > > Harris also provided an RTX C compiler. This was licensed from an > outside vendor, but offered under the Harris name. Thanks for the clarifications. I like the RTX2000 design. I think if it were done in a modern process and a good assortment of peripherals were added it has potential for being a great MCU. But that market is crowded and it is hard to gain a foothold with a new product, so it is unlikely we will ever see that other than in an FPGA. ARMs seem to be ruling everywhere that isn't covered by the AVR based Arduino and the low power MSP430s. The AVRs are mostly popular because the processor doesn't matter so much and the development software is easy to use (I suppose, I haven't used it yet). The MSP430s only have a small edge in low power and are seeing ARMs capture more and more market share. TI themselves are providing new ARM MCUs intended to be a migration path from the MSP430. Even if a company brought out a modern version of the RTX2000, it would be a tough sell in today's market due to a number of competitive reasons that aren't all related to performance. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mike Mellen <mmellen@intellikey.com> |
|---|---|
| Date | 2016-05-02 16:50 -0400 |
| Message-ID | <5727BD92.5060403@intellikey.com> |
| In reply to | #46875 |
On 5/2/2016 4:31 PM, rickman wrote: > > I like the RTX2000 design. I think if it were done in a modern process > and a good assortment of peripherals were added it has potential for > being a great MCU. But that market is crowded and it is hard to gain a > foothold with a new product, so it is unlikely we will ever see that > other than in an FPGA. ARMs seem to be ruling everywhere that isn't > covered by the AVR based Arduino and the low power MSP430s. The AVRs > are mostly popular because the processor doesn't matter so much and the > development software is easy to use (I suppose, I haven't used it yet). > The MSP430s only have a small edge in low power and are seeing ARMs > capture more and more market share. TI themselves are providing new ARM > MCUs intended to be a migration path from the MSP430. > > Even if a company brought out a modern version of the RTX2000, it would > be a tough sell in today's market due to a number of competitive reasons > that aren't all related to performance. > The RTX was an interesting project, especially since it had to be done "under the radar" at Harris. Harris was working with Intel to develop a CMOS version of the 286, so that was their "official" processor chip. RTX started out as FORCE (Forth Optimized RISC Computing Engine). The idea was to offer customers a design package containing modules to build custom, application-specific microprocessors - an ALU, stack controllers, interrupt controller, RAM/Stack modules, etc. The FORCE name was dropped due to trademark conflicts with another company. One of the marketing guys was reading something about trains, and came up with the connection between express trains and speed. Thus the Real Time eXpress name came to be. The RTX2000 was a proof-of-concept product. Harris design engineers used the tools they were proposing to sell to customers to create an example processor that would satisfy a lot of customer's design needs, and it became a standard product for Harris. A second version, the RTX2010, came out a little later with a couple more DSP related features, such as a barrel shifter. Some work was done on a 32-bit RTX, based on Phil Koopman's WISC concept, but other than a few chips and development boards being built, I dont' think it ever became a product. Harris management was showing less and less interest in supporting the whole RTX product line, and further development work was suspended.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-02 16:49 -0700 |
| Message-ID | <06c7d0ce-3b8d-403d-bba7-56400721ea45@googlegroups.com> |
| In reply to | #46869 |
On Monday, May 2, 2016 at 8:17:17 AM UTC-7, Mike Mellen wrote: > On 4/30/2016 11:39 AM, hughaguilar96@gmail.com wrote: > > > > Why would Forth Inc. write a compiler for the RTX2000 except that Harris Semiconductor paid you to do it? > > > > Why would Harris Semiconductor write their own compiler except that the Forth Inc. compiler wasn't any good? > > Not that it really matters nearly 30 years later, but sometimes Hugh's > rants go a little too far: > > I worked at Harris Semiconductor on the RTX project, so this is all > firsthand information. I don't remember whether Harris approached Forth > Inc about doing a polyForth for the RTX2000 or vice versa, but both > companies were interested in pursuing the project. I was part of the > team that met with Ms. Rather about their product. Forth Inc developed > their compiler completely on their own. Other than some technical > support and participation in the beta testing, Harris had no direct > involvement in the polyForth development. > > Harris did produce a couple of Forth compilers. The first was part of a > development kit that included a prototyping board and PC-based Forth > cross-compiler. This was a result of the Marketing/Sales input that said > that this was the type of support that customers "expected" for a > microprocessor product. Harris also developed a native Forth compiler > for the RTX, but I don't think it was ever released other than to a few > select customers. > > Harris also provided an RTX C compiler. This was licensed from an > outside vendor, but offered under the Harris name. You never said in your post if Forth Inc.'s compiler was any good or not. Given the serious quality problems with PolyForth for the 16-bit x86 and SwiftForth for the 32-bit x86, it seems unlikely that PolyForth for the RTX2000 would not have the same quality problems. You did say that Harris Semiconductor wrote two compilers, one a cross-compiler (presumably the back-end to the C compiler) and the other a "native" Forth system (apparently this means a traditional Forth system that runs on the target board). Why did you do that if you already had PolyForth?
[toc] | [prev] | [next] | [standalone]
| From | Mike Mellen <mmellen@intellikey.com> |
|---|---|
| Date | 2016-05-03 09:06 -0400 |
| Message-ID | <5728A259.3070609@intellikey.com> |
| In reply to | #46884 |
On 5/2/2016 7:49 PM, hughaguilar96@gmail.com wrote: > You never said in your post if Forth Inc.'s compiler was any good or not. The early beta version that I worked with had no issues. It produced code very similar to that produced by Harris compilers written by people with intimate knowledge of the hardware. I guess I would have to say the polyForth compiler was "good". > You did say that Harris Semiconductor wrote two compilers, one a cross-compiler (presumably the back-end to the C compiler) and the other a "native" Forth system (apparently this means a traditional Forth system that runs on the target board). Why did you do that if you already had PolyForth? Harris marketing and sales people insisted that any Harris product had to have a lot of support available. They specified - based on their "vast" experience with Harris microprocessor customers - that The cross-compiler/prototyping board approach was the only way to go. Those components were developed well before the first chips were ready, and before any talks with Forth Inc. started. The native, run-on-the-target-system version was done because we, as Forth programmers, knew what the hard-core Forth customers would really want.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-03 10:20 -0400 |
| Message-ID | <ngabtd$3q3$1@dont-email.me> |
| In reply to | #46896 |
On 5/3/2016 9:06 AM, Mike Mellen wrote: > On 5/2/2016 7:49 PM, hughaguilar96@gmail.com wrote: > >> You never said in your post if Forth Inc.'s compiler was any good or not. > > The early beta version that I worked with had no issues. It produced > code very similar to that produced by Harris compilers written by people > with intimate knowledge of the hardware. I guess I would have to say the > polyForth compiler was "good". > > >> You did say that Harris Semiconductor wrote two compilers, one a >> cross-compiler (presumably the back-end to the C compiler) and the >> other a "native" Forth system (apparently this means a traditional >> Forth system that runs on the target board). Why did you do that if >> you already had PolyForth? > > Harris marketing and sales people insisted that any Harris product had > to have a lot of support available. They specified - based on their > "vast" experience with Harris microprocessor customers - that The > cross-compiler/prototyping board approach was the only way to go. Those > components were developed well before the first chips were ready, and > before any talks with Forth Inc. started. The native, > run-on-the-target-system version was done because we, as Forth > programmers, knew what the hard-core Forth customers would really want. I recall working for a company who designed the Transputer into a system they developed for the government. There was one person who was a proponent of the Transputer and was able to show advantages for this application (the days of the 68020 and VME otherwise). The language choices were Occam or C and I believe there was no way in hell anyone was going to convince the programming team they needed to use Occam. I expect for many RTX customers using Forth was a similar issue and the C compiler was required if the chip would be used much. Do you have any idea how many of the systems using the RTX were done in Forth as opposed to C? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mike Mellen <mmellen@intellikey.com> |
|---|---|
| Date | 2016-05-03 14:36 -0400 |
| Message-ID | <5728EF9C.5090805@intellikey.com> |
| In reply to | #46898 |
On 5/3/2016 10:20 AM, rickman wrote: > I recall working for a company who designed the Transputer into a system > they developed for the government. There was one person who was a > proponent of the Transputer and was able to show advantages for this > application (the days of the 68020 and VME otherwise). > > The language choices were Occam or C and I believe there was no way in > hell anyone was going to convince the programming team they needed to > use Occam. I expect for many RTX customers using Forth was a similar > issue and the C compiler was required if the chip would be used much. Do > you have any idea how many of the systems using the RTX were done in > Forth as opposed to C? 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).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-03 14:44 -0400 |
| Message-ID | <ngarcp$1o4$1@dont-email.me> |
| In reply to | #46901 |
On 5/3/2016 2:36 PM, Mike Mellen wrote: > On 5/3/2016 10:20 AM, rickman wrote: >> I recall working for a company who designed the Transputer into a system >> they developed for the government. There was one person who was a >> proponent of the Transputer and was able to show advantages for this >> application (the days of the 68020 and VME otherwise). >> >> The language choices were Occam or C and I believe there was no way in >> hell anyone was going to convince the programming team they needed to >> use Occam. I expect for many RTX customers using Forth was a similar >> issue and the C compiler was required if the chip would be used much. Do >> you have any idea how many of the systems using the RTX were done in >> Forth as opposed to C? > > 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). Do you have any idea how many customers and their use volume other than NASA? I don't think I've ever heard who bought these chips and how many were produced. I wonder if it was like the GA144, a few customers with special requirements. Obviously the rad-hard version would be limited quantity and "special needs" customers only. But there were commercial versions of the chips too, right? I would expect the quantities were never very big or the design would have continued longer. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mike Mellen <mmellen@intellikey.com> |
|---|---|
| Date | 2016-05-03 16:03 -0400 |
| Message-ID | <5729042E.9090703@intellikey.com> |
| In reply to | #46903 |
On 5/3/2016 2:44 PM, rickman wrote: > Do you have any idea how many customers and their use volume other than > NASA? I don't think I've ever heard who bought these chips and how many > were produced. I wonder if it was like the GA144, a few customers with > special requirements. Obviously the rad-hard version would be limited > quantity and "special needs" customers only. But there were commercial > versions of the chips too, right? I would expect the quantities were > never very big or the design would have continued longer. I really don't know any of the sales figures. I do know that if a Harris product didn't produce a large return on investment fairly quickly (2 years), it didn't last.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-03 16:28 -0400 |
| Message-ID | <ngb1ek$qfn$1@dont-email.me> |
| In reply to | #46905 |
On 5/3/2016 4:03 PM, Mike Mellen wrote: > On 5/3/2016 2:44 PM, rickman wrote: >> Do you have any idea how many customers and their use volume other than >> NASA? I don't think I've ever heard who bought these chips and how many >> were produced. I wonder if it was like the GA144, a few customers with >> special requirements. Obviously the rad-hard version would be limited >> quantity and "special needs" customers only. But there were commercial >> versions of the chips too, right? I would expect the quantities were >> never very big or the design would have continued longer. > > I really don't know any of the sales figures. I do know that if a Harris > product didn't produce a large return on investment fairly quickly (2 > years), it didn't last. I don't really know, but I expect it takes a while to get a new line of processors off the ground. I recall Stellaris worked for a few years gaining some market share until bought by TI. If they had used the approach Harris did they would have quit long before the payoff. I guess I didn't realize just how old the RTX line was. So it was contemporaneous with the 286? Wow. The 286 was a 16 bit processor with memory management (very crudely done by most opinions). That makes the RTX sound much higher performance for its time. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-03 13:37 -0700 |
| Message-ID | <87r3diev45.fsf@nightsong.com> |
| In reply to | #46901 |
Mike Mellen <mmellen@intellikey.com> writes: > The same reasoning led to the Harris C compiler - customers > comfortable with C. I left Harris soon after the C compiler was > released Any idea what kind of code the C compiler produced? C really needs to be able to reach into the interior of its stack, and I was surprised to find the RTX doesn't seem to support that, even with a PICK-like instruction. So I imagine the C compiler having to put C local variables in main memory, which sounds painful.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-05 02:56 -0500 |
| Message-ID | <AqSdnaXKd9MnYbfKnZ2dnUU7-YXNnZ2d@supernews.com> |
| In reply to | #46907 |
Paul Rubin <no.email@nospam.invalid> wrote: > Mike Mellen <mmellen@intellikey.com> writes: >> The same reasoning led to the Harris C compiler - customers >> comfortable with C. I left Harris soon after the C compiler was >> released > > Any idea what kind of code the C compiler produced? C really needs to > be able to reach into the interior of its stack, and I was surprised to > find the RTX doesn't seem to support that, even with a PICK-like > instruction. Novix certainly could do PICK, so I'd be amazed if the RTX couldn't. Novix also had 2-cycle access to 16 locations in memory. RTX had four user registers, which is not great but it's better than nothing. (It's important to realize that processors at the time were getting maybe 0.2 or 0.3 instructions per clock; Novix and RTX were getting close to 1 instruction per clock.) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2016-05-05 23:56 +0100 |
| Message-ID | <20160505235620.7a3b4ca9@HP-6550b> |
| In reply to | #46917 |
On Thu, 05 May 2016 02:56:42 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Paul Rubin <no.email@nospam.invalid> wrote: > > Any idea what kind of code the C compiler produced? C > > really needs to be able to reach into the interior of its > > stack, and I was surprised to find the RTX doesn't seem to > > support that, even with a PICK-like instruction. > > Novix certainly could do PICK, [...] OVER looks like the deepest single instruction stack access to me: https://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.html Perhaps a recursive method was used? This would need a little under pick-depth * 8 instructions to complete. The RTX2010 looks very similar. Jan Coombs.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-06 08:42 -0500 |
| Message-ID | <U9WdnaMzRqj_ArHKnZ2dnUU7-W3NnZ2d@supernews.com> |
| In reply to | #46920 |
Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> wrote: > On Thu, 05 May 2016 02:56:42 -0500 > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >> Paul Rubin <no.email@nospam.invalid> wrote: >> > Any idea what kind of code the C compiler produced? C >> > really needs to be able to reach into the interior of its >> > stack, and I was surprised to find the RTX doesn't seem to >> > support that, even with a PICK-like instruction. >> >> Novix certainly could do PICK, [...] > > OVER looks like the deepest single instruction stack access to > me: > > https://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.html > > Perhaps a recursive method was used? This would need a little > under pick-depth * 8 instructions to complete. I don't have the source code any more but I think it just required a change of SP, copy T into MD, and then restore SP. Not super-elegant but it wasn't that slow. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-06 13:00 -0400 |
| Message-ID | <ngiicl$cli$1@dont-email.me> |
| In reply to | #46934 |
On 5/6/2016 9:42 AM, Andrew Haley wrote: > Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> wrote: >> On Thu, 05 May 2016 02:56:42 -0500 >> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> >>> Paul Rubin <no.email@nospam.invalid> wrote: >>>> Any idea what kind of code the C compiler produced? C >>>> really needs to be able to reach into the interior of its >>>> stack, and I was surprised to find the RTX doesn't seem to >>>> support that, even with a PICK-like instruction. >>> >>> Novix certainly could do PICK, [...] >> >> OVER looks like the deepest single instruction stack access to >> me: >> >> https://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.html >> >> Perhaps a recursive method was used? This would need a little >> under pick-depth * 8 instructions to complete. > > I don't have the source code any more but I think it just required a > change of SP, copy T into MD, and then restore SP. Not super-elegant > but it wasn't that slow. > > Andrew. I don't think you can change the stack point on the RTX other than by pushes and pops. Am I wrong about that? The block diagrams don't show any access to the stack by direct addressing. I haven't dug into the instructions. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mike Mellen <mmellen@intellikey.com> |
|---|---|
| Date | 2016-05-06 13:56 -0400 |
| Message-ID | <787d6dec-f9e9-9501-25e6-eab0840f6116@intellikey.com> |
| In reply to | #46943 |
On 5/6/2016 1:00 PM, rickman 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? The block diagrams don't show > any access to the stack by direct addressing. I haven't dug into the > instructions. I believe you are correct about that. If I still have my RTX databook at home, I'll check for sure.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-07 03:48 -0500 |
| Message-ID | <H5qdnVl77p1CNrDKnZ2dnUU7-b_NnZ2d@supernews.com> |
| In reply to | #46943 |
rickman <gnuarm@gmail.com> wrote: > On 5/6/2016 9:42 AM, Andrew Haley wrote: >> Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> wrote: >>> On Thu, 05 May 2016 02:56:42 -0500 >>> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>> >>>> Paul Rubin <no.email@nospam.invalid> wrote: >>>>> Any idea what kind of code the C compiler produced? C >>>>> really needs to be able to reach into the interior of its >>>>> stack, and I was surprised to find the RTX doesn't seem to >>>>> support that, even with a PICK-like instruction. >>>> >>>> Novix certainly could do PICK, [...] >>> >>> OVER looks like the deepest single instruction stack access to >>> me: >>> >>> https://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.html >>> >>> Perhaps a recursive method was used? This would need a little >>> under pick-depth * 8 instructions to complete. >> >> I don't have the source code any more but I think it just required a >> change of SP, copy T into MD, and then restore SP. Not super-elegant >> but it wasn't that slow. > > 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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2016-05-07 14:05 +0100 |
| Subject | Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 |
| Message-ID | <20160507140541.6331e8f8@HP-6550b> |
| In reply to | #46968 |
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. > > Andrew. Thanks, so only a few instructions to pick, fancy trying roll? 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 Jan Coombs
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web