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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-07 13:51 -0700 |
| Message-ID | <325bea1a-0032-48af-b0d6-1f5b5c9c1e27@googlegroups.com> |
| In reply to | #46939 |
On Friday, May 6, 2016 at 9:20:11 AM UTC-7, 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 had never heard the term "compiled stack" before. I think what you are describing here is the same idea that I discussed with you previously --- functions' locals are global variablesthe; entire program is analyzed to determine which functions call which other functions so they can share the same memory for their locals if they are not in the same call-chain --- I suggested this at Testra as a way to boost the speed of their existing 80c320 system, prior to the MiniForth project, but they just wanted to stick with Forth --- they said that multiplication was the bottle-neck in motion-control, so this wouldn't help much. I agree that recursion is so rare in micro-controllers that it is not a problem. A much bigger problem however, is that quotations can't be supported in such a system because you have no way of knowing which function will execute the fat-xt and so you have no way of determining at compile-time what the call-chain of the functions is. This isn't an issue in C because C lacks quotations anyway --- C is such a crude language; I'd rather just program in assembly. I think that LFTforth could be implemented to use this system though. The name LFT means "local fall through" which means that the xt can only be executed within the child functions of the parent function where the quotation was defined, so you can determine at compile-time which call-chain the quotation is in. Raimond is totally focused on the ARM Cortex for his LFTforth, and it has abundant registers and an indexed addressing-mode, so this kind of system is not needed. I might be interested in implementing LFTforth or something similar on a small micro-controller that lacks an indexed addressing-mode --- maybe ye olde 80c320 --- is the Dallas chip still used, or is it totally obsolete now?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-07 14:57 -0700 |
| Message-ID | <378626d8-2346-47c6-87d3-0c7eaa92ece9@googlegroups.com> |
| In reply to | #46980 |
On Saturday, May 7, 2016 at 1:51:09 PM UTC-7, hughag...@gmail.com wrote: > quotations can't be supported in such a system because you have no way of knowing which function will execute the fat-xt and so you have no way of determining at compile-time what the call-chain of the functions is. I was wrong about this --- you can determine at compile-time what the call-chain of the fat-xt is --- the parent function still has to be in scope when the quotation is executed.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-05-03 10:58 -1000 |
| Message-ID | <w7CdnV7j4KWXjLTKnZ2dnUU7-S_NnZ2d@supernews.com> |
| In reply to | #46898 |
On 5/3/16 4:20 AM, rickman wrote: > 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? > I don't know of any figures, but I know the RTX polyFORTH was sold to several groups within NASA as well as several other aerospace companies who wanted to use it. We kept in touch with the NASA users, and occasionally did some application work for them, as recently as a few years ago. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-03 21:35 -0700 |
| Message-ID | <2336bb3e-accf-46e4-898e-f9c3fa4e52a0@googlegroups.com> |
| In reply to | #46896 |
On Tuesday, May 3, 2016 at 6:06:35 AM UTC-7, 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". I find it difficult to believe that Forth Inc. could produce a Forth compiler that worked at all. I suppose if they did no code optimization at all they could get it to work, pretty much the same as SwiftForth today. I also find it difficult to believe that NASA would hire Forth Inc. for anything, considering that Elizabeth Rather doesn't know at reentrancy is, doesn't know what full-duplex com is, etc.. I read a little about the RTX2000. A function call was done in zero clock-cycles, but a function return took one clock-cycle. It was the same on the MiniForth. The MiniForth was Harvard Architecture. The machine-code had 16-bit opcodes into which up to five machine instructions could be packed, all of which executed concurrently in a single clock-cycle. My assembler would rearrange the assembly instructions in such a way as to pack as many instructions into each opcode as possible (minimize how many NOP instructions had to be introduced) while still guaranteeing that the code did the same thing as if the assembly instructions were compiled one-per-opcode in the same order that they appeared in the source-code. NEXT was an assembly instruction, and it almost always got parallelized with one or more other assembly instructions --- that is why a function call took zero clock-cycles --- I don't recall there being any case in which NEXT didn't parallelize with some other instructions. What I remember, is that the assembler was the difficult part of the project. The Forth compiler was easy by comparison. I'm not much interested in Forth processors such as the RTX2000 because they don't have an assembly language and it is not possible to write new primitives. This is most likely why you think that Forth Inc.'s compiler was "good" --- without an assembly-language you can't really do any optimization, so a compiler that doesn't do any optimization is considered to be "good" --- although in the real world, you have to do optimization to generate reasonably fast code. In my system, I had "ghost code." These were primitives that were stored as source-code and didn't get assembled into machine-code until the first time that they were referenced. I had thousands of primitives, most of which were meta-compiled and were ghost code, so they didn't materialize unless they were referenced. There was 64KW for both machine-code and Forth-code memory. With 64KW of machine-code though, I could have thousands of primitives materialized. By comparison, the RTX2000 has fewer than 100 primitives and provides no way to add new primitives. In my system, small Forth words would sometimes compile into primitives --- also, I just wrote a lot of primitives myself --- doing this not only sped up the Forth code, but also made it smaller, and it was the Forth memory-space that was in danger of being filled up (we never got close to filling up the machine-code memory). The MiniForth (running on the Lattice isp1048 PLD) was available in 50 or 80 Mhz. versions. By comparison, the RTX2000 ran at 10 Mhz.. If every primitive in the MiniForth system took an average of 8 opcodes (remember that each opcode can have up to 5 instructions packed into it, so that is 40 instructions, although as a practical matter maybe 20 or 30 instructions because they didn't always parallelize fully), then the 80 Mhz. MiniForth would have been about the same speed as the 10 Mhz. RTX2000 --- but also remember that the MiniForth has thousands of primitives, whereas the RTX2000 has less than 100, which makes the MiniForth Forth code significantly smaller and more efficient than the RTX2000 Forth code --- so, all in all, I think we were ahead of you. Also remember that the Lattice isp1048 PLD costs very little compared to your RTX2000 --- as I recall, your price was comparable to an MC68000 system and roughly comparable to the MC68000 in speed (the MC68000 was what the competition in the laser-etching business was using, and we blew them away). Of course, all of this is ancient history now. The MiniForth has long ago been upgraded from the Lattice isp1048 PLD to an FPGA (and the name changed to RACE) --- it now runs much faster (at least 20 times faster, although I don't know exactly). Forth really died after ANS-Forth came out. Nobody was interested in the MiniForth. One one hand, they said that it was non-standard which is very bad, but on the other hand they said that they didn't want to use the ANS-Forth standard because it sucked --- so, Forth was dead --- your RTX2000 was another casualty, as it was non-standard too and could easily be dismissed just on that basis.
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-23 23:04 -0700 |
| Message-ID | <dfc7d75f-6694-4ef6-83d4-30cea51e333d@googlegroups.com> |
| In reply to | #46726 |
On Sunday, April 24, 2016 at 3:03:40 AM UTC+1, rickman wrote: > On 4/23/2016 7:01 PM, Paul Rubin wrote: > > rickman <gnuarm@gmail.com> writes: > >> Why not just compile directly to the target CPU and cut out the middle > >> man? It's got to be faster and easier. > > > > For spaceflight software there might have been some tedious > > certification process that would have to be done all over again if you > > change even one line of code. Therefore if you had something flying > > with an RTX on board and wanted to launch another one, it might be > > easier to emulate the RTX hardware and run the exact same code as > > before, than port the code to a new CPU. I don't know how likely this > > is but it's one possibility. > > Who said anything about changing code? The point of this discussion was > that the RTX Forth code would be run on a different architecture by > using some type of emulation. The RTX code is still Forth and could be > run on any target using a Forth compiler. > > -- > > Rick The important bit is to cut out the middle man - the processor - in the application to save on current and be faster and run existing and proven code and algorithms. And doing it in ASIC would then be possible as well - and you cold be back to a rad-hard RTX, probably 10x faster in existing technology. A small run on an MPW is not that expensive nowadays, probably 20 to 50k for such a small piece of silicon.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-24 03:12 -0400 |
| Message-ID | <nfhre6$slf$1@dont-email.me> |
| In reply to | #46732 |
On 4/24/2016 2:04 AM, JUERGEN wrote: > On Sunday, April 24, 2016 at 3:03:40 AM UTC+1, rickman wrote: >> On 4/23/2016 7:01 PM, Paul Rubin wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> Why not just compile directly to the target CPU and cut out the >>>> middle man? It's got to be faster and easier. >>> >>> For spaceflight software there might have been some tedious >>> certification process that would have to be done all over again >>> if you change even one line of code. Therefore if you had >>> something flying with an RTX on board and wanted to launch >>> another one, it might be easier to emulate the RTX hardware and >>> run the exact same code as before, than port the code to a new >>> CPU. I don't know how likely this is but it's one possibility. >> >> Who said anything about changing code? The point of this >> discussion was that the RTX Forth code would be run on a different >> architecture by using some type of emulation. The RTX code is >> still Forth and could be run on any target using a Forth compiler. >> >> -- >> >> Rick > > The important bit is to cut out the middle man - the processor - in > the application to save on current and be faster and run existing and > proven code and algorithms. And doing it in ASIC would then be > possible as well - and you cold be back to a rad-hard RTX, probably > 10x faster in existing technology. A small run on an MPW is not that > expensive nowadays, probably 20 to 50k for such a small piece of > silicon. None of those improvements are obvious to me by implementing the RTX processor. I'm pretty sure that if the RTX was inherently that much faster (not sure exactly what it is supposed to be faster than) it would already have been adopted, especially at that low a price. Processor speed is not the hallmark of a processor now anyway. As we found with the GA144, you need a lot more than just processor speed to be useful. A processor has to be designed for a class of apps and have a variety of support circuitry to suit that class. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-23 22:41 -0700 |
| Message-ID | <858494b3-b874-4061-8c94-43634ff9ce46@googlegroups.com> |
| In reply to | #46724 |
On Saturday, April 23, 2016 at 11:50:13 PM UTC+1, rickman wrote: > On 4/23/2016 6:11 PM, Paul Rubin wrote: > > JUERGEN <epldfpga@aol.com> writes: > >> RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. > > > > Might not be feasible on those small parts. I was thinking more > > like the 168mhz Cortex M4, or a Raspberry Pi level cpu. > > > >> So I can tell the kids on 11 June at the Maker Fair in Bristol when we > >> build more MicroBoxes: load this software and you have the same > >> processor that landed Philae on the Asteroid > > > > Doesn't seem like a convincing application. Why would they care about > > running the weird RTX instruction set? Main reason I can think of to > > want it is you have a pile of RTX software that you want to keep using. > > I don't get the need to emulate one machine on another. That is > essentially using a compiler based on a virtual machine (the RTX) which > has already been done with Forth programming. Why not just compile > directly to the target CPU and cut out the middle man? It's got to be e with > faster and easier. > > -- > > Rick Rick, if you do not get the idea why to emulate one processor on another - I can really live with this very well. BUT if this emulation exists in Forth it could run on ANY processor big enough. The chance to then implement the emulated processor into VHDL, or similar is a lot higher. And by the way - you would need the FPGA implementation to be available to tell potentials it is available and show it, as speed, LUTS and current consumption would be the main decision points for a potential user. But I have learnt over the years that the educational aspect to help Forth to grow or any commercial aspects are limited to very few people here. So, let's all look after what we are interested here, how diverse of special it might be.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-24 01:55 -0400 |
| Message-ID | <nfhmua$hbk$1@dont-email.me> |
| In reply to | #46728 |
On 4/24/2016 1:41 AM, JUERGEN wrote: > On Saturday, April 23, 2016 at 11:50:13 PM UTC+1, rickman wrote: >> On 4/23/2016 6:11 PM, Paul Rubin wrote: >>> JUERGEN <epldfpga@aol.com> writes: >>>> RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. >>> >>> Might not be feasible on those small parts. I was thinking more >>> like the 168mhz Cortex M4, or a Raspberry Pi level cpu. >>> >>>> So I can tell the kids on 11 June at the Maker Fair in Bristol when we >>>> build more MicroBoxes: load this software and you have the same >>>> processor that landed Philae on the Asteroid >>> >>> Doesn't seem like a convincing application. Why would they care about >>> running the weird RTX instruction set? Main reason I can think of to >>> want it is you have a pile of RTX software that you want to keep using. >> >> I don't get the need to emulate one machine on another. That is >> essentially using a compiler based on a virtual machine (the RTX) which >> has already been done with Forth programming. Why not just compile >> directly to the target CPU and cut out the middle man? It's got to be e with >> faster and easier. >> >> -- >> >> Rick > > Rick, if you do not get the idea why to emulate one processor on another - I can really live with this very well. BUT if this emulation exists in Forth it could run on ANY processor big enough. The chance to then implement the emulated processor into VHDL, or similar is a lot higher. And by the way - you would need the FPGA implementation to be available to tell potentials it is available and show it, as speed, LUTS and current consumption would be the main decision points for a potential user. But I have learnt over the years that the educational aspect to help Forth to grow or any commercial aspects are limited to very few people here. So, let's all look after what we are interested here, how diverse of special it might be. I'm afraid the language barrier has gotten in the way this time. I'm not sure what you are saying with most of this. A processor emulation in an FPGA has very limited market potential. There are many processors available with lower prices than most FPGAs. Soft cores are primarily used when an FPGA is already required but there is a need for a processor to perform some specific function that is harder to do in directly logic or would consume more resources in the FPGA. I believe MPE's work it oriented to rad-hard processing where there are few processors available. Porting the RTX to a rad-hard FPGA would provide a product in a sparse market, potentially with enhanced capabilities of some sort. Otherwise I expect the market for the RTX in an FPGA is very limited. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-23 23:21 -0700 |
| Message-ID | <82c72cfd-3522-4e30-9c76-3947201109fe@googlegroups.com> |
| In reply to | #46730 |
On Sunday, April 24, 2016 at 6:55:36 AM UTC+1, rickman wrote: > On 4/24/2016 1:41 AM, JUERGEN wrote: > > On Saturday, April 23, 2016 at 11:50:13 PM UTC+1, rickman wrote: > >> On 4/23/2016 6:11 PM, Paul Rubin wrote: > >>> JUERGEN <epldfpga@aol.com> writes: > >>>> RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. > >>> > >>> Might not be feasible on those small parts. I was thinking more > >>> like the 168mhz Cortex M4, or a Raspberry Pi level cpu. > >>> > >>>> So I can tell the kids on 11 June at the Maker Fair in Bristol when we > >>>> build more MicroBoxes: load this software and you have the same > >>>> processor that landed Philae on the Asteroid > >>> > >>> Doesn't seem like a convincing application. Why would they care about > >>> running the weird RTX instruction set? Main reason I can think of to > >>> want it is you have a pile of RTX software that you want to keep using. > >> > >> I don't get the need to emulate one machine on another. That is > >> essentially using a compiler based on a virtual machine (the RTX) which > >> has already been done with Forth programming. Why not just compile > >> directly to the target CPU and cut out the middle man? It's got to be e with > >> faster and easier. > >> > >> -- > >> > >> Rick > > > > Rick, if you do not get the idea why to emulate one processor on another - I can really live with this very well. BUT if this emulation exists in Forth it could run on ANY processor big enough. The chance to then implement the emulated processor into VHDL, or similar is a lot higher. And by the way - you would need the FPGA implementation to be available to tell potentials it is available and show it, as speed, LUTS and current consumption would be the main decision points for a potential user. But I have learnt over the years that the educational aspect to help Forth to grow or any commercial aspects are limited to very few people here. So, let's all look after what we are interested here, how diverse of special it might be. > > I'm afraid the language barrier has gotten in the way this time. I'm > not sure what you are saying with most of this. > > A processor emulation in an FPGA has very limited market potential. > There are many processors available with lower prices than most FPGAs. > Soft cores are primarily used when an FPGA is already required but there > is a need for a processor to perform some specific function that is > harder to do in directly logic or would consume more resources in the > FPGA. I believe MPE's work it oriented to rad-hard processing where > there are few processors available. Porting the RTX to a rad-hard FPGA > would provide a product in a sparse market, potentially with enhanced > capabilities of some sort. Otherwise I expect the market for the RTX in > an FPGA is very limited. > > -- > > Rick If I read this - why have any discussion about Forth at all- it is not even mentioned in language comparisons. Market size is relative to what you have to offer. And processors in gates running Forth - even less market. ( Get a Zynq with a few cores in hardware thrown in for free.). Coming back to what this thread is actually about - 8080 in FPGA - interesting enough to have a workshop about it - probably the first one ever; market value - debatable, fun factor - HIGH. And as this implementation is available - the fun factor could be extended by slightly modifying the VHDL, cut the 8080 core out and add the RTX VHDL instead, problem solved.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-24 03:21 -0400 |
| Message-ID | <nfhrun$u36$1@dont-email.me> |
| In reply to | #46733 |
On 4/24/2016 2:21 AM, JUERGEN wrote: > On Sunday, April 24, 2016 at 6:55:36 AM UTC+1, rickman wrote: >> On 4/24/2016 1:41 AM, JUERGEN wrote: >>> On Saturday, April 23, 2016 at 11:50:13 PM UTC+1, rickman wrote: >>>> On 4/23/2016 6:11 PM, Paul Rubin wrote: >>>>> JUERGEN <epldfpga@aol.com> writes: >>>>>> RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. >>>>> >>>>> Might not be feasible on those small parts. I was thinking >>>>> more like the 168mhz Cortex M4, or a Raspberry Pi level cpu. >>>>> >>>>>> So I can tell the kids on 11 June at the Maker Fair in >>>>>> Bristol when we build more MicroBoxes: load this software >>>>>> and you have the same processor that landed Philae on the >>>>>> Asteroid >>>>> >>>>> Doesn't seem like a convincing application. Why would they >>>>> care about running the weird RTX instruction set? Main >>>>> reason I can think of to want it is you have a pile of RTX >>>>> software that you want to keep using. >>>> >>>> I don't get the need to emulate one machine on another. That >>>> is essentially using a compiler based on a virtual machine (the >>>> RTX) which has already been done with Forth programming. Why >>>> not just compile directly to the target CPU and cut out the >>>> middle man? It's got to be e with faster and easier. >>>> >>>> -- >>>> >>>> Rick >>> >>> Rick, if you do not get the idea why to emulate one processor on >>> another - I can really live with this very well. BUT if this >>> emulation exists in Forth it could run on ANY processor big >>> enough. The chance to then implement the emulated processor into >>> VHDL, or similar is a lot higher. And by the way - you would need >>> the FPGA implementation to be available to tell potentials it is >>> available and show it, as speed, LUTS and current consumption >>> would be the main decision points for a potential user. But I >>> have learnt over the years that the educational aspect to help >>> Forth to grow or any commercial aspects are limited to very few >>> people here. So, let's all look after what we are interested >>> here, how diverse of special it might be. >> >> I'm afraid the language barrier has gotten in the way this time. >> I'm not sure what you are saying with most of this. >> >> A processor emulation in an FPGA has very limited market >> potential. There are many processors available with lower prices >> than most FPGAs. Soft cores are primarily used when an FPGA is >> already required but there is a need for a processor to perform >> some specific function that is harder to do in directly logic or >> would consume more resources in the FPGA. I believe MPE's work it >> oriented to rad-hard processing where there are few processors >> available. Porting the RTX to a rad-hard FPGA would provide a >> product in a sparse market, potentially with enhanced capabilities >> of some sort. Otherwise I expect the market for the RTX in an FPGA >> is very limited. >> >> -- >> >> Rick > > If I read this - why have any discussion about Forth at all- it is > not even mentioned in language comparisons. Market size is relative > to what you have to offer. And processors in gates running Forth - > even less market. ( Get a Zynq with a few cores in hardware thrown in > for free.). Coming back to what this thread is actually about - 8080 > in FPGA - interesting enough to have a workshop about it - probably > the first one ever; market value - debatable, fun factor - HIGH. And > as this implementation is available - the fun factor could be > extended by slightly modifying the VHDL, cut the 8080 core out and > add the RTX VHDL instead, problem solved. The first 8080 in an FPGA??? I expect not. Nearly every old 8 bit CPU has been done in FPGAs. There are at least 2 on opencores.org. There are 5 Z80 cores which is more popular for obvious reasons. Not really interesting to other than hobbyists I think. I actually don't get why the 8080 workshop is so popular. That's the main reason why I will be attending, to find out why people are interested. If you feel the RTX is a good thing to do in HDL, why don't you do that? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-24 08:40 -0700 |
| Message-ID | <3967561b-5594-4340-8fe1-8a0c0f1c8836@googlegroups.com> |
| In reply to | #46735 |
On Sunday, April 24, 2016 at 8:21:09 AM UTC+1, rickman wrote: > On 4/24/2016 2:21 AM, JUERGEN wrote: > > On Sunday, April 24, 2016 at 6:55:36 AM UTC+1, rickman wrote: > >> On 4/24/2016 1:41 AM, JUERGEN wrote: > >>> On Saturday, April 23, 2016 at 11:50:13 PM UTC+1, rickman wrote: > >>>> On 4/23/2016 6:11 PM, Paul Rubin wrote: > >>>>> JUERGEN <epldfpga@aol.com> writes: > >>>>>> RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. > >>>>> > >>>>> Might not be feasible on those small parts. I was thinking > >>>>> more like the 168mhz Cortex M4, or a Raspberry Pi level cpu. > >>>>> > >>>>>> So I can tell the kids on 11 June at the Maker Fair in > >>>>>> Bristol when we build more MicroBoxes: load this software > >>>>>> and you have the same processor that landed Philae on the > >>>>>> Asteroid > >>>>> > >>>>> Doesn't seem like a convincing application. Why would they > >>>>> care about running the weird RTX instruction set? Main > >>>>> reason I can think of to want it is you have a pile of RTX > >>>>> software that you want to keep using. > >>>> > >>>> I don't get the need to emulate one machine on another. That > >>>> is essentially using a compiler based on a virtual machine (the > >>>> RTX) which has already been done with Forth programming. Why > >>>> not just compile directly to the target CPU and cut out the > >>>> middle man? It's got to be e with faster and easier. > >>>> > >>>> -- > >>>> > >>>> Rick > >>> > >>> Rick, if you do not get the idea why to emulate one processor on > >>> another - I can really live with this very well. BUT if this > >>> emulation exists in Forth it could run on ANY processor big > >>> enough. The chance to then implement the emulated processor into > >>> VHDL, or similar is a lot higher. And by the way - you would need > >>> the FPGA implementation to be available to tell potentials it is > >>> available and show it, as speed, LUTS and current consumption > >>> would be the main decision points for a potential user. But I > >>> have learnt over the years that the educational aspect to help > >>> Forth to grow or any commercial aspects are limited to very few > >>> people here. So, let's all look after what we are interested > >>> here, how diverse of special it might be. > >> > >> I'm afraid the language barrier has gotten in the way this time. > >> I'm not sure what you are saying with most of this. > >> > >> A processor emulation in an FPGA has very limited market > >> potential. There are many processors available with lower prices > >> than most FPGAs. Soft cores are primarily used when an FPGA is > >> already required but there is a need for a processor to perform > >> some specific function that is harder to do in directly logic or > >> would consume more resources in the FPGA. I believe MPE's work it > >> oriented to rad-hard processing where there are few processors > >> available. Porting the RTX to a rad-hard FPGA would provide a > >> product in a sparse market, potentially with enhanced capabilities > >> of some sort. Otherwise I expect the market for the RTX in an FPGA > >> is very limited. > >> > >> -- > >> > >> Rick > > > > If I read this - why have any discussion about Forth at all- it is > > not even mentioned in language comparisons. Market size is relative > > to what you have to offer. And processors in gates running Forth - > > even less market. ( Get a Zynq with a few cores in hardware thrown in > > for free.). Coming back to what this thread is actually about - 8080 > > in FPGA - interesting enough to have a workshop about it - probably > > the first one ever; market value - debatable, fun factor - HIGH. And > > as this implementation is available - the fun factor could be > > extended by slightly modifying the VHDL, cut the 8080 core out and > > add the RTX VHDL instead, problem solved. > > The first 8080 in an FPGA??? I expect not. Nearly every old 8 bit CPU > has been done in FPGAs. There are at least 2 on opencores.org. There > are 5 Z80 cores which is more popular for obvious reasons. Not really > interesting to other than hobbyists I think. > > I actually don't get why the 8080 workshop is so popular. That's the > main reason why I will be attending, to find out why people are > interested. > > If you feel the RTX is a good thing to do in HDL, why don't you do that? > > -- > > Rick You should go to bed I assume - an event is not a processor. People do things because they like it - and for your better understanding I copied from a bit higher " 8080 > > in FPGA - interesting enough to have a workshop about it - probably > > the first one ever; market value - debatable, fun factor -
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-24 08:34 -0700 |
| Message-ID | <4c0385b3-4e3c-48d5-bd53-08a12c293456@googlegroups.com> |
| In reply to | #46730 |
On Sunday, April 24, 2016 at 6:55:36 AM UTC+1, rickman wrote: > On 4/24/2016 1:41 AM, JUERGEN wrote: > > On Saturday, April 23, 2016 at 11:50:13 PM UTC+1, rickman wrote: > >> On 4/23/2016 6:11 PM, Paul Rubin wrote: > >>> JUERGEN <epldfpga@aol.com> writes: > >>>> RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. > >>> > >>> Might not be feasible on those small parts. I was thinking more > >>> like the 168mhz Cortex M4, or a Raspberry Pi level cpu. > >>> > >>>> So I can tell the kids on 11 June at the Maker Fair in Bristol when we > >>>> build more MicroBoxes: load this software and you have the same > >>>> processor that landed Philae on the Asteroid > >>> > >>> Doesn't seem like a convincing application. Why would they care about > >>> running the weird RTX instruction set? Main reason I can think of to > >>> want it is you have a pile of RTX software that you want to keep using. > >> > >> I don't get the need to emulate one machine on another. That is > >> essentially using a compiler based on a virtual machine (the RTX) which > >> has already been done with Forth programming. Why not just compile > >> directly to the target CPU and cut out the middle man? It's got to be e with > >> faster and easier. > >> > >> -- > >> > >> Rick > > > > Rick, if you do not get the idea why to emulate one processor on another - I can really live with this very well. BUT if this emulation exists in Forth it could run on ANY processor big enough. The chance to then implement the emulated processor into VHDL, or similar is a lot higher. And by the way - you would need the FPGA implementation to be available to tell potentials it is available and show it, as speed, LUTS and current consumption would be the main decision points for a potential user. But I have learnt over the years that the educational aspect to help Forth to grow or any commercial aspects are limited to very few people here. So, let's all look after what we are interested here, how diverse of special it might be. > > I'm afraid the language barrier has gotten in the way this time. I'm > not sure what you are saying with most of this. > > A processor emulation in an FPGA has very limited market potential. > There are many processors available with lower prices than most FPGAs. > Soft cores are primarily used when an FPGA is already required but there > is a need for a processor to perform some specific function that is > harder to do in directly logic or would consume more resources in the > FPGA. I believe MPE's work it oriented to rad-hard processing where > there are few processors available. Porting the RTX to a rad-hard FPGA > would provide a product in a sparse market, potentially with enhanced > capabilities of some sort. Otherwise I expect the market for the RTX in > an FPGA is very limited. > > -- > > Rick You seem to have gotten out of your area of knowledge - then please keep ouf of commenting. Thanks very much for your understanding.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-24 12:16 -0400 |
| Message-ID | <nfira6$g0b$1@dont-email.me> |
| In reply to | #46738 |
On 4/24/2016 11:34 AM, JUERGEN wrote: > On Sunday, April 24, 2016 at 6:55:36 AM UTC+1, rickman wrote: >> On 4/24/2016 1:41 AM, JUERGEN wrote: >>> On Saturday, April 23, 2016 at 11:50:13 PM UTC+1, rickman wrote: >>>> On 4/23/2016 6:11 PM, Paul Rubin wrote: >>>>> JUERGEN <epldfpga@aol.com> writes: >>>>>> RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. >>>>> >>>>> Might not be feasible on those small parts. I was thinking more >>>>> like the 168mhz Cortex M4, or a Raspberry Pi level cpu. >>>>> >>>>>> So I can tell the kids on 11 June at the Maker Fair in Bristol when we >>>>>> build more MicroBoxes: load this software and you have the same >>>>>> processor that landed Philae on the Asteroid >>>>> >>>>> Doesn't seem like a convincing application. Why would they care about >>>>> running the weird RTX instruction set? Main reason I can think of to >>>>> want it is you have a pile of RTX software that you want to keep using. >>>> >>>> I don't get the need to emulate one machine on another. That is >>>> essentially using a compiler based on a virtual machine (the RTX) which >>>> has already been done with Forth programming. Why not just compile >>>> directly to the target CPU and cut out the middle man? It's got to be e with >>>> faster and easier. >>>> >>>> -- >>>> >>>> Rick >>> >>> Rick, if you do not get the idea why to emulate one processor on another - I can really live with this very well. BUT if this emulation exists in Forth it could run on ANY processor big enough. The chance to then implement the emulated processor into VHDL, or similar is a lot higher. And by the way - you would need the FPGA implementation to be available to tell potentials it is available and show it, as speed, LUTS and current consumption would be the main decision points for a potential user. But I have learnt over the years that the educational aspect to help Forth to grow or any commercial aspects are limited to very few people here. So, let's all look after what we are interested here, how diverse of special it might be. >> >> I'm afraid the language barrier has gotten in the way this time. I'm >> not sure what you are saying with most of this. >> >> A processor emulation in an FPGA has very limited market potential. >> There are many processors available with lower prices than most FPGAs. >> Soft cores are primarily used when an FPGA is already required but there >> is a need for a processor to perform some specific function that is >> harder to do in directly logic or would consume more resources in the >> FPGA. I believe MPE's work it oriented to rad-hard processing where >> there are few processors available. Porting the RTX to a rad-hard FPGA >> would provide a product in a sparse market, potentially with enhanced >> capabilities of some sort. Otherwise I expect the market for the RTX in >> an FPGA is very limited. >> >> -- >> >> Rick > > You seem to have gotten out of your area of knowledge - then please keep ouf of commenting. Thanks very much for your understanding. I'm not sure if you intend to be offensive or if this is just the result of a difference in culture. I had a German coworker who once told me "You must explain...". That is considered rude in the US. This is a public discussion started by... me. I am trying to discuss the facts. FPGAs are actually my specialty and I have designed my own soft core processors. I believe I am adequately qualified to participate in an Internet discussion on the topic. If you wish to discuss this topic with me, please do so. If you don't wish to discuss the topic with me, then please feel free to not. I find it interesting that you have stopped responding to the technical content and are instead being personal. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-23 22:55 -0700 |
| Message-ID | <ab9cb92d-9d47-4c03-bafe-8fa2a4c6bc63@googlegroups.com> |
| In reply to | #46722 |
On Saturday, April 23, 2016 at 11:11:32 PM UTC+1, Paul Rubin wrote: > JUERGEN <epldfpga@aol.com> writes: > > RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. > > Might not be feasible on those small parts. I was thinking more > like the 168mhz Cortex M4, or a Raspberry Pi level cpu. > > > So I can tell the kids on 11 June at the Maker Fair in Bristol when we > > build more MicroBoxes: load this software and you have the same > > processor that landed Philae on the Asteroid > > Doesn't seem like a convincing application. Why would they care about > running the weird RTX instruction set? Main reason I can think of to > want it is you have a pile of RTX software that you want to keep using. Paul, M4 and Pi are fine and available here in hardware now, or I would probably buy the HW you suggest - just for the fun of it. But I would suggest a target hardware where a solution using the two commercial Forths is possible. The theoretical 2nd source should be covered for a potential commercial user. AND I did not want to say kids want RTX, but the educational aspects are there. In the same way I never understood why nobody did a " clean room " Forth implementation of one or a few G144 processors. The entry cost now is too high for many to play with it - so the real advantages do not show and it is not used.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-24 03:29 -0400 |
| Message-ID | <nfhsdf$v58$1@dont-email.me> |
| In reply to | #46729 |
On 4/24/2016 1:55 AM, JUERGEN wrote: > On Saturday, April 23, 2016 at 11:11:32 PM UTC+1, Paul Rubin wrote: >> JUERGEN <epldfpga@aol.com> writes: >>> RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. >> >> Might not be feasible on those small parts. I was thinking more >> like the 168mhz Cortex M4, or a Raspberry Pi level cpu. >> >>> So I can tell the kids on 11 June at the Maker Fair in Bristol when we >>> build more MicroBoxes: load this software and you have the same >>> processor that landed Philae on the Asteroid >> >> Doesn't seem like a convincing application. Why would they care about >> running the weird RTX instruction set? Main reason I can think of to >> want it is you have a pile of RTX software that you want to keep using. > > Paul, M4 and Pi are fine and available here in hardware now, or I would probably buy the HW you suggest - just for the fun of it. But I would suggest a target hardware where a solution using the two commercial Forths is possible. The theoretical 2nd source should be covered for a potential commercial user. AND I did not want to say kids want RTX, but the educational aspects are there. In the same way I never understood why nobody did a " clean room " Forth implementation of one or a few G144 processors. The entry cost now is too high for many to play with it - so the real advantages do not show and it is not used. Are you saying the GA144 failed because the "entry" cost is too high? Do you mean the learning curve? The price of the eval board? Certainly $500 is not so much to a company seriously interested in using the GA144. The problem with that device is the huge processor performance combined with the small I/O throughput, low memory bandwidth and lack of modern interfaces makes the part suitable for a very, *very* limited range of apps. It compares favorably to the ADI SigmaDSP line which have audio interfaces and/or CODECs built in with a wide range of processor performance. But the GA144 is *much* harder to learn to program. For the SigmaDSP ADI has a graphical building block approach to programming which works well for the types of apps it is geared toward. The GA144 has a huge learning curve to just getting a "hello world" program to run. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2016-04-25 19:03 -0700 |
| Message-ID | <2dfc0f36-774c-479a-8e19-031b6c117cfe@googlegroups.com> |
| In reply to | #46716 |
On Saturday, April 23, 2016 at 4:55:53 AM UTC-4, JUERGEN wrote: > RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. > So I can tell the kids on 11 June at the Maker Fair in Bristol when we build more MicroBoxes: load this software and you have the same processor that landed Philae on the Asteroid - and as we will build about 50 - this would be more Processing Power and probably faster that what was on there - including the carrier ... Programs running on the RTX2000 written in Forth will run on the MSP430G2553, too, having a Forth system on chip - except the hardware specific I/O and Timers. But instead telling the kids they would have the same processor, tell them that they are using the same programming language that landed Philae on the Asteroid. See Wolfgang Allinger's report on https://groups.google.com/forum/?fromgroups#!searchin/comp.lang.forth/rtx2000$20allinger|sort:relevance/comp.lang.forth/7Byy-42cvTg/7tbbuuEGbYkJ
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-04-26 05:04 -0700 |
| Message-ID | <4b5a7eb0-51bc-4fe8-a86e-b5390779a370@googlegroups.com> |
| In reply to | #46769 |
On Tuesday, April 26, 2016 at 3:03:59 AM UTC+1, visua...@rocketmail.com wrote: > On Saturday, April 23, 2016 at 4:55:53 AM UTC-4, JUERGEN wrote: > > RTX running on an MSP430G2553 or an ARM LP1114 DIL - WOW. > > So I can tell the kids on 11 June at the Maker Fair in Bristol when we build more MicroBoxes: load this software and you have the same processor that landed Philae on the Asteroid - and as we will build about 50 - this would be more Processing Power and probably faster that what was on there - including the carrier ... > > Programs running on the RTX2000 written in Forth will run on the MSP430G2553, too, having a Forth system on chip - except the hardware specific I/O and Timers. > > But instead telling the kids they would have the same processor, tell them that they are using the same programming language that landed Philae on the Asteroid. > > See Wolfgang Allinger's report on https://groups.google.com/forum/?fromgroups#!searchin/comp.lang.forth/rtx2000$20allinger|sort:relevance/comp.lang.forth/7Byy-42cvTg/7tbbuuEGbYkJ Is there a rough comparison factor RTX and 2553 performance e.g. RTX roughly 5x faster - but high and a lot better IO accuracy and timer performance?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-26 10:42 -0700 |
| Message-ID | <8737q8jmgt.fsf@nightsong.com> |
| In reply to | #46779 |
JUERGEN <epldfpga@aol.com> writes: > Is there a rough comparison factor RTX and 2553 performance e.g. RTX > roughly 5x faster - but high and a lot better IO accuracy and timer > performance? Regular arithmetic on the RTX and 2553 should be in the same ballpark, probably favoring the 2553 since it is clocked faster (16 mhz instead of 10 mhz). IIRC the RTX had exceptionally fast interrupt handling due to not having to save as much context as conventional cpus did. So it possibly beats the 2553 at that. The RTX is a more powerful chip than the 2553 because of its deep stacks, hardware multiplier, and other features. It's perhaps comparable to one of the higher end 430's, or a small ARM. Info here: http://soton.mpeforth.com/flag/jfar/vol6/no1/article1.pdf
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-26 15:12 -0400 |
| Message-ID | <nfoecm$h1n$1@dont-email.me> |
| In reply to | #46787 |
On 4/26/2016 1:42 PM, Paul Rubin wrote: > JUERGEN <epldfpga@aol.com> writes: >> Is there a rough comparison factor RTX and 2553 performance e.g. RTX >> roughly 5x faster - but high and a lot better IO accuracy and timer >> performance? > > Regular arithmetic on the RTX and 2553 should be in the same ballpark, > probably favoring the 2553 since it is clocked faster (16 mhz instead of > 10 mhz). IIRC the RTX had exceptionally fast interrupt handling due to > not having to save as much context as conventional cpus did. So it > possibly beats the 2553 at that. The RTX is a more powerful chip than > the 2553 because of its deep stacks, hardware multiplier, and other > features. It's perhaps comparable to one of the higher end 430's, > or a small ARM. > > Info here: http://soton.mpeforth.com/flag/jfar/vol6/no1/article1.pdf I just wanted to point out that many of the MSP430 chips have a hardware multiplier even if the 2553 doesn't. I'm not sure why deep stacks would make the RTX a more powerful chip. It has been shown many times that when running Forth a stack does not need to be deep. While the RTX may have some natural advantage when running Forth, it is not a *huge* advantage and most of the ARM CPUs will run rings around it. If it were made in a more current technology it might keep pace with other processors, but the thing that usually limits performance in MCUs is the Flash memory, not the CPU. That's why the faster processors don't include Flash. Rather they use larger amounts of RAM and load programs from the Flash to the RAM. So at some point speeds becomes a poor way to compare the RTX which has on on chip RAM or Flash if I am not mistaken (other than the stacks which is not a RAM replacement). So instead of comparing it to the MSP430 line of MCUs, the RTX should be compared to CPUs without internal RAM like the higher end ARMs which run at hundreds of MHz. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-26 16:51 -0700 |
| Message-ID | <87twiohqti.fsf@nightsong.com> |
| In reply to | #46790 |
rickman <gnuarm@gmail.com> writes: > hardware multiplier even if the 2553 doesn't. I'm not sure why deep > stacks would make the RTX a more powerful chip. It has been shown > many times that when running Forth a stack does not need to be deep. The RTX has about 1kB of memory in the stacks alone. The 2553 has 0.5k of ram on the whole chip, plus 40-50 usable bytes in the registers if you want to count those. I don't know if the RTX has any addressible ram, e.g. if the stacks support random access. I also forgot to consider program memory. The 2553 has 16k and I don't know if the RTX has any. > the thing that usually limits performance in MCUs is the Flash memory, > not the CPU. That's why the faster processors don't include Flash. The fast Cortex-M's have some feature (ART) that speeds up execution from flash. I think it's basically a small hardware cache but I'm not sure. > So instead of comparing it to the MSP430 line of MCUs, the RTX should > be compared to CPUs without internal RAM like the higher end ARMs > which run at hundreds of MHz. The lower end ARMs may be more appropriate: they could also copy code to ram if necessary, and any way they run at so much higher frequency than the RTX that they can stand a few extra cycles to read from flash.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web