Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58497 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-05-02 15:27 +0100 |
| Last post | 2017-05-04 10:07 -0700 |
| Articles | 20 on this page of 177 — 26 participants |
Back to article view | Back to comp.lang.forth
Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 15:27 +0100
Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 07:52 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-02 08:19 -0700
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 08:27 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:55 +0100
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-03 02:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:16 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:05 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:23 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:26 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:03 -0500
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 12:44 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:36 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:28 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:13 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:35 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 18:53 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:10 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:22 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:53 +0000
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:39 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 10:58 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:53 +0000
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:21 +0000
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 00:22 -0700
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-06 23:05 +0100
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 22:36 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:38 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 04:49 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 05:03 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 09:02 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 07:45 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:24 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:45 -0700
Re: Recognizers discussion Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-03 10:08 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:56 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:37 +0100
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 11:07 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 20:55 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:47 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:07 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 07:59 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:38 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:42 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:43 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:05 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:10 +0300
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:25 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:33 +0300
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:05 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:54 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 11:10 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:49 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:14 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 13:02 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-05 23:29 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:56 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:42 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:08 -0500
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 08:51 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:38 -0700
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 09:59 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 10:16 -0700
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 22:04 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 22:09 -0700
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:50 -0700
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-07 21:33 -1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:12 -0500
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:21 -0700
FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 12:35 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:50 -0700
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 03:39 -0500
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:59 -0700
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:03 -0700
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:10 +0100
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:24 -1000
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:37 -0700
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 22:53 -1000
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:53 +0100
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:00 +0300
Re: FP stack Paul Rubin <no.email@nospam.invalid> - 2017-05-10 01:02 -0700
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:06 +0300
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:58 +0000
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:17 +0300
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 13:09 +0100
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 15:05 +0000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:43 +0200
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-10 18:34 +1000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:45 +0000
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-11 19:13 +1000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:50 -0500
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:18 +0000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 12:12 -0500
Re: FP stack stephen@mpeforth.com (Stephen Pelc) - 2017-05-11 13:53 +0000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 15:43 +0000
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-12 08:48 -0700
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:31 +0000
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 10:18 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 15:37 -0500
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 17:25 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 22:55 -0500
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-13 14:24 +1000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-13 13:44 +0200
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:58 -0500
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 13:50 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:25 -0700
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 11:39 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 11:49 -0700
Re: FP stack (was: Recognizers discussion) "HAA" <someone@microsoft.com> - 2017-05-09 21:15 +1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-09 14:16 +1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 08:57 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 07:54 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:30 -0500
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 14:05 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:42 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:51 -0500
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-04 22:29 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:41 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:06 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 07:36 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:21 +0000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:24 +0000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-04 20:17 +0200
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-05 11:03 +1000
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 00:16 -0700
Re: Recognizers discussion JUERGEN <epldfpga@aol.com> - 2017-05-05 13:15 -0700
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-06 16:49 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-05 21:00 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 14:17 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-09 15:46 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:50 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 13:11 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 13:49 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 15:57 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:17 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:25 -1000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 01:19 +0200
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-05 15:50 +0000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-08 11:43 +1000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-08 19:17 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:25 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:22 -1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-13 13:33 +1000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-12 21:32 -1000
Re: Recognizers discussion Howerd <howerdo@yahoo.co.uk> - 2017-05-13 07:12 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:30 +0000
Re: Recognizers discussion rickman <gnuarm@gmail.com> - 2017-05-04 11:37 -0400
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:51 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 07:31 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-05 20:35 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 12:27 -0700
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-05 15:03 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:26 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 18:17 +0100
Re: Recognizers discussion Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:26 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 21:39 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:58 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-07 10:39 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:39 +0000
Re: Recognizers discussion Paul Rubin <no.email@nospam.invalid> - 2017-05-07 17:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:40 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:25 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-08 16:25 +0200
Flash (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:51 +0000
Re: Flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 08:06 -0500
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 13:57 +0000
Re: Flash Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-07 16:46 +0200
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 16:31 +0100
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:16 +0000
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:18 +0100
Re: Flash albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 21:45 +0200
Re: Flash Matthias Trute <matthias.trute@gmail.com> - 2017-05-07 12:54 -0700
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:33 +0100
Re: Flash Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-07 08:50 -0700
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:21 +0000
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-04 10:07 -0700
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-11 22:55 -0500 |
| Subject | Re: FP stack |
| Message-ID | <of3bhf$47c$1@dont-email.me> |
| In reply to | #59099 |
On 5/11/2017 10:25 PM, Elizabeth D. Rather wrote: > On 5/11/17 10:37 AM, Cecil Bayona wrote: >> On 5/11/2017 3:18 PM, Elizabeth D. Rather wrote: >>> On 5/10/17 11:13 PM, HAA wrote: >>>> Anton Ertl wrote: >>>>> "HAA" <someone@microsoft.com> writes: >>>>>> LMI - claimed to be Forth's second largest vendor - used >>>>>> floats on the data stack exclusively. >>>>> >>>>> Whoever claims this is wrong. Looking at >>>>> <https://www.linkedin.com/in/raygduncan>, Ray Duncan has not worked >>>>> for LMI since 2000, and AFAIK LMI has not had any business since then, >>>>> if it exists at all (Google does not find a web page belonging to >>>>> LMI). >>>> >>>> LMI was certainly a major Forth vendor. So what if the owner chose to >>>> leave to pursue other interests. >>>> >>> >>> Ray was a physician. In the mid-90's he went back to grad school and >>> became a neonatologist. When he entered practice, he turned over his >>> code and customer list to FORTH, Inc. and we took care of a number of >>> his customers for years. >>> >>> Cheers, >>> Elizabeth >>> >> Since it's so old, can we have it? > > I can't answer that, Leon is in charge now. I don't even know if he > could find a copy, nor do I know why you would want one. There are > numerous better free Forths around. > > Cheers, > Elizabeth > There is always something to be learned even from an old Forth, so having access to the source could be instructive even for an old Forth. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-13 14:24 +1000 |
| Subject | Re: FP stack |
| Message-ID | <of61q6$n9s$1@gioia.aioe.org> |
| In reply to | #59100 |
Cecil Bayona wrote: > On 5/11/2017 10:25 PM, Elizabeth D. Rather wrote: > > On 5/11/17 10:37 AM, Cecil Bayona wrote: > >> On 5/11/2017 3:18 PM, Elizabeth D. Rather wrote: > >>> On 5/10/17 11:13 PM, HAA wrote: > >>>> Anton Ertl wrote: > >>>>> "HAA" <someone@microsoft.com> writes: > >>>>>> LMI - claimed to be Forth's second largest vendor - used > >>>>>> floats on the data stack exclusively. > >>>>> > >>>>> Whoever claims this is wrong. Looking at > >>>>> <https://www.linkedin.com/in/raygduncan>, Ray Duncan has not worked > >>>>> for LMI since 2000, and AFAIK LMI has not had any business since then, > >>>>> if it exists at all (Google does not find a web page belonging to > >>>>> LMI). > >>>> > >>>> LMI was certainly a major Forth vendor. So what if the owner chose to > >>>> leave to pursue other interests. > >>>> > >>> > >>> Ray was a physician. In the mid-90's he went back to grad school and > >>> became a neonatologist. When he entered practice, he turned over his > >>> code and customer list to FORTH, Inc. and we took care of a number of > >>> his customers for years. > >>> > >>> Cheers, > >>> Elizabeth > >>> > >> Since it's so old, can we have it? > > > > I can't answer that, Leon is in charge now. I don't even know if he > > could find a copy, nor do I know why you would want one. There are > > numerous better free Forths around. > > > > Cheers, > > Elizabeth > > > There is always something to be learned even from an old Forth, so > having access to the source could be instructive even for an old Forth. Code of that vintage is showing its age but ideas and approaches can still be relevant. I don't know what deal, if any, was done between Forth Inc and LMI as to code rights upon Ray leaving. However he posted a 6811 cross-compiler he still had in his possession on the Greenarrays website. http://www.greenarraychips.com/home/documents/forth-archive.html You may be able to contact Ray for a definitive response through one of the online link sites for professionals. I read an online comment suggesting Ray couldn't find a purchaser for LMI. He'd predicted some years earlier there would be a further shake-out of forth vendors...
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-13 13:44 +0200 |
| Subject | Re: FP stack |
| Message-ID | <of6rje$6bo$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #59099 |
In article <VsadncaAHt6qtojEnZ2dnUU7-dfNnZ2d@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: >On 5/11/17 10:37 AM, Cecil Bayona wrote: >> On 5/11/2017 3:18 PM, Elizabeth D. Rather wrote: >>> On 5/10/17 11:13 PM, HAA wrote: >>>> Anton Ertl wrote: >>>>> "HAA" <someone@microsoft.com> writes: >>>>>> LMI - claimed to be Forth's second largest vendor - used >>>>>> floats on the data stack exclusively. >>>>> >>>>> Whoever claims this is wrong. Looking at >>>>> <https://www.linkedin.com/in/raygduncan>, Ray Duncan has not worked >>>>> for LMI since 2000, and AFAIK LMI has not had any business since then, >>>>> if it exists at all (Google does not find a web page belonging to LMI). >>>> >>>> LMI was certainly a major Forth vendor. So what if the owner chose to >>>> leave to pursue other interests. >>>> >>> >>> Ray was a physician. In the mid-90's he went back to grad school and >>> became a neonatologist. When he entered practice, he turned over his >>> code and customer list to FORTH, Inc. and we took care of a number of >>> his customers for years. >>> >>> Cheers, >>> Elizabeth >>> >> Since it's so old, can we have it? > >I can't answer that, Leon is in charge now. I don't even know if he >could find a copy, nor do I know why you would want one. There are >numerous better free Forths around. Really? Does historic interest means nothing to you? Take some pity on the guy who is doing a biography of Moore/Forth a hundred years from now. > >Cheers, >Elizabeth -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-10 05:58 -0500 |
| Subject | Re: FP stack |
| Message-ID | <H7adnXiSqJjCb4_EnZ2dnUU7-X_NnZ2d@supernews.com> |
| In reply to | #58921 |
Joel Rees <joel.rees@gmail.com> wrote:
> On Tuesday, May 9, 2017 at 5:39:44 PM UTC+9, Andrew Haley wrote:
>> Joel Rees <joel rees@somewhere> wrote:
>> >
>> >> 2) How many cells should an FP value have on the data stack? 1? 2? 4?
>> >> None of these answers is good for all systems. Or maybe an FP value
>> >> should be an opaque type with an unspecified size? Then you cannot
>> >> access anything below it.
>> >
>> > As I mentioned elsewhere, I don't understand how this is a concern.
>> >
>> > When we need to know the byte width of a CELL, if we don't have a
>> > constant for it, we make one, just so we don't have to keep writing
>> >
>> > SP@ SP@ -
>> >
>> > all over in our code.
>> >
>> > We have to provide the floating point math words, why not just provide
>> > a few constants to tell us how big they are?
>>
>> That's not the problem. Say you have
>>
>> 1 1.0e0
>>
>> on an integrated stack with floating-point numbers and integers. How
>> do you SWAP them? A float might be 1, 2, or 3 cells in size.
>
> Say you have
>
> 1 1.
>
> on stack. How do you swap them?
ROT
> Sure, you know a double is two cells. But that is just an implicit
> constant. Hmm.
>
> 2>R S>D 2R> DSWAP
>
> is a "robust" solution that does not reference the constant in the
> programmer's mind. It could be followed by a D>S if we want to be
> perfectly thorough.
>
> F>R S>F FR> FSWAP
If we had floating-point locals this could reduce to
to x >r x r>
but it's stil very unpleasant when all you want to do is SWAP . And
if you have seperate stacks you never have to do that, because both
operands are already on the top of their respective stacks, so you
have much less stack noise in words which use floating-point and
integer operands.
> Admittedly, tagging an F>S on the end of that would require really
> good rounding in the definition of F>S, and may induce unintentional
> sensitivity to exceptions.
And it'd lose precision unless floats always occupied multiple cells.
So, as you can see, the mixed stack is almost unusable in practice.
Given that separate floating-point stacks are common, and writing code
for them is so much easier, it's the standard way to do it.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-09 13:50 +0000 |
| Subject | Re: FP stack (was: Recognizers discussion) |
| Message-ID | <2017May9.155023@mips.complang.tuwien.ac.at> |
| In reply to | #58870 |
Joel Rees <joel.rees@gmail.com> writes:
>On Monday, May 8, 2017 at 10:24:31 PM UTC+9, Anton Ertl wrote:
>> Joel Rees <joel rees@somewhere> writes:
>> >I've never understood the need for a separate floating point stack.
>> ...
>> >But we put doubles, pointers, string pointers, string records, and all sort=
>> >s of other non-single-cell-integer non-scalar stuff on the parameter/local =
>> >state stack. Why not floating point, as well? (Especially, now that 32 bit =
>> >and 64 bit CPUs are becoming the norm, even in the embedded world.)
>>
>> 1) There is little overlap between integer and FP operations,
>> basically just the data-movement stuff @ ! DUP SWAP etc. By contrast,
>> we use, e.g., +, -, and u< on signed and unsigned integers, and on
>> addresses, and being able to access the individual cells of doubles
>> allows implementing various more refined operations (e.g., triple-cell
>> integers in M*/).
>
>Well, the virtual word U+ is the same as + on two's complement, but D+ is
>still D+. And then there is UM* and UM/MOD, etc.
>
>It's not like type is completely transparent until you hit FP.
Of course not. That's not what I claimed.
Another way of putting it: We do not split the data stack into an
address stack, an integer stack, a double stack, etc. for the same
reason that in CPU design general-purpose registers won out over the
accumulator/index or data/address split of early CPUs: We use many
operations on several of these data types.
>> Having the individual cells of a c-addr u string
>> descriptor accessible is the foundation for a number of string
>> operations, e.g., checking whether a string is a prefix of another
>> string. If we put these data on separate stacks, we would have to
>> introduce and then use all kinds of words for transfering cells
>> between these stacks; that's not the case for FP data.
>
>I find that the first thing I want to do with an FP is split the fields
>out.
There are some people who do that, but not that many. In the Forth
world you see this by there never being anything close to a proposal
for e.g., accessing the fields, or for transferring the FP value to
the data stack as a bit pattern. Likewise, in many FPUs there is no
support for such operations.
>> 2) How many cells should an FP value have on the data stack? 1? 2? 4?
>> None of these answers is good for all systems. Or maybe an FP value
>> should be an opaque type with an unspecified size? Then you cannot
>> access anything below it.
[...]
>We have to provide the floating point math words, why not just provide
>a few constants to tell us how big they are?
And this helps us in which way? E.g., take:
: faxpy ( ra f_x nstridex f_y nstridey ucount -- )
\ vy=ra*vx+vy
>r swap 2swap swap r> 0 ?DO
fdup dup f@ f* over + 2swap dup f@ f+ dup f! over + 2swap
LOOP 2drop 2drop fdrop ;
Rewrite this to work with FP values with system-specific number of
cells on the data stack. You may use the constants you have in mind.
>I'm not a real fan of most floating point hardware. Lack of support
>for a fully meaningful set of equality operators is just one of the
>problems. Separate registers is another, although, on a register-
>starved CPU, extra registers for floating point registers can be
>rather useful.
Even register-rich architectures such as IA-64 have separate FP
registers. This allows to keep FP registers close to the FPU and
integer registers close to the integer unit.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-10 00:25 -0700 |
| Subject | Re: FP stack (was: Recognizers discussion) |
| Message-ID | <60f085e8-a418-4670-9e53-310b23a28f3f@googlegroups.com> |
| In reply to | #58891 |
On Tuesday, May 9, 2017 at 11:24:29 PM UTC+9, Anton Ertl wrote:
> Joel Rees <joel rees@somewhere> writes:
> >On Monday, May 8, 2017 at 10:24:31 PM UTC+9, Anton Ertl wrote:
> >> Joel Rees <joel rees@somewhere> writes:
> >> >I've never understood the need for a separate floating point stack.
> >> ...
> >> >But we put doubles, pointers, string pointers, string records, and all sort=
> >> >s of other non-single-cell-integer non-scalar stuff on the parameter/local =
> >> >state stack. Why not floating point, as well? (Especially, now that 32 bit =
> >> >and 64 bit CPUs are becoming the norm, even in the embedded world.)
> >>
> >> 1) There is little overlap between integer and FP operations,
> >> basically just the data-movement stuff @ ! DUP SWAP etc. By contrast,
> >> we use, e.g., +, -, and u< on signed and unsigned integers, and on
> >> addresses, and being able to access the individual cells of doubles
> >> allows implementing various more refined operations (e.g., triple-cell
> >> integers in M*/).
> >
> >Well, the virtual word U+ is the same as + on two's complement, but D+ is
> >still D+. And then there is UM* and UM/MOD, etc.
> >
> >It's not like type is completely transparent until you hit FP.
>
> Of course not. That's not what I claimed.
>
> Another way of putting it: We do not split the data stack into an
> address stack, an integer stack, a double stack, etc. for the same
> reason that in CPU design general-purpose registers won out over the
> accumulator/index or data/address split of early CPUs: We use many
> operations on several of these data types.
>
> >> Having the individual cells of a c-addr u string
> >> descriptor accessible is the foundation for a number of string
> >> operations, e.g., checking whether a string is a prefix of another
> >> string. If we put these data on separate stacks, we would have to
> >> introduce and then use all kinds of words for transfering cells
> >> between these stacks; that's not the case for FP data.
> >
> >I find that the first thing I want to do with an FP is split the fields
> >out.
>
> There are some people who do that, but not that many. In the Forth
> world you see this by there never being anything close to a proposal
> for e.g., accessing the fields, or for transferring the FP value to
> the data stack as a bit pattern. Likewise, in many FPUs there is no
> support for such operations.
Thus, the move to memory and back.
[Eliding a rant about the general evils of floating point and a blind
assertion about multi-precision being much more fitting to the common
requirements, and fixed-point being a better fit to most of the rest
of the problem domain, ... :)]
> >> 2) How many cells should an FP value have on the data stack? 1? 2? 4?
> >> None of these answers is good for all systems. Or maybe an FP value
> >> should be an opaque type with an unspecified size? Then you cannot
> >> access anything below it.
> [...]
> >We have to provide the floating point math words, why not just provide
> >a few constants to tell us how big they are?
>
> And this helps us in which way? E.g., take:
>
> : faxpy ( ra f_x nstridex f_y nstridey ucount -- )
> \ vy=ra*vx+vy
Was that for my benefit, or do you also document much of your code with
idealized infix?
If it was for my benefit, I'd have appreciated a bit more explanation
of your type notation. I don't have gforth's type notations memorized.
Okay, let me see. My first try assuming f_x and f_y were floating point
scalars didn't make sense. So, trying under the assumption that f_x and
f_y are pointers to floating point vectors and translating to my own
notation:
( f: ra -- )
( p: addr_x stride_x addr_y stride_y ucount )
> >r swap 2swap swap r> 0 ?DO
> fdup dup f@ f* over + 2swap dup f@ f+ dup f! over + 2swap
> LOOP 2drop 2drop fdrop ;
You know, I can't read that without help. I'll try, assuming that
floating point is on its own stack, and swap, etc., don't have effects
on the floating point stack:
>r ( ucount )
swap ( y stride and address, address up )
2swap ( y pair and x pair )
swap ( x address up )
r> ( ucount )
0 ?DO ( limit and counter out of the way )
fdup ( copy of ra )
dup ( copy of x addr )
f@ ( what x is pointing at )
f* ( product of ra and what x is pointing at )
over + ( bump x to next )
( This is where I stopped to check the gforth manual and recognized
that ra must be a floating point, and then realized that f_x and
f_y were addresses, not scalar floats, and it began making sense. )
2swap ( x and y references )
dup f@ f+ ( sum the product with what y is pointing at )
dup f! ( save sum at y )
over + ( update y )
2swap ( x and y references ready for next loop )
LOOP 2drop 2drop fdrop ;
Okay, I've solved my stack puzzle for the day. :|
Now, how that would work with a unified stack?
If you have stridex, which apparently is the same as stridey, since
you use f* for one and f+ for the other, you already know the width.
Are they different? Does the floating point stack know how big each
one is point to? That would require something besides ordinary
addresses for f_x and f_y. So they are the same.
First, what you are taking advantage of here is actually just having
a separate stack. Since that is so, what do we have against having
a separate general stack, instead, say a local stack? (You know about
such things, right? :)
> Rewrite this to work with FP values with system-specific number of
> cells on the data stack. You may use the constants you have in mind.
First answer, use named parameters. But that's cheating for this
puzzle, since we no longer have to move the floating points around
on the stack (much). 8-*
Except, gforth's named parameters are all cells, and access-b-value.
And you don't have a way to take the address of a named parameter,
do you?
Okay, that one really is cheating in this context.
Second take on the first answer:
When the floating point unit provides the separate floating point
stack, we get that for free.
If we don't have that for free, I'd rather have a general
separate stack for locals, and a type of local variable similar to
the old fig-Forth USER variable, but on the local stack.
Anyway, second answer:
Just as a thought, with the floating point stack separate,
( ra f_x nstridex f_y nstridey ucount -- )
cannot reasonably be distinguished (by the interpreter) from
( f_x nstridex f_y nstridey ucount ra -- )
We could provide
f>r ( and ) fr>
as a way to get ra out of the way while we bring in stuff we need
to swap it with.
It's a little clumsy, I suppose, but
: FPCELLCALC sp@ >r 0. d>f sp@ r> swap - >r fdrop r> ;
FPCELLCALC constant FPCELLWIDTH
: fpick ( r0 ... n -- r0 )
sp@ + f@ ; ( Should be implemented at low level. )
: fput ( r1 ... r0 n -- r0 ... ) ( I'm sure somebody will complain. )
sp@ + f! ; ( Should be implemented at low level. )
: put ( n1 ... n0 n -- n0 ... )
sp@ + ! ;
( But I didn't really need either fput or put, I think. Anyway, )
( At this point it's clear what I'm doing? )
: faxpy ( ra f_x f_y ucount -- )
\ vy=ra*vx+vy
0 ?DO
2 fpick FPCELLWIDTH 1+ pick f@ f*
FPCELLWIDTH pick f@ f+
FPCELLWIDTH pick f!
FPCELLWIDTH +
swap FPCELLWIDTH +
swap
LOOP
drop drop fdrop ;
> >I'm not a real fan of most floating point hardware. Lack of support
> >for a fully meaningful set of equality operators is just one of the
> >problems. Separate registers is another, although, on a register-
> >starved CPU, extra registers for floating point registers can be
> >rather useful.
>
> Even register-rich architectures such as IA-64 have separate FP
> registers. This allows to keep FP registers close to the FPU and
> integer registers close to the integer unit.
Sometimes I think it would be better if our floats were actually
double integers. That is, one integer would be the fraction or
mantissa, and the other would be the exponent. (And the CPU would
give us both two's complement and sign-magnitude math, just to
make life fun.)
It seems expensive memory-wise, but what does memory cost these
days?
And graphics really should be fixed point.
--
Joel Rees
Randing rantomly:
http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-10 11:39 +0000 |
| Subject | Re: FP stack (was: Recognizers discussion) |
| Message-ID | <2017May10.133911@mips.complang.tuwien.ac.at> |
| In reply to | #58931 |
Joel Rees <joel.rees@gmail.com> writes:
>On Tuesday, May 9, 2017 at 11:24:29 PM UTC+9, Anton Ertl wrote:
[FPCELLWIDTH]
>> And this helps us in which way? E.g., take:
>>
>> : faxpy ( ra f_x nstridex f_y nstridey ucount -- )
>> \ vy=ra*vx+vy
>
>Was that for my benefit, or do you also document much of your code with
>idealized infix?
This is a variant of the original documentation. I don't do much
math-oriented code, so not much of my code is documented like this.
How would you document it? The documentation for f_x nstridex
etc. can admittedly be improved.
>If it was for my benefit, I'd have appreciated a bit more explanation
>of your type notation. I don't have gforth's type notations memorized.
r is an FP value (standard notation).
n is a signed integer (standard notation).
u is an unsigned integer (standard notation)
f_ is the address of an FP value. (f_addr would be standard notation)
For a related word, the documentation is better:
|v* ( f_addr1 nstride1 f_addr2 nstride2 ucount -- r ) gforth v_star
|
|dot-product: r=v1*v2. The first element of v1 is at f_addr1, the
|next at f_addr1+nstride1 and so on (similar for v2). Both vectors have
|ucount elements.
>If you have stridex, which apparently is the same as stridey, since
>you use f* for one and f+ for the other, you already know the width.
No, the elements of each vector do not have to be adjacent. E.g., vx
(described by f_x nstridex) may be a row of a matrix, and vy a column.
Or they could both be diagonals. Or one might stride backwards.
>First, what you are taking advantage of here is actually just having
>a separate stack.
Yes, that's another benefit of having a separate FP stack.
>Since that is so, what do we have against having
>a separate general stack, instead, say a local stack? (You know about
>such things, right? :)
You lost me here. Do you mean a second return stack?
>First answer, use named parameters. But that's cheating for this
>puzzle, since we no longer have to move the floating points around
>on the stack (much). 8-*
Actually, yes, with locals you can eliminate all need for stack
manipulation. But remember, you are trying to sell your unified stack
to a Forth audience, some of which hate locals.
>Except, gforth's named parameters are all cells, and access-b-value.
>And you don't have a way to take the address of a named parameter,
>do you?
Gforth has FP locals and variable-flavoured locals (although the
variable-flavoured locals are so little-used that I guess nobody would
miss them if they went away; in the present case it's better to do
without them, too).
>It's a little clumsy, I suppose, but
>
>: FPCELLCALC sp@ >r 0. d>f sp@ r> swap - >r fdrop r> ;
>
>FPCELLCALC constant FPCELLWIDTH
>
>: fpick ( r0 ... n -- r0 )
> sp@ + f@ ; ( Should be implemented at low level. )
>
>: fput ( r1 ... r0 n -- r0 ... ) ( I'm sure somebody will complain. )
> sp@ + f! ; ( Should be implemented at low level. )
>
>: put ( n1 ... n0 n -- n0 ... )
> sp@ + ! ;
This is missing some CELLS or 1 CELLS /, but I get the gist.
>( But I didn't really need either fput or put, I think. Anyway, )
>
>( At this point it's clear what I'm doing? )
>
>: faxpy ( ra f_x f_y ucount -- )
>\ vy=ra*vx+vy
> 0 ?DO
> 2 fpick FPCELLWIDTH 1+ pick f@ f*
> FPCELLWIDTH pick f@ f+
> FPCELLWIDTH pick f!
> FPCELLWIDTH +
> swap FPCELLWIDTH +
> swap
> LOOP
> drop drop fdrop ;
You lost the flexibility of allowing arbitrary strides (and different
ones for x and y). But ok, if we limit ourselves to that, here's the
same program in Forth-2012 (i.e., separate FP stack) (untested):
: faxpy-nostride ( ra f_x f_y ucount -- )
\ vy=ra*vx+vy
0 ?do
fdup over f@ f* dup f@ f+ dup f!
float+ swap float+ swap loop
2drop fdrop ;
I think these two definitions amply demonstrate the advantages of a
separate FP stack over a unified stack.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-05-10 11:49 -0700 |
| Subject | Re: FP stack (was: Recognizers discussion) |
| Message-ID | <bef00621-221b-4703-a850-78adc77c98e8@googlegroups.com> |
| In reply to | #58972 |
On Wednesday, May 10, 2017 at 9:36:45 PM UTC+9, Anton Ertl wrote: > Joel Rees <joel.rees@somewhere> writes: > >On Tuesday, May 9, 2017 at 11:24:29 PM UTC+9, Anton Ertl wrote: > [FPCELLWIDTH] > [...] > >If you have stridex, which apparently is the same as stridey, since > >you use f* for one and f+ for the other, you already know the width. > > No, the elements of each vector do not have to be adjacent. E.g., vx > (described by f_x nstridex) may be a row of a matrix, and vy a column. > Or they could both be diagonals. Or one might stride backwards. I see. That was something I missed. > >First, what you are taking advantage of here is actually just having > >a separate stack. > > Yes, that's another benefit of having a separate FP stack. I'm proposing it's the primary benefit. > >Since that is so, what do we have against having > >a separate general stack, instead, say a local stack? (You know about > >such things, right? :) > > You lost me here. Do you mean a second return stack? Now you've lost me. I mean a second stack to dump temporaries to, as an alternative to >r and r> . > >First answer, use named parameters. But that's cheating for this > >puzzle, since we no longer have to move the floating points around > >on the stack (much). 8-* > > Actually, yes, with locals you can eliminate all need for stack > manipulation. But remember, you are trying to sell your unified stack > to a Forth audience, some of which hate locals. > > >Except, gforth's named parameters are all cells, and access-b-value. > >And you don't have a way to take the address of a named parameter, > >do you? > > Gforth has FP locals and variable-flavoured locals (although the > variable-flavoured locals are so little-used that I guess nobody would > miss them if they went away; in the present case it's better to do > without them, too). I had forgotten that. I keep falling asleep when I try to read the gforth documentation. Well, not because of the documentation, because the only time I can break loose for it, I'm already half-way to never-never land. :-( > >It's a little clumsy, I suppose, but > > > >: FPCELLCALC sp@ >r 0. d>f sp@ r> swap - >r fdrop r> ; > > > >FPCELLCALC constant FPCELLWIDTH > > > >: fpick ( r0 ... n -- r0 ) > > sp@ + f@ ; ( Should be implemented at low level. ) ( eek! speaking of half-way to never-never land. :-/ ) FPCELLWIDTH * sp@ + f@ ; > >: fput ( r1 ... r0 n -- r0 ... ) ( I'm sure somebody will complain. ) > > sp@ + f! ; ( Should be implemented at low level. ) ( as above ) > >: put ( n1 ... n0 n -- n0 ... ) > > sp@ + ! ; CELLWIDTH * sp@ + ! ; > This is missing some CELLS or 1 CELLS /, but I get the gist. Right. :( But all of those really should be implemented in assembler. If I had designed the early Forths, I think I would have put pick and put in before rot and roll. I know ROT is implementable as register renaming, where pick is a little hard to defer the copy for. But locality of reference has certain limits. > >( But I didn't really need either fput or put, I think. Anyway, ) > > > >( At this point it's clear what I'm doing? ) > > > >: faxpy ( ra f_x f_y ucount -- ) > >\ vy=ra*vx+vy > > 0 ?DO > > 2 fpick FPCELLWIDTH 1+ pick f@ f* > > FPCELLWIDTH pick f@ f+ > > FPCELLWIDTH pick f! > > FPCELLWIDTH + > > swap FPCELLWIDTH + > > swap > > LOOP > > drop drop fdrop ; > > You lost the flexibility of allowing arbitrary strides (and different > ones for x and y). But ok, if we limit ourselves to that, here's the > same program in Forth-2012 (i.e., separate FP stack) (untested): > > : faxpy-nostride ( ra f_x f_y ucount -- ) > \ vy=ra*vx+vy > 0 ?do > fdup over f@ f* dup f@ f+ dup f! > float+ swap float+ swap loop > 2drop fdrop ; > > I think these two definitions amply demonstrate the advantages of a > separate FP stack over a unified stack. In reduction to absurdity, shouldn't we therefore have yet other separate stacks -- a doubles stack, an address stack, a strings stack, etc.? To be fair, if we compare having a separate floating point stack to having an additional general purpose stack, we should give the general purpose stack operators like the floating point stack operators. We could perhaps call them aXXX, to show the use of the alternate stack. (I don't mean fair to me and people of like mind, I mean giving fair consideration to a different approach. We could be cutting off our noses to spite our faces here.) Thus, F@ would operate within a single stack, and aF@ would push a floating point on the alternate general stack. And we would have D@ and aD@, etc. Of course, I am taking the point of view that it would cost no more to implement an alternate general purpose stack when I suggest this, and that is not a real assumption, not fair, as it were, to the tightest constraints of many existing small embedded processors. In my fantasy world, at any rate, even small controllers will have two stacks in addition to the return address stack, and the return address stack will usually be hidden or cached. Back in the real world, if using the FP registers as a stack doesn't interfere with their use in vector operations, yeah, the FP stack makes sense. -- Joel Rees delusions of being a novelist: http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-09 21:15 +1000 |
| Subject | Re: FP stack (was: Recognizers discussion) |
| Message-ID | <oes8dc$ku2$1@gioia.aioe.org> |
| In reply to | #58827 |
Anton Ertl wrote: > ... > This has now come up several times, so I have added it to the FAQ: > > https://www.complang.tuwien.ac.at/forth/faq/faq-general.html#toc5.15 > > - anton "tell a lie big enough and keep repeating it, people will eventually come to believe it." Joseph Goebbels
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-09 14:16 +1000 |
| Message-ID | <oerfqh$19fp$1@gioia.aioe.org> |
| In reply to | #58803 |
Joel Rees wrote: > ... > But we put doubles, pointers, string pointers, string records, and all sorts of other > non-single-cell-integer non-scalar stuff on the parameter/local state stack. Why not > floating point, as well? (Especially, now that 32 bit and 64 bit CPUs are becoming the > norm, even in the embedded world.) Forth has used f/p on the data stack since the beginning and it's not an issue for those who use it. Hardware f/p stack makes sense but often come with limits. Understanding there is no single right answer, VFX comes with (or did when I last looked) three versions of f/p - hardware/software/data stack.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-03 08:57 -0500 |
| Message-ID | <qqWdnRjCDcMufJTEnZ2dnUU7-VudnZ2d@supernews.com> |
| In reply to | #58577 |
minforth@arcor.de wrote: > > In my world there are users (customers) and implementers > (engineers). Users will never touch recognizers or even know they > exist. Software engineers are clever enough to extend NUMBER? in a > small Forth System by a few lines of code to recognize > application-specific formats. They really don't need recognizers. Yes, I can see that. > However things are not so easy when the Forth system source is not > disclosed,, e.g. encrypted or protected by some other means. Sure, but then you're screwed anyway. I've never used a Forth I didn't have the source code for, and neither would I want to. One great benefit of a simple system is that you can easily change it, and you don't have to depend on high priests in their ivory tower to consider your request. > Then recognizers offer hooks to "crippled implementors" of new data > formats while maintaining core system source protection. On the > other hand recognizers are nice backdoor for incrementing target > system vulnerability. ;-) LOL! :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-05-03 07:54 -0700 |
| Message-ID | <001b418d-c670-46d4-a002-30d6c2359f27@googlegroups.com> |
| In reply to | #58583 |
Am Mittwoch, 3. Mai 2017 15:57:13 UTC+2 schrieb Andrew Haley: > > However things are not so easy when the Forth system source is not > > disclosed,, e.g. encrypted or protected by some other means. > > Sure, but then you're screwed anyway. I've never used a Forth I > didn't have the source code for, and neither would I want to. One > great benefit of a simple system is that you can easily change it, and > you don't have to depend on high priests in their ivory tower to > consider your request. > Sure, but there is a reason behind, when you're not in a One-Man-Show. The core system should never be messed around with by engineers, like any firmware or operating system internals. That's the realm of software development.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-03 11:30 -0500 |
| Message-ID | <CNydnXVq7pMmmJfEnZ2dnUU7-UGdnZ2d@supernews.com> |
| In reply to | #58586 |
minforth@arcor.de wrote: > Am Mittwoch, 3. Mai 2017 15:57:13 UTC+2 schrieb Andrew Haley: >> > However things are not so easy when the Forth system source is not >> > disclosed,, e.g. encrypted or protected by some other means. >> >> Sure, but then you're screwed anyway. I've never used a Forth I >> didn't have the source code for, and neither would I want to. One >> great benefit of a simple system is that you can easily change it, and >> you don't have to depend on high priests in their ivory tower to >> consider your request. > > Sure, but there is a reason behind, when you're not in a > One-Man-Show. The core system should never be messed around with by > engineers, like any firmware or operating system internals. That's > the realm of software development. Oh come on, you've got a crucial delivery to make, and you come across a bug in some core software. What are you going to do besides fix it? And the flexibility of Forth isn't just about development: you can customize a Forth to add debugging, tracing, and measurement features. And you can put in just the diagnostics you want *right now*, not wait for it to be released as a new feature. All of this is extremely useful in real-world software development. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-03 14:05 -0500 |
| Message-ID | <oed9fa$938$1@dont-email.me> |
| In reply to | #58593 |
On 5/3/2017 11:30 AM, Andrew Haley wrote: > minforth@arcor.de wrote: >> Am Mittwoch, 3. Mai 2017 15:57:13 UTC+2 schrieb Andrew Haley: >>>> However things are not so easy when the Forth system source is not >>>> disclosed,, e.g. encrypted or protected by some other means. >>> >>> Sure, but then you're screwed anyway. I've never used a Forth I >>> didn't have the source code for, and neither would I want to. One >>> great benefit of a simple system is that you can easily change it, and >>> you don't have to depend on high priests in their ivory tower to >>> consider your request. >> >> Sure, but there is a reason behind, when you're not in a >> One-Man-Show. The core system should never be messed around with by >> engineers, like any firmware or operating system internals. That's >> the realm of software development. > > Oh come on, you've got a crucial delivery to make, and you come across > a bug in some core software. What are you going to do besides fix it? > And the flexibility of Forth isn't just about development: you can > customize a Forth to add debugging, tracing, and measurement features. > And you can put in just the diagnostics you want *right now*, not wait > for it to be released as a new feature. All of this is extremely > useful in real-world software development. > > Andrew. > That is one of the great advantages of Forth you are in charge of the development software. Customers will not wait for the vendor when there is a problem, neither should the developer if he/she can help it. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-03 18:42 +0100 |
| Message-ID | <oed4kp$mq9$1@dont-email.me> |
| In reply to | #58583 |
On 5/3/2017 14:57, Andrew Haley wrote: > minforth@arcor.de wrote: > >> However things are not so easy when the Forth system source is not >> disclosed,, e.g. encrypted or protected by some other means. > > Sure, but then you're screwed anyway. I've never used a Forth I > didn't have the source code for, and neither would I want to. One > great benefit of a simple system is that you can easily change it, and > you don't have to depend on high priests in their ivory tower to > consider your request. > That screws up libraries. In fact, I'd say this approach of falling back on specific source implementations & systems has right royally screwed up any progress in the area of portable code. Hugh's got a point here*; this doesn't progress the world of portability one inch. *That was hard to say, I'll be frank, but even a busted clock can be right occasionally. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 02:51 -0500 |
| Message-ID | <kOSdnS_PQK3kQJfEnZ2dnUU7-IOdnZ2d@supernews.com> |
| In reply to | #58604 |
Alex <alex@rivadpm.com> wrote: > On 5/3/2017 14:57, Andrew Haley wrote: >> minforth@arcor.de wrote: > >>> However things are not so easy when the Forth system source is not >>> disclosed,, e.g. encrypted or protected by some other means. >> >> Sure, but then you're screwed anyway. I've never used a Forth I >> didn't have the source code for, and neither would I want to. One >> great benefit of a simple system is that you can easily change it, and >> you don't have to depend on high priests in their ivory tower to >> consider your request. > > That screws up libraries. Nonsense. You don't have to change anything that will break something you depend on. I am, of course, assuming that the programmer isn't a complete idiot. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-05-04 22:29 +1000 |
| Message-ID | <oef6rc$1n95$1@gioia.aioe.org> |
| In reply to | #58604 |
Alex wrote: > On 5/3/2017 14:57, Andrew Haley wrote: > > minforth@arcor.de wrote: > > > > >> However things are not so easy when the Forth system source is not > >> disclosed,, e.g. encrypted or protected by some other means. > > > > Sure, but then you're screwed anyway. I've never used a Forth I > > didn't have the source code for, and neither would I want to. One > > great benefit of a simple system is that you can easily change it, and > > you don't have to depend on high priests in their ivory tower to > > consider your request. > > > > That screws up libraries. In fact, I'd say this approach of falling back > on specific source implementations & systems has right royally screwed > up any progress in the area of portable code. Hugh's got a point here*; > this doesn't progress the world of portability one inch. > > *That was hard to say, I'll be frank, but even a busted clock can be > right occasionally. Do you use Hugh's portable library code?
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-04 13:41 +0100 |
| Message-ID | <oef7b0$nfs$1@dont-email.me> |
| In reply to | #58644 |
On 5/4/2017 13:29, HAA wrote: > Alex wrote: >> On 5/3/2017 14:57, Andrew Haley wrote: >>> minforth@arcor.de wrote: >> >>> >>>> However things are not so easy when the Forth system source is not >>>> disclosed,, e.g. encrypted or protected by some other means. >>> >>> Sure, but then you're screwed anyway. I've never used a Forth I >>> didn't have the source code for, and neither would I want to. One >>> great benefit of a simple system is that you can easily change it, and >>> you don't have to depend on high priests in their ivory tower to >>> consider your request. >>> >> >> That screws up libraries. In fact, I'd say this approach of falling back >> on specific source implementations & systems has right royally screwed >> up any progress in the area of portable code. Hugh's got a point here*; >> this doesn't progress the world of portability one inch. >> >> *That was hard to say, I'll be frank, but even a busted clock can be >> right occasionally. > > Do you use Hugh's portable library code? > > > You mean the novice.fth? If that, then no. It's huge and full of stuff I don't have a use for. The interdependencies of various parts are overkill; you can't use any of the functions in the bottom half of the monolithic lump of source because they depend on (some fairly oddball) definitions in the first half. It also has (had? I never know when or where Hugh reissues it to fix bugs, even though he claims never to write buggy software) some serious pitfalls due to late binding. I also dislike the overuse of ABORT" on what feels like every second line. This lack of divisibility is a criticism of other libraries too; I've used the Forth Foundation Library (FFL), but again the interlocking nature of the parts is problematic. I have used small parts and still do, but some of it I have rewritten just to gain some clarity in my own code without the overload of a third party's style. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 09:06 -0500 |
| Message-ID | <t6OdnUjMBLDzqJbEnZ2dnUU7-e3NnZ2d@supernews.com> |
| In reply to | #58646 |
Alex <alex@rivadpm.com> wrote: > > The interdependencies of various parts are overkill; ... > > This lack of divisibility is a criticism of other libraries too; I've > used the Forth Foundation Library (FFL), but again the interlocking > nature of the parts is problematic. I have used small parts and still > do, but some of it I have rewritten just to gain some clarity in my own > code without the overload of a third party's style. Well, that's libraries all over. They all seems to have complex dependencies. Tools like Maven handle this, but the end result is vast numbers of libraries end up being required for every project because of transitive dependencies. There is no good general solution, but Java solves some of it by only loading the parts of each library that are actually called and doing very aggressive inlining to make much of the overhead go away. It's rather a sledgehammer approach and certainly not one I'd recommend in general, but it mostly works. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-05-15 12:22 +0000 |
| Message-ID | <xn0kq0edldbx3p009@nntp.aioe.org> |
| In reply to | #58655 |
Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: > > > > The interdependencies of various parts are overkill; ... > > > > This lack of divisibility is a criticism of other libraries too; > > I've used the Forth Foundation Library (FFL), but again the > > interlocking nature of the parts is problematic. I have used small > > parts and still do, but some of it I have rewritten just to gain > > some clarity in my own code without the overload of a third party's > > style. > > Well, that's libraries all over. They all seems to have complex > dependencies. Some do. Some don't. A good library doesn't have many dependencies, except on a few basic things. -- Rudy Velthuis http://www.rvelthuis.de "We need a common enemy to unite us." -- Condoleezza Rice, March 2000
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web